- 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