-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add collection properties and relationship types #191
Conversation
Add: as:inbox, as:outbox, as:store and as:relationships Add: as:isBlocking, as:isIgnoring, as:isFollowing, as:isFollowedBy, as:isMemberOf
@evanp ... would like your thoughts on this |
To simplify the terms, consider dropping |
@csarven ... I'd considered that, but opted to keep the |
From the discussion on the WG telecon I looked in to common usage by social sites for "inbox". For both Facebook and LinkedIn, Inbox is only for direct messages (others use "notifications" which is also a somewhat confusing term as they get confused with push notifications). I found no examples of any silo that uses "inbox" for any type of wall/stream/feed etc. The closest I found was the GitHub has a old style inbox icon for its updates but it actually links to "/notifications". Annoyingly most do not have any discernible name for this main feed either. |
-1 to isFoo pattern! I guess we expect people to add is* properties for many other verbs? Follow - isFollowing Like - isLiking I proposed a way to reuse same verbs for both kind of N-ary Relations - Activities and Relation(ship)s https://lists.w3.org/Archives/Public/public-socialweb/2015Aug/0111.html https://github.com/w3c-social/social-vocab/tree/master/verb/likes Also before we start adding collection properties, I would like to see reasons of why not to reuse pattern used by LDP Direct Container and similar one proposed for Hydra Collection Design & HydraCG/Specifications#41 I see it as yet another way to reuse verbs defined as rdf:Property not only for Activity and Relation(ship) but also for Collection 😄 https://github.com/w3c-social/social-vocab/tree/master/container/DirectContainer Last but not least we should make clear strategy for dealing with inverse properties mnot/I-D#39 (comment) |
I think the missing piece of the puzzle is SKOS concept schemes and concepts. It provides sufficient extensibility and reuse. See also the W3C Web Annotation approach with oa:Motivation ( documentation: http://www.w3.org/TR/annotation-model/#motivations ) which also uses SKOS concepts for some built-in motivations, and more importantly provides the mechanism for different communities/implementations to take it further. Note: the WG is considering to use "roles" in place of motivations going forward. For the interactions/activities on my site, I indicate the A recent discussion on is/has prefixes is also here: w3c/web-annotation#70 |
Withdrawing |
This PR removes the existing as:replies property and adds:
as:inbox points to a collection containing items directed at an
object. This would include replies which is why the PR removes the
redundant as:replies
as:outbox points to a collection containing items originating from or
attributed to the object.
as:relationships points to a collection containing as:Relationship
objects that involve the containing object. Examples would include a
person's social graph, the people they are following or are being
followed by, the members of a group, etc.
as:store points to a collection containing objects being stored on
behalf of the containing object. This would, for instance, be used to
point to the root of a content store for a Person.
There is a very broad range of use cases covered by just these basic
four collection properties.
Additionally, the PR adds five specific relationship types. These include:
These are intended to be used as values in the as:Relationship object.