Re: URIs : How to find the ontologies behind them

From: <Patrick.Stickler@nokia.com>
Subject: RE: URIs : How to find the ontologies behind them
Date: Fri, 11 Apr 2003 08:46:56 +0300

> > -----Original Message-----
> > From: ext Peter F. Patel-Schneider 
> > [mailto:pfps@research.bell-labs.com]
> > Sent: 10 April, 2003 16:46
> > To: Stickler Patrick (NMP/Tampere)
> > Cc: www-rdf-interest@w3.org
> > Subject: Re: URIs : How to find the ontologies behind them
> > 
> > 
> > From: <Patrick.Stickler@nokia.com>
> > Subject: RE: URIs : How to find the ontologies behind them
> > Date: Thu, 10 Apr 2003 09:40:56 +0300

[...]

> My main objection is that it is basing RDF application design and
> behavior on characteristics of the RDF/XML serialization, which is
> simply very poor RDF engineering practice. RDF applications should
> focus on the graph, period. And only concern themselves with RDF/XML
> for interchange, static expression, etc. and even then, should let
> the parser or knowledge base implementation take care of serialization.

Huh?  How does a scheme that goes from a URI reference of the form
http://foo.com/bar#xxx from http://foo.com/bar depend on RDF/XML
serialization?  Have I said anything about RDF/XML here?

> > > And there is no assertion that http://foo.ex/bar#bax relates to
> > > a particular XML *element* in an RDF/XML instance having an
> > > rdf:ID="bax" even if the parser will map such an rdf:ID value
> > > to a URI based on an xml:base separated by '#'. rdf:ID is
> > > not defined as an XML ID attribute.
> > 
> > Agreed, but, again, what does this have to do with what I said?
> 
> Any utility from your proposed approach presumes that most if not all
> of RDF/XML statements use rdf:ID and that the complete body of 
> authoritative knowledge asserted for a resource is expressed within
> the single RDF/XML property element having the rdf:ID attribute, and
> this is quite simply unrealistic and very far from reality.

What does this have to do with rdf:ID?  All that is needed is that there is
a URI reference there.  It could be introduced by rdf:ID or rdf:about or
just come from a URI in an RDF triple.  Certainly this doesn't work for
blank nodes.

> SW agents should not expect to be able to (a) parse some URIref to
> obtain the base URI and (b) find any XML element having an rdf:ID
> equal to the fragment ID. It's just not part of either the design
> or common practice of RDF users. Similarities with HTML <a name="...">
> or XML ID values are purely superficial.

Huh?  Where have I said to ``find any XML element having an rdf:ID equal to
the fragment ID ''?  

[...]

> > > *** TAKE NOTE: URIrefs are *fully opaque* in an RDF graph and SW
> > > *** agents operating on RDF expressed knowledge should not attempt
> > > *** to parse URIrefs to infer any relationships between the resource
> > > *** denoted by the URIref and any other resource that might share
> > > *** some intersection of some character sequence with the URIref. 
> > 
> > Aaah, but I'm not saying that this is part of RDF.  I'm just 
> > saying that it
> > is possible (in some unspecified, and maybe never formally specified,
> > manner) to place information about an RDF URI reference at a 
> > particular
> > URI.
> 
> But that is not reliably retrievable by a SW agent operating on an RDF
> graph because (a) in the RDF graph, where the SW agent *should* be operating,
> URIrefs are *fully opaque* and therefore a SW agent should not be parsing
> the URIref to try to derive a base URI of some schema, and (b) even if it
> does, should not presume that there is any rdf:ID value corresponding to
> the (dubious, uncertain) fragment identifier.

The current formal semantic of RDF treats URI references as fully opaque.
So what?  What prevents some other mechanism of the Semantic Web from
looking inside URI references?  Why is this not a great idea?   

> So, even if you could make your approach work for some localized, toy system
> where the RDF/XML serialization and URIref construction is tighly controlled,
> it is hardly a reasonable proposal for dealing with arbitrary RDF expressed
> knowledge on the global SW.

Why not?  Take an RDF URI reference.  Remove the fragment identifier.  Try
to use the resulting URI reference to retrieve an RDF (or OWL) document.
Treat that document as probably containing some interesting information
about the URI reference.  How is this a toy proposal?

> > > The SW deals with RDF graphs, not RDF/XML instances, so
> > > one should not be concerned with aspects of the XML serialization 
> > > when requesting knowledge from a knowledge base. And looking
> > > at URI vs. URIref or URI vs. namespace relations (neither of 
> > > which can be reliably utilized) is the wrong way to go.
> > 
> > Why not?  Many RDF URI references can be so decomposed.  
> 
> Not reliably. Even if you're lucky and get an RDF schema from the guessed-at
> base URI, you can't actually *know* that it relates to the resource denoted
> by the original URIref.

Sure, you can't know this, but so what?  If there is no relevant
information there, what has been lost?

> As such, this approach is a hack. If it works for someone, great, but
> they should fully appreciate that it does not reflect (IMO) sound SW
> engineering.

Why not?  It uses already existing machinery from the World Wide Web, that,
to me, has good utility in the Semantic Web.

> > I'm not suggesting that this be part of RDF per se.  
> 
> Fair enough, but is still is IMO a very impractical and unreliable approach
> that also fails to respect the opacity of URIrefs in the RDF graph, which
> are intended to be atomic primitives which are not decomposed in any way.

Huh?  Why are RDF URI references supposed to be atomic primitives?  What
architectural maxim of the Semantic Web (not RDF) says so?

[...]

> Patrick

peter

Received on Friday, 11 April 2003 07:01:28 UTC