RE: URIs : How to find the ontologies behind them

> -----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
> 
> > 
> > > > I'm primarily interested in the 'when the SW gets going' 
> > > case (it's about
> > > > time we get it going, no? ;).  You seem to be saying that a 
> > > best practice
> > > > would be to put the OWL describing the resource in the 
> > > place that the URI of
> > > > the resource refers to.
> > > 
> > > Not necessarily in that exact place.  However, most RDF URI 
> > > references have
> > > fragment identifiers, so it would be possible for example to place
> > > information about http://foo.ex/bar#bax in a document located at
> > > http://foo.ex/bar.  
> > 
> > Sorry. Unfortunately, no.
> > 
> > RDF fragment IDs do not work in exactly the same way as XML ID's.
> > 
> > You can describe the resource http://foo.ex/bar#bax in a dozen
> > different RDF/XML instances, none of which are http://foo.ex/bar.
> > And in all cases, you need not use rdf:ID ever. So even if
> > http://foo.ex/bar#bax is defined by http://foo.ex/bar, that
> > doesn't guaruntee that rdf:ID="bax" occurs anywhere in that
> > RDF/XML instance.
> 
> So?  Does this mean that what I said is not possible?

I believe that in practice, it will be provide very little reliability,
given that many, possibly most, RDF/XML instances do not use rdf:ID
and even if one schema does, that knowledge is frequently augmented
with additional statements in other RDF/XML instances -- and thus, the
approach you propose will have limited utility.

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.

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

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.

> > And in fact, though there should only be one occurrence of a given
> > rdf:ID value for an xml:base scope, one can have descriptions using
> > both rdf:ID and rdf:about about the very same resource in the same
> > RDF/XML instance.
> 
> Agreed, but, again, what does this have to do with what I said?

See comments above.

> > One should not think of URIrefs as working in RDF the same way
> > as they do in an HTML browser. They don't.
> 
> Agreed, but, again, what does this have to do with what I said?

See comments above.

> > Thus, just as one cannot reliably get to a namespace document
> > from a URI, one cannot get to a definitive RDF/XML instance from
> > a URIref.
> 
> Agreed, but, again, what does this have to do with what I said?

See comments above.

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

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.

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

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.

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

> > The SW architecture should provide for a standardized means by
> > which, given a URIref, one can inquire from the web authority
> > of the URIref (presuming there is one) for a description of 
> > the resource denoted by the URIref.
> > 
> > One can also inquire from various registries or other sources
> > for non-web-authoritative descriptions of the resource, allowing
> > for one to syndicate various views and opinions of the resource.
> 
> Sure why not?
> 
> It may be that there is a better way than the one I 
> described.  However,
> what is wrong with what I said?

See comments above.

Patrick

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

Received on Friday, 11 April 2003 01:47:01 UTC