RE: How to avoid that collections "break" relationships (ISSUE-41)

On Friday, June 06, 2014 10:22 AM, Ruben Verborgh wrote:
> > IME, a lot of people (outside the SemWeb community) find traversing
links in
> > the reverse direction "unnatural" and "hacky".
> 
> But that's not what it is.
> We can't change the RDF model.

I agree, nevertheless people get confused about this. Introducing a
mechanism to also support a direct forward link doesn't mean at all that we
are changing RDF. We are just giving more explicit information to the client
(yeah, it is redundant information but it might help some simpler clients).

Side note: the "rev" attribute to express reverse links has been in HTML
from the very beginning. As it wasn't really used and often lead to errors,
it has been obsoleted in HTML5 [1].


> > it indicates what kind of triples can be found in the collection.
> 
> Agree. So a term like "is collection of" could also work?

Sure, even though I personally don't like this specific term very much:

  /alice/friends isCollectionOf [
      subject /alice
      property schema:knows
  ]

This looks a bit weird for me. If just naming things would be easier :-)


> Nothing in the term description requires the word "manages".
> 
> The case I'm trying to make here is:
> "manages" is a lot vaguer than (for instance) "is a collection of".
> There can be many ways in which one resource manages another,
> hence the thousand different semantics of Manager components in Java.

Right. So, if we would like to describe that an HTTP LINK operation supports
the creation of certain links, how would we describe that? We would need to
introduce a separate property to do so, right? With "manages" we could
simply say

  xy a Operation
    method LINK
    manages [
        subject /alice
        property schema:knows
    ]
    expects schema:Person

It is a tradeoff, do we want to keep the vocabulary small at the cost of
vaguer names or do we prefer to have more explicit names at the cost of a
bigger vocabulary? I generally lean towards the former.


> > First of all, it should tell clients why they might or might not be
> > interested in a collection. We might decide to reuse it at a later point
to
> > describe operations in more detail. It could for instance also be used
to
> > indicate that an HTTP Link operation can be used to manage certain
> > subject/property pairs.
> 
> But that's not aligned with what you wanted to express above:
> 
> > it indicates what kind of triples can be found in the collection.

Why not? Doesn't the information about "what kind of triples can be found in
the collection" help clients to decide "why they might or might not be
interested in a collection"?


> This reinforces my believe we're actually looking for :isCollectionOf
> of something similar.
> It's really those declarative semantics we need here,
> not the operational semantics.

Does this imply that you would like to have a different property for the
operation I outlined above?


Summarized, I think we found a pattern for collections which everyone can
live with. AFAICT, there are three open issues:

  1) Do we want to introduce something like hasCollection?
  2) Should we rename "manages"?
  3) Should we reuse rdf:subject/predicate/object instead of introducing
hydra:subject/property/object (predicate or property?)


Have a nice weekend,
Markus



[1]
http://www.w3.org/TR/2014/CR-html5-20140429/obsolete.html#non-conforming-fea
tures


--
Markus Lanthaler
@markuslanthaler

Received on Friday, 6 June 2014 16:51:39 UTC