W3C home > Mailing lists > Public > semantic-web@w3.org > December 2012

Re: Well Behaved RDF - Taming Blank Nodes, etc.

From: Hugh Glaser <hg@ecs.soton.ac.uk>
Date: Wed, 12 Dec 2012 18:23:28 +0000
To: Pat Hayes <phayes@ihmc.us>
CC: David Booth <david@dbooth.org>, semantic-web <semantic-web@w3.org>
Message-ID: <387E72E216DF1247A2F8ED4819C93BA71E37415C@UOS-MSG00041-SI.soton.ac.uk>
OK, blank nodes :-)
Hi Pat,
On 12 Dec 2012, at 17:43, Pat Hayes <phayes@ihmc.us>
 wrote:

> 
> On Dec 12, 2012, at 9:01 AM, David Booth wrote:
> 
<snip>
>> A Well-Behaved RDF graph is an RDF graph that can be serialized 
>> as Turtle without the use of explicit blank node identifiers. 
>> I.e., only blank nodes that are implicitly created by the 
>> bracket "[ ... ]" or list "( ... )" notations are permitted. 
> 
> That is too restrictive. There is a real need to be able to describe things such as "Joe's father" or "a woman in a red dress" which are naturally phrased as bnodes with identifying descriptors attached to them. 
> 
I don't think I understand, or I may disagree :-)
Why is the node for "Joe's father" any different in character from the node for "Joe"?
(Assuming this is my data I'm publishing, and I'm not reusing external URIs.)
I had to make up a URI for Joe; it isn't a great hardship to ask me to make one up for his father as well.
The only difference between the two resources seems to be that you have a property for one that you don't have for the other (perhaps "name" in this case).
That doesn't seem a great way to choose what URIs you decide to mint and publish.
And the downside (apart from any processing problems that David might have), is that no-one can make statements about the resource I am referring to as Joe's father.
The only reason (apart from laziness in thinking up a URI) I can see for a bnode here is if I want to prevent people making statements about the resource, which is surely not something we want to encourage in a simple RDF profile description.

Cheers
Received on Wednesday, 12 December 2012 18:24:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:38 UTC