Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

jasnell
Copy link
Collaborator

@jasnell jasnell commented Jul 15, 2015

This PR removes the existing as:replies property and adds:

  • as:inbox
  • as:outbox
  • as:relationships
  • as:store

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:

  • as:isBlocking
  • as:isIgnoring
  • as:isFollowing
  • as:isFollowedBy
  • as:isMemberOf

These are intended to be used as values in the as:Relationship object.

Add: as:inbox, as:outbox, as:store and as:relationships
Add: as:isBlocking, as:isIgnoring, as:isFollowing, as:isFollowedBy,
     as:isMemberOf
@jasnell
Copy link
Collaborator Author

jasnell commented Jul 15, 2015

@evanp ... would like your thoughts on this

@csarven
Copy link
Member

csarven commented Jul 15, 2015

To simplify the terms, consider dropping is, has or alike from properties/classes. They are in a way implied.

@jasnell
Copy link
Collaborator Author

jasnell commented Jul 15, 2015

@csarven ... I'd considered that, but opted to keep the is prefix to help differentiate the relationship properties from the other core, more general use properties.

@dissolve
Copy link
Contributor

dissolve commented Aug 7, 2015

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.

@elf-pavlik
Copy link
Member

-1 to isFoo pattern!

I guess we expect people to add is* properties for many other verbs?

Follow - isFollowing
Ignore - isIgnoring
Block - isBlocking

Like - isLiking
Eat - isEating

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

likes

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 😄

DirectContainer

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)

@csarven
Copy link
Member

csarven commented Aug 30, 2015

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 oa:motivation (e.g., oa:replying) for the threaded entries e.g., http://csarven.ca/webmention#interactions . Depending on context, I can just as easily create my own motivations e.g., concept:repost-of, concept:blocked, concept:likes (which are a oa:Motivations) , or re-use existing ones.

A recent discussion on is/has prefixes is also here: w3c/web-annotation#70

@jasnell
Copy link
Collaborator Author

jasnell commented Oct 7, 2015

Withdrawing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants