RE: URIs : How to find the ontologies behind them

> -----Original Message-----
> From: ext Peter F. Patel-Schneider 
> [mailto:pfps@research.bell-labs.com]
> Sent: 11 April, 2003 14:01
> 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: 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?

Yes. You have. Though perhaps not intentionally.

Base URIs only exist in the RDF/XML serialization. You cannot 
(reliably or justifiably) derive a base URI from a URIref insofar
as the RDF graph is concerned because URIrefs are considered 
fully opaque by the RDF MT.

The only place you would ever see an explicit relationship between
a URIref and a base URI is in the RDF/XML.

The same is true for relationships between namespace names and URIs
grounded in those namespaces.

Both are mechanisms of the RDF/XML serialization alone, and once
you are operating on the graph, which is where SW agents should
operate, they are hidden behind URIref opaqueness.


> > > > 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 ''?  

I understood you as suggesting that, in order to get information
about a resource denoted by a URIref that you should parse the URIref,
derive a base URI, dereference the base URI, and if the results are
an RDF/XML instance, look for the definition of the resource based
on its local name.

While that approach may work in some cases, it is IMO not the way
the SW should work and breaks the layering between serialization
and the graph as well as disregards the opacity of URIrefs.

> [...]
> 
> > > > *** 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?   

Because it cannot be consistently and reliably applied to 
arbitrary URIrefs. And there are *much* better ways to 
implement knowledge discovery than hacks involving parsing
URIrefs.

> > 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?

I believe I've already answered this elsewhere in this response.

> > > > 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.

It presumes that folks use URIrefs rather than just URIs.

I do not myself define URIrefs, nor do many others. It is thus
of limited utility based on limited practice. As such it may
be a useful hack, but it is not a solution to knowledge
discovery about arbitrary resources.

> > > 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?

Well, taking RDF as the first layer of the Semantic Web, I
would expect the upper layers of the SW to conform to the
architectural maxim set forth by RDF that URIrefs are opaque.

And in case it wasn't clear (as it seems that much of what I
say is not clear) I do not assert that the trick you suggest
cannot work, only that it is not a reliable or sufficiently
comprehensive solution for knowledge discovery about arbitrary
resources.

Patrick

--
Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com

Received on Friday, 11 April 2003 07:52:51 UTC