Re: genid example from RDF1.1 is bad

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

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

perhaps other use cases can be put together to find a wider audience, so
that it ends up becoming available.

I would say that from the web architecture point of view the current solution
is unacceptably bad, and a new URN space is much much better. 

There are URN schemes for books, and there will be a lot more bnodes than books, so
I don't see the problem.

Henry


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

Social Web Architect
http://bblfish.net/

Received on Wednesday, 24 September 2014 14:18:29 UTC