- From: Miles Sabin <miles@mistral.co.uk>
- Date: Mon, 15 Apr 2002 14:54:29 +0100
- To: <www-rdf-interest@w3.org>
Uche Ogbuji wrote, > Lars Marius Garshol wrote, > > 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. > > 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. How about this one from the M+S REC itself, <rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator rdf:resource="http://www.w3.org/staffId/85740"/> </rdf:Description> <rdf:Description about="http://www.w3.org/staffId/85740"> <v:Name>Ora Lassila</v:Name> <v:Email>lassila@w3.org</v:Email> </rdf:Description> </rdf:RDF> which according to the text in sec. 2.1 is asserting, The individual referred to by employee id 85740 is named Ora Lassila and has the email address lassila@w3.org. The resource http://www.w3.org/Home/Lassila was created by this individual. IOW, http://www.w3.org/staffId/85740 denotes Ora Lassila, the person. Cheers, Miles > So while I agree that there *ought* to be no confusion, I think that > in practice there is. This could be fixed by providing convenient and > understandable mechanisms for handling this, but current practice > seems to be broken. > > | But I don't see the confusion. RFC 1738, which governs the URI > | http://uche.ogbuji.net makes it clear that this URI > | locates/identifies the document that is retrieved using HTTP and > | that address. Why would anyone thing it represents a person? > > Because lots of people use URIs that way. Then the confusion is of their own making, not RDF. 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. Personally, I don't see the problem, which is why I've ditched the long recent thread on the issue. There are specs that govern URIs, and since tose specs are not, emm, ontologically closed :-), URIs end up meaning largely what we agree that they mean. This is quite common, and the human species isn't extinct because of such ambiguities. 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. > | Maybe I'm just thick, but I just do not come close to understanding > | Topic Maps. There are just too many moving parts interacting in > | confusing ways. I must say, though, from observice the discussiuons > | at KT, that I'm not sure anyone really does. > > I find this a puzzling statement. To me they are very clear, and it > seems to me that most topic mappers feel the same way. Then I probably misunderstood the discusson that night. Pardon me. It just seemed to me that there was a lot of cross-clarification going on while discussing TM matters, much of which increased any fog I might have been under. It's not for me to say what others understand. -- 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/ Managing structured Web service metadata - http://www-106.ibm.com/developerwork s/webservices/library/ws-wsdlrdf/ 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 ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. http://www.star.net.uk ________________________________________________________________________
Received on Monday, 15 April 2002 09:54:33 UTC