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

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

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Thu, 3 Jul 2014 22:45:01 +0200
To: <public-hydra@w3.org>
Message-ID: <009901cf96ff$aa43f140$fecbd3c0$@gmx.net>
On 3 Jul 2014 at 18:11, McBennett, Pat wrote:
> I really like this proposal (so +1), but my only concern (and this is
> certainly not an objection), is that currently all our RDF is 'clean'
> (in that I have literally no blank nodes), and ideally I'd like to
> keep it that way, while of course still supporting Hydra collections.

Most operations are blank nodes, so are most IriTemplates and
SupportedProperties (at least the way I use them).

> I know I could easily introduce a named node myself (or skolemize),
> but would it make sense for the spec to at least allude to the
> controversy around blank nodes [1], [2], [3], [4], [5], and offered a
> non-normative approach (i.e. a convention) for those who wish to avoid
> them as much as possible (for example, the use of
> '/alice/friends/meta' below where the use of '/meta' is a simple
> convention to avoid blank nodes). Of course for those who don't care,
> allowing the use of blank nodes is fine too.

What would be the benefit of doing so? A client doesn't care whether it's
/meta or /managesBlock. I think it would just complicate the spec.

> Or is the concensus that this would just be cluttering the specification,
and blank nodes are
> 'fine really' (as seems to be the consensus from the JSON-LD group [6])?

In my opinion they are really fine. Most of the things you reference have
been written before things like JSON-LD or SPARQL property paths existed.
They make it very simple to work with blank nodes in most cases.

> [1]
> [2]
> [3] http://www.w3.org/2009/12/rdf-ws/papers/ws23
> [4] http://aidanhogan.com/docs/bnodes.pdf
> [5] http://manu.sporny.org/2013/rdf-identifiers/
> [6] https://github.com/mcollina/levelgraph-jsonld/issues/8

Markus Lanthaler
Received on Thursday, 3 July 2014 20:45:30 UTC

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