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

On Monday, June 02, 2014 7:46 PM, Ruben Verborgh wrote:
> Hi Gregg,
> 
> >> Hence, the following is sufficient (1):
> >>   </alice/friends> :manages [
> >>       :subject </alice>;
> >>       :property schema:knows;
> >>   ].
> >> (where "manages" might not be the best term).
> >
> > This is pretty much what Markus and I came up with, and makes manages
look 
> > like LD Fragments, to me.
> 
> Jup, this looks like a basic Linked Data Fragment.
> 
> >> Terminology suggestion (just to help us think):
> >>   </alice/friends> :isCollectionOf [
> >>       rdf:type :CollectionItemTemplate;
> >>       :subject </alice>;
> >>       :property schema:knows;
> >>   ].
> >> (Note that the rdf:type could be hidden.)
> >
> > I don't see that isCollectionOf does more than manages
> 
> It doesn't to anything more, I just tried to make "manages" more
tangible/concrete.
> (cfr. components named "Manager" in Java, what do they do? :-)

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. 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. Think, e.g., of an HTTP LINK/UNLINK operation which can be used
to manage certain subject/property pairs. That's also the reason why I'm
somewhat hesitant to set manage's domain to Collection.


> > I also don't see what a CollectionItemTemplate is
> 
> An attempt to identify what the blank node is/means.
> To me, that node is a template of an item in the collection.
> 
> Note that we could really use rdf:subject and rdf:predicate here
> (which coincidentally comes very close to basic LDFs);
> the range _and_ domain would work.

As Gregg noted in a different mail [1] (I'm on a plane, so perhaps he
already responded himself in the meantime) using rdf:subject etc. would mean
that the whole thing is an rdf:Statement:

    "Don't thing rdf:subject works, as it's domain is rdf:Statement, and I
don't think
     we want to invoke Reification, so best stick with
hydra:property/subject."


> > and even though property/subject/object should have a domain, it should
probably be
> more generic, such as IndirectResourceManager
>
> Exactly. CollectionItemTemplate would thus be a subclass of
IndirectResourceManager,
> to allow for other selections besides triple patterns.
> But we'll need to come up with better names.

I think these properties are so generic that a domain (at least an
rdfs:domain) is counterproductive as it inhibits reuse in different
scenarios... but we could of course hint the type by using
schema:domainIncludes.


> > but in common practice it would be omitted.
> 
> Absolutely.
> (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?


> >> The semantics would then mandate be that:
> >> - for a given template, minimum 1 and maximum 2 components should be
used
> >> - the collection contains all items of the dataset that match the
template (possibly paged)
> >
> > +1, although subject and object may be inferred from other statements.
> 
> Fair enough, but dangerous for lighter clients that don't do inferences.

Yep. Better to state those things explicitly.. it's cheap and makes
everyone's life easier.


[1]
http://www.w3.org/mid/2A08989E-9B18-434C-84C7-64A3144F8FE9@greggkellogg.net


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 3 June 2014 18:40:05 UTC