W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2002

Re: The semantics of blank nodes

From: <MDaconta@aol.com>
Date: Thu, 14 Nov 2002 12:12:47 EST
Message-ID: <10d.1ae6b5b1.2b05338f@aol.com>
To: fmanola@mitre.org, www-rdf-interest@w3.org
In a message dated 11/13/2002 2:47:52 PM US Mountain Standard Time, 
fmanola@mitre.org writes:

> >The point I disagree with above is when you say, "the blank node
> >represents an address" because no where do we connect it with
> >the concept (or Class) "Address".  As you say below,
> >this could be resolved if we specify a type and then that clears up the
> >semantic confusion.  I would guess that a blank node then really just
> >means "thing" (unless we type it).
> This depends on what "means" means.  If I create a resource, or a blank 
> node, I get to decide what it means, and anyone who understands my 
> vocabulary or the structure I'm using (through some means or other) 
> might share that meaning (e.g., they might understand that the thing at 
> the end of my "address" property was an address).  As far as 
> machine-interpretable meaning is concerned, though, *any* resource, 
> blank node or not, just means "thing" unless you provide some additional 
> information about it (like a type, which of course the machine has to 
> understand too).  That is, it isn't just blank nodes that have to be 
> typed to have this meaning:  resources with URIs do too.  URIs don't 
> carry meaning with them (or at least, they aren't supposed to be 
> interpreted as carrying meaning in RDF).

Understand.  Identity and typing are orthogonal.  Except where a well-known
identity conveys well-known semantics but that cannot be assumed.  

This brings up a tangential issue on the semantics of a URI identity
beyond uniqueness.  Has there been any thought in RDF Schema to creating
a utility property to express that a URI is retrievable (same issue as 
namespace retrieving an RDDL document).  Or is it better to use a urn scheme?
I am not that familiar with the urn scheme but in your example in the primer:

 1. <?xml version="1.0"?>
 2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 3.             xmlns:dc="http://purl.org/dc/elements/1.1/"
 4.             xmlns:ex="http://www.example.org/terms/">
 5.   <rdf:Description rdf:about="http://www.example.org/index.html">
 6.        <ex:creation-date>August 16, 1999</ex:creation-date>
 7.        <ex:language>English</ex:language>
 8.        <dc:creator>
 9.           <rdf:Description 
10.           </rdf:Description>
11.        </dc:creator>
12.   </rdf:Description>
13. </rdf:RDF>
How is an RDF application processing this to know that the URI on
line 5 is an accessible web page but the URI on line 9 is just an identity?
Especially when both specify http: as the protocol.  I know this is off topic
but some pointers on this would be helpful.  One way I can think of is
to add the <dc:type> property to the web page and then you can assume 
anything without a dc:type is just an identity (not a foolproof technique 
the dublin core folks add a dc:type value for "identifier" or "name").

> <snip />
> You generally make statements about classes of things in schemas.  So 
> the place to say that the property <address> has a range of class 
> <Address> would be in a schema.  In the original example, though, I 
> wanted to represent the specific address of a specific staff member. 
> That means that the thing on the end of Joe's <address> (or <livesAt>) 
> property needs to be something that represents an individual address, 
> not the class of addresses.  So I need to use either a blank node, or a 
> resource with a URI.  Either way, adding a type property would convey 
> more information about that instance (to someone or something who 
> understood what class <Address> meant).

Agreed.  In terms of best practice, it may be good to mention that in 
the primer.

Best wishes,

 - Mike
Michael C. Daconta
Director, Web & Technology Services
Received on Thursday, 14 November 2002 12:13:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:43 UTC