Re: RDF Keys, or why RDF is lousy at metadata annotations

Hi Bob,

This is a brief, somewhat abstracted, response to your points made over a 
couple of messages.  I have some sympathy for your quest (particularly that 
I find the all-or-nothing scope of bnodes is sometimes awkward in certain 
developments I have worked on), but I'm uncertain that another kind of node 
labelling is really going to help.

(1) we tried to say something about interpretation of URIs in the real 
world, but in the end had to punt ... ("social meaning", etc, [1]).

(2) There is no Unique name assumption in RDF.  Just because two URIs are 
used in an RDF graph, that doesn't of itself mean that they denote 
different things.  I think this undermines one or your particular 
arguments, where you say:
[[
Bnodes relate to URI attachment.  There are two kinds of bnodes:  The first 
are equivalent
to skolems.  The second represent unnamed entities, such as the majority of 
entities
referenced by tags in XML specifications.  If these entities had names, 
they would obey
the unique name assumption (i.e., they would be recognized as disjoint).
]]
-- http://lists.w3.org/Archives/Public/www-rdf-comments/2004JanMar/0094.html

(3) I'm not sure if your "keys" proposal is a good idea or not... I can see 
some attractions.  But I do think that, before any rush to standardize, 
there should be some practical experience.  It seems to me that you could 
do something similar to your idea of RDF keys, within the current rules of 
RDF, using something like the URI query syntax.  I believe there's a 
binding of SOAP requests to URIs that might be adaptable in this respect 
(even if you never intend to use SOAP).  But, mainly, if you try something, 
and show that It Is Good, then I think your ideas become much more compelling.

Or:  what is it that you need someone else's permission to do?

#g
--

[1] http://www.w3.org/2000/03/rdf-tracking/#rdfms-assertion


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Tuesday, 16 March 2004 06:42:53 UTC