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

Hi Markus,

>> [Requiring a forward link] might be more straightforward,
>> but is this something you can spec?
> 
> Why not? We could include something like
> 
> Even though the "manages" information provides enough information to find
> the collection as long as is included in the referencing document, simple
> clients may have problems to traverse reverse links. Thus, the referencing
> entity SHOULD (MUST?) also reference the collection directly using the
> "hasCollection" property.

SHOULD, perhaps.
MUST makes little sense if Hydra is a vocabulary and not a client/server contract.
(That's why I wondered whether it can be spec'ed.)

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

> It may also be that it is much more efficient (performant) to follow the
> forward link instead of the reverse links as there are much fewer of them.

I don't think that this should influence the design of the vocabulary;
there's no need to work around perceived weaknesses of the RDF model.
(Plus, performance won't be too different.)

We could allow the extra links…
but it gets problematic if people rely on them.
(JSON-LD framing might be a solution here for those who do.)

>> Nah, "manages" is really vague. I could think of several other interpretations.
> 
> Sure, words are often vague if you look at them in isolation.

Even in context, I meant.

> it indicates what kind of triples can be found in the collection.


Agree. So a term like "is collection of" could also work?

> In a lot of cases, the collection also affords
> the creation of new triples of that type or their deletion.

So it's still a collection?

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.

>> Reuse is not necessarily an advantage.
>> (cfr. rdfs:seeAlso, which can be reused everywhere).
> 
> IMO you have to distinguish between reuse within the confines of a
> vocabulary, and reuse in general. Within a single vocabulary, it makes a lot
> of sense IMO because all uses can be easily documented and retrieved by
> dereferencing that concept's URL.

But that doesn't really change the point:
if we had a hydra:seeAlso property,
we could reuse it everywhere within the vocabulary.
We should strive to find the right granularity
so that the predicates still have sufficient meaning
for machine clients to do useful things with it.

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

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.

> Yes. Let's try to not extend the vocabulary just for the sake of it

+1, but let's make sure that the concepts carry specific enough semantics.

Ruben

Received on Friday, 6 June 2014 08:22:32 UTC