Re: A modest proposal concerning blank nodes.

On 03/03/11 10:39, Andy Seaborne wrote:
>>> We can also require that all RDF processors be able to input
>>> existing RDF notations which have syntactic forms for blank node
>>> identifiers, either by storing the RDF in this form or by
>>> skolemizing it on input. This sets up a backward-compatible
>>> situation which is strongly biassed to eliminate blank nodes as
>>> rapidly as possible from actual deployed RDF. We can even call
>>> these tag-labelled nodes "blank nodes" if we like, with only a tiny
>>> change to the current RDF concepts specifications.
>>>
>
> With this proposal, what happens when software does:
>
> parse(GET /foo)
>
> parse(GET /foo)
>
> where GET /foo returns "_:x :p 123 ."
>
> Same label, same g-box, same g-snap, different g-text.
>
> (not that you can tell it's the same g-snap (better: g-box state): it
> might be different g_box states that serializes the same but it was
> different at a time when we weren't looking).
>
> Is that the same bnode or not?
> (One triple or two?)
>
> Compatibility: it's two.
>
> Andy

Not all bNodes have identifiers in the syntax.

In Turtle,

[] :p (1 2) .

which is in triples:


_:b2 rdf:first 1 .
_:b2 rdf:rest _:b3 .
_:b3 rdf:first 2 .
_:b3 rdf:rest rdf:nil .

although they may not come out in that order and so may have different 
labels:

RIOT produces

_:b0 rdf:first 1 .
_:b0 rdf:rest _:b1.
_:b1 rdf:first 2 .
_:b1 rdf:rest rdf:nil .
_:b2 :p _:b1 .

rapper produces:

_:genid2 rdf:first 2 .
_:genid2 rdf:rest rdf:nil .
_:genid3 rdf:first 1 .
_:genid3 rdf:rest _:genid2 .
_:genid1 :p _:genid3 .

	Andy

Received on Thursday, 3 March 2011 15:09:27 UTC