Re: URI: Name or Network Location?

On Jan 23, 2004, at 14:23, ext Hammond, Tony (ELSLON) wrote:

> Hi Patrick:
>
> (Always fun to cross swords with you. :)
>

It really wasn't my intention to start a brawl... really... ;-)


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

True. This is a matter of education. I'd rather not "dumb down" the
web architecture, or make it overly complex, just because some behavior
might be occasionally confusing to some.

This seems really to be a PR issue, and one that is easily addressed
for all of your INFO "customers". Simply arrange your namespaces
grounded in your root organizational server http://info-uri.info,
and configure your root server to return a more informative, user
friendly response to any HTTP requests which are not otherwise
configured to actually resolve to something. The response could
simply be a redirection to a boilerplate page that explains the
nature of INFO URIs and why they are not getting any representation
of a resource, or it could be a redirection to a home page of the
owner of the particular subspace, etc. etc.

And since you already have the web server in place, adding that
default, fall-back behavior would be trivial.

I.e., there's no reason why you'd have to just throw 404 back in
their face with nothing more said. Yet at the same time, if anyone
wanted to e.g. set up a server providing RDF/OWL definitions
of their terms such that automated agents could discover the nature
of those terms via those INFO http: URIs, then that would be a *huge*
win for everyone (see the example below).

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

I understand your position, I think, in principle.

Though I don't think your assertions about the intended or required
usage of the http: URI scheme are correct (insofar as the actual specs
are concerned, even if John Doe surfing the web might (mis)presume 
otherwise).

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

If the owner of some info: subspace uses DDDS to provide resolution
of those URIs to representations of the named resources, they *might*
be misbehaving insofar as what the I-D says, or what their agreement
with the INFO organization stipulates, but those info: URIs
*are* resolvable.

My point is that any constraint against resolvability is based on
a social convention, an agreement between those minting info: URIs,
and *not* an actual hard constraint. Thus, they cannot be *guarunteed*
non-resolvable. It simply can't be done, and you are thus promising
something you cannot deliver.

There is *no* guaruntee that a few years down the road folks won't
be able to click on an info: URI in *any* browser and get a useful
response.

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

Er. If you want to say something about those names, why wouldn't you
want that information to be easily accessible, and most importantly
(per RDF, TM, etc.) formally defined?

E.g. http://sw.nokia.com/FN-1/published

Go ahead. Resolve the URI. And you get a very useful representation of
that term. Why would we not want to be able to get information about
*any* resource, especially terms of key vocabularies controlling our
tools and systems, which is denoted by a URI?

All those things you're saying about the terms denoted by INFO URIs
are then inaccessible by any standard means to web and SW agents. What's
the use of that?!

I guess that's the bottom line for me, I fail to see *any* benefit
in not having the option of resolving a URI and fail to see any
additional cost or overhead to using an http: URI as simply a
name and not providing for any resolution whatsoever.

It seems to me that the crux of this whole issue is that you don't
want folks to get unfriendly 404 responses. Fair enough. So give
them friendly 404 responses with nice pretty pictures. It's easily
done, without shutting the door on the future option of providing
resolution for some, or even all, of those URIs.

> 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

I'm sorry, but I just can't see how that is so. Please elaborate. How
does the assignment of the subspace http://info-uri.info/foo/ to Foo 
Inc.
entail any more overhead than the assignment of info:foo/?

You make this and similar claims in the FAQ and elsewhere, but you
don't actually demonstrate that what you claim is the case, nor
provide any use cases to back up your claims.

If no effort is put into mechanisms for resolution, then there's *no*
difference. And if resolution is delegated to each subspace owner,
then at most, it's just a matter of redirecting all requests
beginning with http://info-uri.info/foo/ to whatever server Foo Inc.
specifies. And if you provide a configuration tool for them, they
can specify/update/manage it themselves with no additional overhead
to the top level organization.


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

All the complications to resolution for URNs would be easily solved
if they would simply use http: URIs as I've proposed here and elsewhere.

I also don't see how resolution issues complicate the registration
process.

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

Again, you make the claim, but I fail to find any substance to it.

All the arguments about http: URIs being fragile because domain
name ownership might change/end and that's why you can't have
robust, long lived http: URIs are IMO just plain bogus.

(not that http: URIs *can't* be fragile, but they don't *have* to be).

If an organization such as INFO, or DOI, or IANA, or whomever
wanted to, they could obtain and maintain a root domain upon
which to mint http: URIs which would be as long lived as that
organization. And once that organization is no more, any URIs
that were minted under their auspices are instantly suspect,
since there remains no infrastructure to manage/monitor the
use of that namespace or subspaces deligated to others.

The same is true of info: URIs. Once the INFO organization
is no more, then all info: URIs ultimately lose their
integrity (even if they don't immediately lose their utility).

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

I appreciate your position. But I fail to see sufficient evidence
for many of the key claims made in the INFO FAQ which serve as
justification for the new URI scheme, and my own experience
indicates that the truth is otherwise.

Regards,

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Friday, 23 January 2004 08:26:14 UTC