Define tiny and topological vocabulary for "relationship"

[dmitrizagidulin]

Please Indicate One:

• Editorial
• Question
• Feedback
• Blocking Issue
• Non-Blocking Issue

Please Describe the Issue:

Outside of the domain of family history or heraldry sites (an area that seems out of scope for AS2), the concept of describing social relationships has been bogged down with controversy and technical problems. The state of the art in ontologies related to this subject (foaf and relationships vocabulary) leaves something to be desired. And there doesn't seem to be any real use case for it, aside from the very narrow case of implementing "Friend"-lists type functionality used by many social apps.

The Friends list use case is important, but is being addressed by ActivityPub's followers and following collections.

I propose:

1. Drop the "Relationship" object from the vocabulary
2. Drop relationship from section 4 (common properties of objects)
3. Drop section 5.2 Representing Relationships Between Entities as out of scope for this spec.
4. Either a) move section 5.2.1 Modeling "friend requests" to the ActivityPub spec, or b) make section 5.2.1 the entirety of 5.2, just using the Offer and Follow objects and referencing the Followers collection, without using Relationship objects.

I'm happy to make a PR with these changes.

[dmitrizagidulin]

After talking to @evanp at the F2F, I propose instead to rephrase this issue as - since we have an Extension mechanism, why don't we move the "Relationship" object and related properties to an extension, instead of core.

[tantek]

Note also additional prior relationship vocabulary work:

• XFN - http://gmpg.org/xfn/11
• vCard 4 (RFC6350) RELATED property (based on XFN, with additions) - http://tools.ietf.org/html/rfc6350#section-6.6.6

Strongly agree with spinning this out of the spec, and whoever is working on it, please try to align with prior established work.

[evanp]

Group resolved to remove Relationship

[jasnell]

-1 to removing Relationship. The use case is well documented. Maintaining friends/relationship collections is central to most social services. What has not been indicated is why Relationship as currently defined is inadequate.

[dmitrizagidulin]

@jasnell Can you point us to use case documentation for the Relationship object?
The proposal to move it to an Extension instead of Core is for several reasons:

• no obvious use cases. The 'friends/followers' use case is being handled in things like ActivityPub via the use of Followers collections.
• there are no good vocabs or ontologies for the Relationship object to use

[jasnell]

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams-vocabulary/#connections

[dmitrizagidulin]

Do you have any other links to use cases aside from friends lists? Because a Relationship object is completely superfluous to friends/subscribers/followers management, which can be done with simple collections of actors (which is how AP handles it, as do most other similar systems).

But even if you're looking to cover exotic use cases like dating sites or family history sites, why not implement Relationships as an Extension? Why does it need to be in the core?

[jasnell]

While I disagree with this change, don't let my -1 block it if there is consensus in the group.

[evanp]

One thing I've realized as I work on this issue is that without the Relationship type we don't have a way to model a "friend request". Given that, I'm also -1 on this proposal.

I understand the motivation, but I wonder if we could instead provide a minimal, topological relationship vocabulary that describes the structure of the social graph without any additional social values attached.

I realize that's not easy and that there are implicit values in any description, but we might be able to avoid some of the pitfalls if we steer towards describing edges in the social graph rather than qualitative social relationships.

One way to do this is to provide a finite set of sub-classes of Relationship:

• FollowingRelationship: subject is following object. Unidirectional.
• FollowerRelationship: object is following subject. Unidirectional.
• ContactRelationship: subject and object follow each other. "Friend" might be another term to use here, as it's the term of art for mutual relationships, but it's loaded with social meaning, while "contact" is more neutral.
• MemberRelationship: subject is a member of object. Object type would typically be something like Group or Organization.

Extensions that want to provide more socially relevant relationships could do so with extension types.

If we pursued this mechanism, we'd drop the "relationship" property and use "type" to specialize Relationships instead.

[jasnell]

Works for me but it's a slippery slope. Would need to keep the vocabulary as constrained as possible.

I don't think we'd need to drop relationship, we'd would just provide a set of terms for it (rather than subclassing Relationship:

{
  "type": "Relationship",
  "subject": "acct:james@gmail.com",
  "relationship": "Following",
  "object": "acct:evanp@fuzzy.io"
}

This would keep parsing fairly simple and would simplify code in that implementers would not have to keep track of the type hierarchy between Relationship and it's subclasses.

[jasnell]

The actual base terms I'd recommend for relationship would be something like:

• http://www.w3.org/ns/activitystreams/IsFollowing - "relationship": "IsFollowing"
• http://www.w3.org/ns/activitystreams/IsFollower - "relationship": "IsFollower"
• http://www.w3.org/ns/activitystreams/IsContact - "relationship": "IsContact"
• http://www.w3.org/ns/activitystreams/IsMember - "relationship": "IsMember"

[tantek]

@dmitrizagidulin you wrote "there are no good vocabs or ontologies for the Relationship object to use", perhaps you missed my previous comment (since we commented on the same day).

#289 (comment)

XFN 1.1 has been well established since 2004, and was normatively incorporated into vCard4 (RFC 6350, 2011).

In addition, if we're looking at adding following/follower semantics, those terms have been found to work quite well based on research:

http://microformats.org/wiki/xfn-brainstorming#follower_and_following

and @jasnell even used one in his code example: "relationship": "Following"

[kevinmarks]

Do you mean 'topological' rather than 'topographical' ? I don't see the connection to geography here.

[evanp]

@kevinmarks DOH. Yes, topological.

[sandhawke]

@evanp you asked me some details about representing this in OWL.

The example in the OWL Primer is

:toddlerAge  owl:equivalentClass
   [ rdf:type rdfs:Datatype;
     owl:oneOf (  "1"^^xsd:integer  "2"^^xsd:integer )
   ] .

I want to point out that using this for property names seems like pretty bad modeling.

Of course, one would normally use properties as properties, but AS2 makes that hard, since it reifies everything

A middle ground might be to have the properties be "individuals" (IRIs which denote conceptual entities).

Then it's a different kind of enumeration, like https://www.w3.org/TR/owl2-primer/#Enumeration_of_Individuals

[tantek]

@evanp @sandhawke in re-reading where this discussion has gone I realized that the fact that this feature is still not fully well understood (certainly unimplemented/unprototyped) and its design is still being brainstormed here in a github issue IMO means it's far from being baked well enough to be "CR ready" (certainly has not received wide review), and on the contrary, very much tends to support @dmitrizagidulin's proposal of having it develop independently as an extension.

I would prefer that this "Relationship" feature not jeopardize or delay AS2 CR any further (which it is doing at the moment), and thus +1 to @dmitrizagidulin's proposal.

[rhiaro]

Turns out I was wrong about this. Hold that thought.

I'm marking this as Commenter Satisfied on the basis of offline discussion with @dmitrizagidulin that this feature (along with all others) is implicitly at risk and will be dropped if not implemented by the end of CR.

For the record, I also agree that this should be an extension and not in core.