W3C home > Mailing lists > Public > semantic-web@w3.org > October 2010

Re: Is there a systematic method for naming bnodes?

From: Nathan <nathan@webr3.org>
Date: Mon, 04 Oct 2010 13:33:45 +0100
Message-ID: <4CA9C9A9.7090804@webr3.org>
To: Pat Hayes <phayes@ihmc.us>
CC: Melvin Carvalho <melvincarvalho@gmail.com>, Semantic Web <semantic-web@w3.org>
Pat Hayes wrote:
> Well, the very idea of a *blank* node is one that has no name, so this idea seems to be rather against the spirit of the bnode, so to speak. Of course, concrete syntaxes do use bnode identifiers, but these are really just an artifact of the need to represent a graph in a linear character sequence. These bnode identifiers are purely local to the graph. 

Hmm, does this mean then that often people are using blank nodes as if 
they have a name, and should this be avoided?

for example:

   _:x1 rdf:type ex:Person ; rdfs:label "Nathan"@en .
   :Bob :knows _:x1 .
   :Sue :knows _:x1 .

as far as I know many RDF processors (and indeed common understanding) 
would treat this as if to say that: "The person that Bob knows called 
Nathan is the same person that Sue knows called Nathan"

When it appears that correct interpretation would be "Bob knows a person 
call Nathan and Sue knows a person called Nathan"

Thus, am I mistaken, or would it be preferably to write:

   _:x1 rdf:type ex:Person ; rdfs:label "Nathan"@en .
   :Bob :knows _:x1 .
   _:x2 rdf:type ex:Person ; rdfs:label "Nathan"@en .
   :Sue :knows _:x2 .

or even:

   :Bob :knows [ a ex:Person, rdfs:label "Nathan" ]
   :Sue :knows [ a ex:Person, rdfs:label "Nathan" ]

And in the case where the person they know is the same person called 
Nathan, then to give that person a proper name, a URI reference.

I guess, more tersely, should a blank node reference '_:' ever appear 
more than once in the object position of a triple? and if it does should 
parsers create a graph which links both subjects to the same blank node, 
or produce two different ones?


Received on Monday, 4 October 2010 12:41:11 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:20 UTC