- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Tue, 28 Jan 2003 09:07:43 -0500 (EST)
- To: www-rdf-comments@w3.org
The handling of blank nodes is still problematic in the LCC version of the
RDF Syntax document.
The intent is clear. Each nodeElement that does not otherwise get a
subject is given a blank node identifier as a subject. The string-value of
this blank node identifer is to be different from the string-value of every
other blank node identifier resulting from the parsing of the RDF/XML
document.
However, the document does not follow this intent.
First, in section 5.2, the document only says that ``generated blank node
identifiers must not clash with any blank node identifiers from rdf:nodeID
attribute values.'' This allows
<rdf:RDF xmlns:rdf="..."
xmlns:ex="...">
<rdf:Description>
<ex:foo>
<rdf:Description />
</ex:foo>
</rdf:Description>
</rdf:RDF>
to generate the following triple
_:x <ex:foo> _:x .
Second, a blank node identifier in the linear representation of an RDF
Graph is generated from the string-value of the subject of the event. For
events that come from nodeElements that have an rdf:nodeID attribute, this
value is determined in 7.2.11 as follows
``If there is an atribute a with a.URI=rdf:nodeID,
then e.subject := bnodeid(identifier:=a.string-value)''
From 6.1.7 the string value of this subject is the concatenation of "_:"
and the value its identifier accessor, which is determined during the
construction of the event ``by giving a value for the identifier accessor''.
This means that
<rdf:RDF xmlns:rdf="..."
xmlns:ex="...">
<rdf:Description rdf:nodeID="HI">
<ex:foo>
<rdf:Description rdf:nodeID="BYE" />
</ex:foo>
</rdf:Description>
</rdf:RDF>
MUST generate the following triple
_:HI <ex:foo> _:BYE .
Therefore the wording in 5.2 ``One method would be to add a constant prefix
to all the rdf:nodeID attribute values'' is not a potential solution to the
blank node identifier clashing problem, as it clashes with the required
method of determining the string-value of such blank nodes.
Received on Tuesday, 28 January 2003 09:17:53 UTC