Lists Home |
Date Index |
Simon St.Laurent wrote:
> Jonathan Borden wrote:
> > No doubt there _are_ problems, particularly with the definition of URI
> > references (e.g. URI + fragment identifier), but with URIs themselves: what
> > actual problems exist?
> * Lack of comparison rules
Ah! This is one problem that the URI notion actually solves.
Two URIs are equal when they are textually identical. Period.
The notion espoused by Paul Prescod that clients never, ever,
retrieve a resource, only a representation of the resource,
gets us out of the ontological quagmire we fall into with
the question "when do two URIs represent the same thing?"
This is like asking if two arbitrary procedures, written
in the Turing-complete programming language of your choice,
denote the same function: the mathematically correct answer is
uncomputable, so most sensible languages either do not admit
an equality predicate on functions or restrict it to object
This doesn't rule out statements like "Topic Map X declares
that URI Y and URI Z denote the same resource" of course. This is
vaguely analogous to a formal proof that the two procedures
in question compute the same function, in the sense that it's
possible to state that two URIs are equivalent, just not within
the system itself.
> * Lack of common understandings or best practices regarding what "URI
> processing" even means.
Although I still believe the URL vs. URN distinction is
a useful one, it seems that even if you publish a URI that's
intended to be used only as a Locator, somebody else is going
to come along later and use it as a Name.
I guess what I'm trying to say is that the question of "how
to process a URI" might be as meaningless as the question of
"how to process an XML document". SGML gained most of its utility
by divorcing processing expectations from the markup; perhaps
the URI philosophy will enable more of the same. (AFAIC the
jury's still out on this one though. One of these years Edd Dumbill
is *bound* to get a nomination for the "Best Practical Use of the
Semantic Web" award, and then we'll see if this idea bears any fruit.)