Re: silly question about rdf:about

> 
> * Lars Marius Garshol
> |
> | I think Nikita is right. If you look at the RDF currently being
> | published, most of it (if not all), uses http URIs to point to
> | things that are not network-retrievable resources.
> 
> * Uche Ogbuji
> | 
> | I disagree.  Do you have some citations?  I don't think I've ever
> | heard an RDF person put up a URI and say "this is a person".  I
> | don't think I've ever seen the equivalent of this in any RDF
> | examples, either.
> 
> There isn't a whole lot of RDF out there,

Surprising statement, but anyway...

> but what I've found is
> guilty of this error:
> 
>  - the MusicBrainz data identifies artists, albums, and tracks with
>    http:// URIs
> 
>  - the WordNet-in-RDF data uses http:// URIs to identify words
> 
>  - airports.rdf uses http:// URIs to identify airports
> 
>  - the OpenWine data uses http:// URIs for countries, regions, wine
>    producers, grape types, you name it

Wait a minute.  What are we arguing here?  Just because they are using HTTP 
URIs does not mean they are making an unreasoned stand in for an entity.  My 
point has been that as long as there is agreement on the matter, there is no 
reason why an HTTP URI cannot stand in for an abstract entity.  It is then no 
more than any other name.

You seem to agree, based on the fact that you gave an HTTP URI as an example 
of a published subject indicator (indicator, right?).

Back to the original example.  If I see

http://uche.ogbuji.net

Then it is unreasonable for me to think, of my own, that it means anything 
other than the Web site that is to be found there.  If, however, you and I 
have agreed that this URI is a stand-in for the person, then we can proceed to 
use it as such.

Isn't this *exactly* how PSIs work?

Possibly, the examples you give are not explicit enough about the 
meaning/intent of their URIs.  If so, that is bad practice, but the sort of 
bad practice that is common with any naming system.


> This is all the "real" RDF data out there that I know about. If people
> know of other RDF data dumps I'd love to hear about them.
> 
> Of course, the problem starts right here:
>   <URL: http://www.w3.org/TR/REC-rdf-syntax/fig3.gif >
>  
> | [...]
> | Then the confusion is of their own making, not RDF.
> 
> So what? Confusion is confusion, no matter where it comes from.

Are you implying that people cannot build bad models with TM?


> | As I said in the nocturne, the uses and meanings of URIs lie at a
> | very different layer from RDF.  Since RDF works (or should work)
> | with URIs as they are, this is a problem to be solved in URI, not
> | RDF.  Ans it's a problem that goes far beyond RDF.
> 
> Yes and no. The meaning of http URIs is crystal clear, but their use
> in RDF is anything but. The discussions going on in the RDF community
> right now show that there is nothing like consensus on whether RDF may
> or may not use them to refer to things that are not
> network-retreivable, even if it is obvious to all concerned that what
> one gets by resolving an http URI *is* network-retreivable.

Which discussions do you refer to, in particular?


> | I don't think that adding a layer of indirection, as Topic Maps
> | does, does a *thing* to change this, or goes a single step beyond
> | RDF in disambiuating the meanings of things we are describing.
> 
> Well, do you understand it?

Not really.  I don't understand the reason, and I don't understand the result.


-- 
Uche Ogbuji                   Principal Consultant     Fourthought, Inc.
uche.ogbuji@fourthought.com   http://Fourthought.com   +1 720 320 2046
XML strategy, XML tools (http://4Suite.org), knowledge management
Track chair, XML/Web Services One (San Jose, Boston): 
http://www.xmlconference.com/
RDF Query using Versa - http://www-106.ibm.com/developerworks/xml/library/x-thi
nk10/index.html
WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004
XML, The Model Driven Architecture, and RDF @ XML Europe - 
http://www.xmleurope.com/2002/kttrack.asp#themodel

Received on Monday, 15 April 2002 21:46:15 UTC