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

On Jun 6, 2014, at 9:51 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

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

It doesn't look particularly weird, IMO, but does bind it to collection, where we want to keep it more generic. IMO, hydra:manages is a good term, but we could consider something like hydra:ldFragment, which is really what it is, not that it conveys the specific purpose of the entity. I'd say just keep with hydra:manages.

>> 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?

+1

>  2) Should we rename "manages"?

- 0.1

>  3) Should we reuse rdf:subject/predicate/object instead of introducing
> hydra:subject/property/object (predicate or property?)

-1: a manages block is not a reified statement, and I don't see how this aids the use case.

Gregg

> 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 17:23:21 UTC