RE: URIs : How to find the ontologies behind them

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

It's the same thing, however you want to play around with the words.

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

You're right. I stand corrected (on that particular point).

However, since there still is (a) no guarunteed relation between
a URIref and URI, (b) no guaruntee that a URI derived from a URIref
will resolve to an RDF representation, the approach is still 
a hack that may work for some cases, but not a basis for knowledge
discovery for arbitrary resources.

This has, and continues to be my main point. Yes, it can work, in
some cases, but I took issue with it being presented as an overall
global solution to the person making the inquiry about knowledge 
discovery.

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

Absolutely.

> Even so, how would this invalidate my 
> suggestion?  Lots of
> other people do use fragment identifiers.  

Again, I was only taking issue with your suggestion as being
presented as a solution for a reliable, globally deployable
solution for knowledge discovery about arbitrary resources.

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

It is an approach that has limited and non-global utility. 

Note I don't say 'no utility', but not global utility.

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

Er... well, feel free to drop us a postcard from wherever you end up... ;-)

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

Well, that wasn't my impression, but of course, I could have
simply misread your intent.

Still, IMO better to actually have a comprehensive, global, and
consistent solution that does not presume anything not specified
by the standards.

Cheers,

Patrick

Received on Monday, 14 April 2003 09:07:15 UTC