Here’s some thoughts, just brainstorming, on this latest version…
Update: I didn’t post this yesterday as I was uncertain on my AP/LD/VF knowledge and asked on fedi, and am delighted to see @lynnfoster’s update, as I was thinking in a similar direction with the relationship property having the range of as:Object. And also defining relationships at Actor level. Adjusting my text to Lynn’s suggestion…
Unbound Groups
Definition (I’d use singular instead of plural):
Unbound Actor: An ActivityStreams
Actorthat is independent of the instance(s) that host it.
With that name I think the scope of this FEP should relate to any actor-type, not just Group. That also makes it more compatible to Valueflows, which defines relationships between ‘Agents’ on the same level.
The challenge to overcome is that the ActivityPub Object ID ties any object to a domain via an URL, and hence ties to an instance. The Unbound Actor FEP provides a workaround until the time that a better ID mechanism (content addressing, DID’s, … ?) is specified.
In this Group Link Relationship is a specialization of Actor Relationships, and gs:unbound an indicator of the Unbound Actor workaround being used. So I wonder if all this couldn’t be generalised to define these actor relationships.
Valueflows
Valueflows writes the following on Agent Relationships (see also: example):
[details =“click to expand Valueflows Agent Relationships documentation and ontology diagram …”]
Agent relationships have many nuances, thus VF provides the ability to define one’s own kinds of relationships. For example people might “participate” with an organization by means of agreeing to terms and conditions. Or people might have more active “membership” in a group or organization. Or people might consider themselves members but want a more independently flavored term such as “affiliates”.
A relationship can be direct, like “steward”, or more like a role, for example “grower” or “harvester” for a food network.
Relationships can also include roles like “sub-organization” or “trading partner”.
There are a number of useful Properties in existing vocabularies that can be used. Or people can create their own as needed.
Relationships have direction: For example, in “Michael is a member of Enspiral”, Michael is the subject and Enspiral is the object. In this case the inverse is also valid, “Enspiral has member Michael”. In VF, we consider this to be one relationship. One directional relationships like “follows” are also supported.
Relationships can be in a scope (or not): For example, “Kathy is mentor of Sam, in the scope of Enspiral.”
@lynnfoster here on SocialHub provided the following diagram of the ontology that Valueflows uses for that:
[/details]
- An actor can have zero or more relationships
- Some relationship types are commonly understood (standardized)
- Other relationship types can be custom defined (app-specific)
One thing I wonder about in the Valueflows specification of AgentRelationship… it looks like, by using roleLabel and inverseRoleLabel in AgentRelationshipRole, you lose the ability to define standardized Linked Data relationships. The only supported relationship is a Valueflows relationship. If you consider for instance the FOAF, Relationship, GoodRelations or Schema.org or many other ontologies, you want to standardize from widely adopted semantics defined there.
Actor Relationships
Though it is a bit vaguely defined in ActivityPub the streams property can contain “A list of supplementary Collections which may be of interest.”. And in @mayel’s doc for Bonfire this is also used. Then the Group may be:
{
"id": "https://social.undefinedhackers.net/group/hackers",
"type": "Group",
"preferredUsername": "hackers",
"streams": {
"relationships": "https://social.undefinedhackers.net/group/hackers/relationships"
},
"endpoints": {
"sharedInbox": "https://social.undefinedhackers.net/inbox.json"
},
"inbox": "https://social.undefinedhackers.net/group/hackers/inbox.json",
"outbox": "https://social.undefinedhackers.net/group/hackers/outbox.json",
"publicKey": {
"id": "https://social.undefinedhackers.net/group/hackers#public-key",
"owner": "https://social.undefinedhackers.net/group/hackers",
"publicKeyPem": "..."
}
}
(Note: If I look at the ActivityStreams definition of Relationship, then isn’t Example 47 invalid? The value of relationship property cannot be "http://purl.org/vocab/relationship/acquaintanceOf" as the range is as:Object. But that may be my limited LD understanding shining through.)
Here I follow up from @lynnfoster. But relationship should be an as:Object first. Idk, but maybe to express the relationship type the url property can be used. And maybe to express RoleBehavior (grouping of relationships into categories) the context property may be used. The spec says about “context”:
The notion of “context” used is intentionally vague. The intended function is to serve as a means of grouping objects and activities that share a common originating context or purpose. An example could be all activities relating to a common project or event.
With that, when dereferencing the relationships collection, something like this is returned:
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://social.undefinedhackers.net/group/hackers/relationships",
"type": "Collection",
"items": [
{
"id": "https://social.undefinedhackers.net/group/hackers/relationships/1",
"summary": "!lhackers@social.undefinedhackers.net and !lug@gnusocial.net are the same",
"type": "Relationship",
"subject": {
"type": "Group",
"id": "https://social.undefinedhackers.net/group/hackers"
},
"relationship": {
"type": ["Object", "vf:AgentRelationshipRole"],
"id": "https://social.undefinedhackers.net/groups/role/sameAs",
"url": "https://schema.org/sameAs",
"context": "https://social.undefinedhackers.net/nodeinfo/capability/UnboundGroups"
},
"object": {
"type": "Group",
"id": "https://gnusocial.net/group/lug"
}
}
]
}
In other words the Unbound Group that is hosted across 2 instances is indicated with a “sameAs” relationship, and the “context” makes clear how we should interpret the relationship’s meaning (UnboundGroup capability).
I left out the target here, because I’d need to learn more about this before doing so. In ActivityStreams 5.2.1 Modeling friends requests is an interesting flow to look at, I think.
This way an arbitrary number of different relationships could be defined between actors. The “context” as RoleBehavior might serve as a filter to only retrieve the ones that are interesting.
In the regular Groups implementations we have right now the “member_of” relationship is expressed via the followers collection I think. This may continue to be so, but only for a single relationship type i.e. “follows”. The Follow activity is defined in ActivityStreams as:
Indicates that the
actoris “following” theobject. Following is defined in the sense typically used within Social systems in which the actor is interested in any activity performed by or on the object. Thetargetandorigintypically have no defined meaning.
That also indicates a single type of relationship (though to me it seems to be different in meaning than a “member of” relationship. Someone can follow a Group without being a member. But it is as it is).
Standardized relationship types
In the example above there would be a need to standardize a set of relationship types and maybe contexts to be universally understood across the Fediverse. Just brainstorming, but e.g.
| context (capability) | relationship types |
|---|---|
| Unbound Groups | https://schema.org/sameAs |
| Organization Structure | http://purl.org/vocab/relationship/childOf |
http://purl.org/vocab/relationship/parentOf |
|
http://purl.org/vocab/relationship/siblingOf |
|
| Offering | http://purl.org/goodrelations/v1#offers |
http://purl.org/goodrelations/v1#seeks |
Etcetera…
Minor remarks
In @mayel’s document there is some terminology that seems to indicate a specialization of Groups, in other words app/implementation-specific. Probably perfectly fine, because it was created in that context, I think. But want to mention anyway…
- “User creates Group” → “Person creates Group” (I personally try to avoid “user” altogether)
- “Moderator” → yes, if you have moderators, but the notion of that is app-specific
- “The context field contains the parent Group’s id/uri” → a parent relationship?
I did not look into SharedCollections. I know too little about the low-level stuff needed still. But may spend more time on this 