W3C home > Mailing lists > Public > semantic-web@w3.org > September 2014

Re: genid example from RDF1.1 is bad

From: <henry.story@bblfish.net>
Date: Wed, 24 Sep 2014 16:03:49 +0200
Cc: David Booth <david@dbooth.org>, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, Semantic Web <semantic-web@w3.org>
Message-Id: <E37F2551-E728-4FA1-B355-4889E82EEC2E@bblfish.net>
To: Soiland-Reyes Stian <soiland-reyes@cs.manchester.ac.uk>

On 24 Sep 2014, at 15:41, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote:

> This is a very interesting discussion.
> 
> 
> I believe that unless you are describing truly existential statements
> ("There exist some foaf:Person which has 2 heads")  or get bnodes from
> inline short-hand syntax like RDF lists in Turtle, then one should
> avoid BNodes altogether.
> 
> As it can be difficult to decide on an authority from where to mint
> URIs - particularly in a mobile/desktop client/server situation - I
> have often resolved to using urn:uuid URIs like:
> 
>   <urn:uuid:962906b1-d962-4868-a375-605503fbd654>
> 
> 
> The only downside I can see to this is that you can't
> deterministically de-skolemize (can be solved by making a new URI
> scheme as you suggest). When is that needed?
> 
> Your proposed bnode: scheme has one major flaw - it assumes that bnode
> identifiers in the referenced document remains the same. There is
> nothing stopping the server from producing a document with _:b01 and
> _:b02 being swapped around in the very next second - and indeed this
> happens in many implementations today.
> 
> One way I can see around this would be to include a hash (e.g. sha1)
> of the parsed presentation (or E-Tag), the URI and bnode identifier..
> True - it would mean that different representations of the same bnode
> would give different identifiers (due to content negotiation) - but at
> least you would not get unintended overlaps.

I agree that there is a use case to attach the bnode to the representation.
That is why I had the {etag} field in the bnode URN scheme I proposed :-)
 
  bnode:{domain}:{path}:{etag}:{identifier}

If we provide the path, then an etag should suffice, as etags + path give one 
a unique resource version.

Note: I did not spend a lot (any?) of time looking in detail at the URN specs recently.
So of course one would have to look at what is actually feasible withint the constraints
of URNs.

Here are some additional criteria that should be followed:

1- a bnode URN for a document should easily be used in a prefix 
  so that one document would only need one @prefix bn: <bnode:....:> .
  statement, for all the bnodes to be able to be declared with that prefix.
  Also future serialisations could then perhaps provide a bnode URN syntax
  such as  
 
   =:etag12 foaf:name "Joe"

  just as we have now

  _:bnode foaf:name "Joe" 

  in Turtle now.

2. [to fill out]

Social Web Architect
http://bblfish.net/
Received on Wednesday, 24 September 2014 14:04:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:53 UTC