- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Wed, 24 Sep 2014 14:41:57 +0100
- To: "henry.story@bblfish.net" <henry.story@bblfish.net>
- Cc: David Booth <david@dbooth.org>, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, Semantic Web <semantic-web@w3.org>
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.
Received on Wednesday, 24 September 2014 13:42:46 UTC