Re: genid example from RDF1.1 is bad

And lacking an etag you can generate a fresh uuid. Then the URIs are
unique, yet have a resolvability option.

Although I still don't like the syntax (it has too many things missing
from the original URI - what about query and ports arguments? Or the
original scheme? Also it's very long..) I can agree that it is an
option that more clearly show that it is a bnode - you would not feel
the need (or normally have the ability to) resolve it - as you would
not find any additional information anyway.

Introducing a brand new URI scheme only for BNodes in RDF, and only to
save having to parse a path argument for a client that cares about
network efficiency (which would parse them anyway to avoid ../../
etc), does however seem a bit overkill to me.

On 24 September 2014 15:03,
<> wrote:
> On 24 Sep 2014, at 15:41, Stian Soiland-Reyes <> 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

Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Wednesday, 24 September 2014 14:14:38 UTC