W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2003

Re: other rdf:nodeID name thoughts

From: Garret Wilson <garret@globalmentor.com>
Date: Sun, 19 Jan 2003 15:56:29 -0800
Message-ID: <3E2B3B2D.6050300@globalmentor.com>
To: Bill Kearney <wkearney99@hotmail.com>
CC: www-rdf-comments@w3.org

Thanks for the reply, Bill. Let me give a more concrete explanation.

I'm editor of the XPackage specification ( www.xpackage.org ), which is 
be used for describing such information as an HTML document's MIME type, 
the files that need to be transmitted along with that document, its 
stylesheets, its images, its image fallback information, etc. People in 
the Open eBook Forum have had huge RDF backlash (the issue is still 
being debated), in part because of the special syntax RDF requires. Many 
think that forcing users to think about some deeper RDF framework will 
impede acceptance of the next OEB packaging specification.

I've managed to get XPackage so that it's pretty intuitive to be used 
for OEB packaging without a knowledge of RDF. And even non-RDF-aware 
eBook authors can live with an rdf:resource sprinkled here and there in 
the OEB package file---it's intuitive to explain even to non-computer 
users (or a tool implementor) that the book and each of its images are 
"resources" that go into building the entire book. But "nodes"? Once we 
get past the lymphatic system-related questions, explaining a directed 
graph representation of their book assumes users know something about 
graph/tree/network theory and terminology.

I guess it comes down to the fact that even if RDF didn't exist, a book 
would be a resource, as would be an image, as would be a stylesheet, 
etc. But these things only become "nodes" when interpreted in light of 
the RDF framework---specifically the graphical representation of that 
framework.

What we're really talking about when discussing rdf:nodeID is a 
temporary identifier that allows relationships between resources to be 
described. The resources participating in those relationships become 
"nodes" only when considered in the context of a graph. If only 
"temporary identifier within the scope of this document for the purpose 
of describing relationships" weren't so long, it might be a fitting 
attribute name. ;)

Cheers,

Garret

Bill Kearney wrote:

>Is this any more complicated that using the word 'resource'?
>
>I'd have to think that opening the door into graph theory by using the nodeID
>name would be a *good* thing.  If just for the purpose of letting folks know
>there's a larger set of concepts out there that might be worth investigating.
>We could just as easily call the thing rdf:hamsandwich.  But we're not trying to
>get a deli schema going so the use of that wording wouldn't be all that helpful.
>
>Not getting into graph theory is one thing.  Taking steps to blindly lead people
>away from it is another entirely.  Once people grasp what the terms mean it's
>not really all that important what they're called.
>
>I dislike 'local' in that it raises questions like server/client-side localness,
>binding and what not.  Likewise for 'internal'.
>
>-Bill Kearney
>
>----- Original Message -----
>From: "Garret Wilson" <garret@globalmentor.com>
>To: <www-rdf-comments@w3.org>
>Sent: Sunday, January 19, 2003 2:37 PM
>Subject: other rdf:nodeID name thoughts
>
>
>  
>
>>I'm thinking of specifications built on top of RDF that may try to hide
>>technical details of RDF from the user. rdf:about and rdf:reference did
>>that somewhat by talking about relationships between *resources*, but
>>the name "rdf:nodeID" presupposes a knowledge of some graphical
>>representation of RDF---relationships between nodes in a graph.
>>
>>Has anyone proposed other names for rdf:nodeID just to be user-friendly,
>>such as one of the following?
>>
>>rdf:localID
>>rdf:internalID
>>rdf:tempID
>>
>>The only one I really like is rdf:localID. The rest don't seem to work,
>>but then rdf:nodeID doesn't seem quite right, either.
>>    
>>
Received on Sunday, 19 January 2003 18:56:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:31 GMT