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

Hi Ruben,

I'm going to consolidate my response to both of your mails into a single
reply.

On Thursday, June 05, 2014 1:54 PM, Ruben Verborgh wrote:
> >> hydra:hasCollection with "property" and "subject" seems better;
> >> it allows clients to derive that (all?) "allice :knows" triples will be
there.
> >> However, "hasCollection" is unnecessary in that case,
> >> because "subject" already gives the needed information.
> >
> > That's true. But I think it still makes a lot of sense to include this
> > forward link, i.e., /alice --[hasCollection]--> Collection instead of
just
> > having the indirect reverse link /alice
<--[subject]--(bnode)<--[manages]--Collection.
> >
> > It's simply much more straightforward to find it that way, especially if
you
> > don't use a triple store.
> 
> It 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.

Obviously some more wordsmithing would be needed to make this clearer. But
I'm sure you get the idea.


> The semantics are already there without the extra link.
> Clients just have to do the effort then (and it's not that hard).
> In other words, we should not treat "subject" links as stronger links
> than "object" links.

IME, a lot of people (outside the SemWeb community) find traversing links in
the reverse direction "unnatural" and "hacky".

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.


On Thursday, June 05, 2014 3:35 PM, Ruben Verborgh wrote:
> > It will always be a trade-off but generally I prefer things that can be
> > reused in various scenarios. If possible, we should keep the set of
concepts
> > as small as possible and reuse them in different scenarios. I think it
is
> > quite obvious (IMO, anyway) what "manages" means when it appears on a
Collection.
> 
> Nah, "manages" is really vague. I could think of several other
interpretations.

Sure, words are often vague if you look at them in isolation.


> But before deciding on a word, let's maybe think what we mean to say?
> What is the predicate supposed to express?

When manages is used on a Collection, it indicates what kind of triples can
be found in the collection. In a lot of cases, the collection also affords
the creation of new triples of that type or their deletion.


> > The advantage of such a generic term is that we could for
> > example reuse it to describe other things in the future as well, e.g.,
on Operations.
> 
> 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.


> The question we need to ask ourselves is:
> what should clients be able to do with this property?

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.


> > I think these properties are so generic that a domain (at least an
> > rdfs:domain) is counterproductive as it inhibits reuse in different
scenarios.
> 
> Generic is only fine to a certain extent.
> We do want machines to derive some value of of the properties.

Right. In your opinion, how exactly do we decrease the value of these
properties by, e.g., not setting a specific range?


> >> (But still, the blank node needs to be "something", to help us think
about it.)
> >
> > Good point. But does a machine need it as well?
> 
> Maybe not. the spec does, though ;-)

Yes. Let's try to not extend the vocabulary just for the sake of it (I'm not
suggesting that you proposed that, quite the contrary, you always ask for
what it enables clients to do).


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 5 June 2014 22:00:56 UTC