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

On 3 Jul 2014 at 23:54, McBennett, Pat wrote:
> Markus Lanthaler wrote on July 03, 2014 9:45 PM:
>> 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 :) !

If you create and describe an API, you can of course avoid them everywhere if you want to do so. But you can't expect that if you consume other people's APIs and descriptions.


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

Yeah, graph normalization is one of the things that is difficult if you have blank nodes but often you can easily sidestep such issues by signing/hashing the complete document instead of the abstract graph. Btw. we actually worked on a graph normalization algorithm in the JSON-LD Community Group [2] but I personally wasn't really involved in that effort.


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

By "naming" he meant "typing" it AFAICT.


>>> 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 :) !).

Graph normalization is indeed made much more difficult if you there are blank nodes but since we can't forbid them completely, any graph normalization algorithm will have to deal with them anyway. Furthermore, I think it is important to differentiate things that have a stable IRI and things that are somewhat transient information. As soon as you give things a IRI, you should prepare that people will use that IRI meaning that you should keep it up which often is more difficult than one might think... Cool URIs don't change and all that :-)


 
[1] http://2014.eswc-conferences.org/sites/default/files/papers/paper_106.pdf
[2] http://json-ld.org/spec/latest/rdf-graph-normalization/


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 7 July 2014 16:41:42 UTC