- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Tue, 3 Jun 2014 20:39:28 +0200
- To: <public-hydra@w3.org>
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