- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Thu, 3 Jul 2014 22:45:01 +0200
- To: <public-hydra@w3.org>
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] http://richard.cyganiak.de/blog/2011/03/blank-nodes-considered-harmful/ > [2] http://milicicvuk.com/blog/2011/07/14/problems-of-the-rdf-model-blank-nodes/ > [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 @markuslanthaler
Received on Thursday, 3 July 2014 20:45:30 UTC