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

> -----Original Message-----
> From: Markus Lanthaler [mailto:markus.lanthaler@gmx.net]
> Sent: Thursday, July 03, 2014 9:45 PM
> To: public-hydra@w3.org
> Subject: RE: Call for consensus on collection design (ISSUE-41)
> 
> 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).
> 

Aha - not much chance of me avoiding them then :) !

> 
> > 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.
> 

The 'benefits' I saw were simply avoiding all the issues I thought *still* existed in relation to BNodes. I know you state that those issues are largely resolved (or at least helped) by JSON-LD and property paths, but even at the ESWC 2014 conference in Greece last month, a couple of references were made to the problems of normalization when dealing with BNodes, specifically in relation to hashing a set of triples for security signatures (in the 'Best Paper of the Conference' [1]).

And I interpreted Rubens TODO proposal as directly related too, since he also wishes to 'name' the 'hydra:manages' node, but I guess his motivations are different.

> 
> > 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.
> 

Ok, fair enough, I'll certainly defer to your vastly broader experience on all this - thanks for the feedback. I guess I was overly influenced by all the bad-press BNodes seem to have gotten historically (although I can't help still being niggled by the very recent statement from the authors of the 'Trusty URIs' paper: '...the difficulty of handling blank nodes...' on page 5 :) !).

[1] http://2014.eswc-conferences.org/sites/default/files/papers/paper_106.pdf


> 
> > [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 21:55:25 UTC