search

w3c / activitystreams

Activity Streams 2.0
https://www.w3.org/TR/activitystreams-core/
Other
278 stars 61 forks source link

Define tiny and topological vocabulary for "relationship" #289

Closed dmitrizagidulin closed 8 years ago

dmitrizagidulin commented 8 years ago

Please Indicate One:

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 commented 8 years ago

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 commented 8 years ago

Note also additional prior relationship vocabulary work:

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

evanp commented 8 years ago

Group resolved to remove Relationship

jasnell commented 8 years ago

-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 commented 8 years ago

@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:

jasnell commented 8 years ago

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

dmitrizagidulin commented 8 years ago

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 commented 8 years ago

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

evanp commented 8 years ago

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:

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 commented 8 years ago

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 commented 8 years ago

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

tantek commented 8 years ago

@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).

https://github.com/jasnell/w3c-socialwg-activitystreams/issues/289#issuecomment-197916259

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 commented 8 years ago

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

evanp commented 8 years ago

@kevinmarks DOH. Yes, topological.

sandhawke commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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.