W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2004

RE: URI: Name or Network Location?

From: Hammond, Tony (ELSLON) <T.Hammond@elsevier.com>
Date: Fri, 23 Jan 2004 12:23:58 -0000
Message-ID: <54A600C436EA694581B93E4BD4D4788A06B73F46@elslonexc004.eslo.co.uk>
To: 'Patrick Stickler' <patrick.stickler@nokia.com>
Cc: www-rdf-interest@w3.org

Hi Patrick:

(Always fun to cross swords with you. :)

> There is *no* requirement that *any* URI
> of *any* URI Scheme resolve to *anything*.

No - but there is an *expectation* that many (most?) schemes e.g. HTTP will
be dereferenceable. A user cannot distinguish between an unresolved URI
(broken link) and an unresolveable URI (not linkable). We just happen to
think it is bad form to use a scheme intended for one purpose for a spearate
purpose.

> As for resolution of info: URIs. I can use DDDS or any proprietary
> solution to resolve info: URIs to representations or descriptions
> of the resources denoted, and that cannot be prevented. Furthermore,

Again no - INFO URIs are not dereferenceable. Sure the identifiers from a
particular namespace may have associated resolution mechanisms (e.g. PubMed
identifiers) and out-of-band methods may be used to 'resolve' those
identifiers to documents (or ohter functionality), but these are not INFO
URIs that are being resolved - because they don't - that's what the I-D says
- guaranteed non-resolveable. Same holds true if you latch up some DDDS
mechanism. The INFO URI is not resolveable.

> What good is a name
> if you can't say anything about the think it names? Surely there
> will be labels, descriptions, and other information associated with
> those info: URIs which describe the things named. Why deliberately
> prevent systems from accessing such information *based* on the
> name (URI) used? I just don't find that position to be reasonable
> or useful.

The point is that we can say something about the name - whole purpose is to
be able to use these names within Web description technologies - e.g. XLink,
RDF, Topic Maps. But we don't need to resolve those names - just want their
identity expressed in URI form. If such functionality is required then the
respective namespace authority should make separate provision, either by
using some existing scheme or by registering an independent scheme (or URN
namepsace if they want to go that route). By explicitly excluding any
possibility of dereference we vastly simplify the registration process for
new namespaces - which is the intent - we are after all trying to grow the
Web as a global information space. And by keeping INFO true to its purpose
of naming alone we avoid ugly hybrid solutions. (Note that URN has the
general notion of dereference - which is a huge complication in registration
and deployment.)

> As for DNS, I've yet to see a convincing argument that DNS is
> inherently "unreliable" and results in URIs containing web authority
> components having domain names as being "fragile". Saying it is so
> does not make it so.

I don't say DNS is unreliable as a name resolution mechanism - just
unreliable/fragile for use within a name-only URI whose one job in life is
to project identity.

> I know you and others have put alot of work into info: URIs, 
> and believe
> me, I'm *very* sympathetic to your goals and motivations. I just think
> it is a big mistake to not use http: URIs to name all those very 
> important
> resources, so that if/as desired, those URIs can be used to access
> important, authoritative information about those resources.

We just have to accept that we're on opposite sides of the fence on this
one. I happen to believe in URI over HTTP. The treasons for INFO as
articulated in the FAQ are not singular but complex and result from a
combination of both cultural and technical concerns which is why we see very
little movement of public namespaces onto the Web. I just wonder whether the
Web scales very well - as an 'information' space.

Tony
Received on Friday, 23 January 2004 07:24:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:04 GMT