- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Thu, 3 Jul 2014 12:25:49 -0700
- To: Ruben Verborgh <ruben.verborgh@ugent.be>
- Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, public-hydra@w3.org
On Jul 3, 2014, at 8:58 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote: > Hi Markus, > >> </alice> hydra:collection </alice/friends> . >> </alice/friends> a hydra:Collection ; >> hydra:manages [ >> hydra:property schema:knows ; >> hydra:subject </alice> . >> ] . > > Great, clearest option I think. > Happy we got something good. I'm +1 too. >> I would like to ask if >> anyone has any concerns or objections against this proposal. > > No concerns with the things that are defined; > some open questions about the things that are not. > > Most importantly, what is the thing that is the object of hydra:manages? > Or, more strictly, what is its domain? > How will it evolve in the future? While it would be good to define the range of hydra:manages, and make sure subject/property/object have that thing in their domain, in practice, I don't expect serializations to include it, and clients shouldn't depend on that type being asserted. Regarding giving it an IRI, vs using a BNode, I think this comes down to publisher preference. I don't have any problems using a BNode for such a block. If a publisher wants to give it an IRI, I have no problem with that. However, a best practice should be that a Collection serialization include the hydra:manages block inline, rather than requiring an additional GET. Gregg > Those are things that can be dealt with later; > I just wanted to bring them up as future TODOs. > > Thanks, > > Ruben >
Received on Thursday, 3 July 2014 19:26:19 UTC