RE: Problem with auto-generated fragment IDs for graph names

On Wednesday, February 20, 2013 11:16 AM, Andy Seaborne:

> I proposed the *parser* generate fragments or URIs and in fact label
> generation is what happens in your example ... _:c14n1, _:c14n2 which
> came from somewhere.  They are generated.  Use <#g1>, <#g2>.

What if that fragment is already in use? Relabeling blank nodes is trivial
as they are transient by definition. You *cannot* do the same with fragment
IDs without changing the data.

In general, I find all the proposals suggesting to mint IRIs with a
recognizable structure at odds with the AWWW. IRIs should be opaque. See:
http://www.w3.org/TR/webarch/#uri-opacity

I still believe that bnode skolemization (as it is currently done and
specified) is a very bad idea, but that's a different story which we
shouldn't discuss here.

 
> Create one ... it's purely internal as you said.  The choice does not
> matter.  (Aside from the ukkiness, because you use bNode identifiers -
> use the SAME one for all baseless documents!)  Your use of bNode
> identifiers is equivalent to a base URI of "_:" because as Markus said,
> it is about navigation of the local document.

That was an entirely different discussion which had to do with whether we
need to specify that bNode IDs denote the graph or not.


> > Skolemization doesn't work because the IDs must be generated in a
> > decentralized manner when normalizing, there is no base IRI, and if
> the
> > IDs picked between two implementations for the same data differ, the
> > digital signatures won't match.
> 
> What is the scope of the normalization?  The bnodes identifiers are
> local - the fragments are local.

Fragments are not local. RDF does not support relative IRIs. All IRIs have
to be absolute and, and such, represent global identifiers. As soon as you
want to store such a document in a standard quad store it will bite you. On
the contrary, if you use blank node identifiers, the store can relabel the
colliding identifiers automatically.



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 20 February 2013 12:30:12 UTC