W3C home > Mailing lists > Public > public-hydra@w3.org > July 2014

Re: Call for consensus on collection design (ISSUE-41)

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Thu, 3 Jul 2014 12:25:49 -0700
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, public-hydra@w3.org
Message-Id: <DFA8BCE9-98BD-408B-9F38-802E990D39A6@greggkellogg.net>
To: Ruben Verborgh <ruben.verborgh@ugent.be>
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.


> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC