- 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