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, henry.story@bblfish.net
<henry.story@bblfish.net> wrote:
>
> 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/
>



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718

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