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 14:52:44 +0300

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

Sure, the RDF MT (currently) treats URI references as opaque.  But what
does the RDF MT have to do with a Semantic Web process of going from 
http://foo.com/bar#xxx to http://foo.com/bar?  It seems to me that if you
are going to forbid going form http://foo.com/bar#xxx to http://foo.com/bar
(to access a potentially-relevant document) then you would also have to
forbid going from http://foo.com/bar#xxx to foo.com (to find a defining
authority).

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

I don't see this at all.  A URI reference is a URI reference.  RDF Concepts
says that one of the choices for nodes in a RDF graph is a URI reference.
Just because the RDF MT treats such URI references as atomic, doesn't mean
that it is not a good idea to do otherwise in some other part of the
Semantic Web.

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

Where did namespace names come from?

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

Namespace names are artifacts of the RDF/XML serialization, and are not
preserved in RDF graphs.  However, URI references are definitely parts of
RDF graphs, and I don't see anything in the Semantic Web vision that says
that it is forbidden to examine the struct of URI references.

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

No.  

I've said that one possibility for getting information that concerns a URI
reference (with a fragment identifier) is to remove the fragment identifier
(if any) and then retrieve (and process) a (any?) Semantic Web document
available at that URI.  I've said nothing about local name, base URI, or
RDF/XML instance.

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

Sure, it is not your opinion.  It certainly looks into URI references.
However, it doesn't depend on anything that is not in an RDF graph, and
thus does not depend on any serialization.

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

Why not?  I'm not saying that this will always result in information.  For
example, there may not be a suitable document at that URI.

[...]

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

Huh?  Do you mean that you exclusively use URIs that do not have fragment
identifiers?  Even so, how would this invalidate my suggestion?  Lots of
other people do use fragment identifiers.  Are you suggesting that this is
a bad idea?  Are you suggesting that my suggestion is a bad idea for those
of us who extensively use fragment identifiers?

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

Why?  The Web Ontology Working Group has valiantly tried to stay completely
within the RDF limitations and more or less has overcome them.  However, it
was an extraordinarily difficult effort that could have been avoided.  If
the limitations of RDF are going to continue hamstringing the Semantic Web
then I want out.

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

I've never said that it was a comprehensive solution.  I've only said that
it is a reasonable way of providing information concerning URI references
that could easily and usefully be made an informal part of the Semantic Web.

> Patrick

peter

Received on Friday, 11 April 2003 08:53:29 UTC