RE: Proposal: new top level domain '.urn' alleviates all need for urn: URIs

> -----Original Message-----
> From: ext Bill de hÓra [mailto:dehora@eircom.net]
> Sent: 07 July, 2003 14:35
> To: Stickler Patrick (NMP/Tampere)
> Cc: uri@w3.org; www-rdf-interest@w3.org
> Subject: Re: Proposal: new top level domain '.urn' alleviates all need
> for urn: URIs
> 
> 
> Patrick.Stickler@nokia.com wrote:
> 
> >>But if you insist on going forward, then:
> >>
> >>  http://urn.X.Y/
> >>
> >>is a sufficient hack. 
> > 
> > 
> > I think it's a rather elegant solution, not really a hack. 
> 
> Of course you do. I think DDDS is the elegant solution.

Well, I consider both to be elegant solutions. I just consider
a new top level domain to be more optimal, all things considered.

DDDS may be your preferred solution, but I would hope you
could see the domain based solution as something a bit more
refined than a hack.

But, hey, feel free to think what you like. I won't argue
the point.

> > It
> > simply uses the existing domain and subdomain name registration
> > infrastructure, guidelines, and general practices to partition
> > the URI space
> 
> That's eactly what's wrong with it.

Surely you can elaborate...

I fail to see any organizational distinction. It's purely
technical. There exists an organization which manages the
registration of urn: subschemes. That organization "controls"
the urn: namespace (all URIs beginning in urn:).

The owner of each subscheme controls their individual subspaces.
E.g. The ISSN folks control urn:issn: and decide what further
URIs are minted beginning with urn:issn:, etc.

If we simply shift that to domains, the same organization that
controls the urn: namespace and the registration of urn:
subschemes controls .urn. Each owner of each subdomain of 
.urn controls all URIs and further subdomain divisions intersecting
with that web authority.

The organizations are the same. The policies that are employed
to decide which URN subschemes are registered remain the same.
Nothing in the organizational/practical structure needs change
at all.

It's simply an issue of whether or not the resultant URIs minted
within that organizational machinery are meaningful to HTTP
servers.

If I'm missing something fundamental, please tell me what it is. 

> > But it does so in a manner that exploits the deployed HTTP
> > infrastructure 
> 
> That's what it doesn't do. It exploits a server in the infrastructure.

I'm sorry, but I don't follow you here.

> > Had someone thought of this approach back when URNs were first
> > being concieved, we'd probably have countless such HTTP-URNs
> > in use today.
> 
> And that's what the problem would be - doubtless we'd be busy 
> replacing it as a victim of its own success.

Can you please specify exactly what the problem is that
you percieve?

> >>It also doesn't require inventing new points 
> >>of failure in the web architecture*, doing DDDS badly, or the costs 
> >>of dealing with ICANN and whoever provides this service.
> > 
> > 
> > Quite.
> 
> Yes, quite.
> 
> 
> >>* As for the full richness of the web archiecture, think about how 
> >>the provider would scale this service. - I suspect purl works 
> >>because not many people use it.
> > 
> > 
> > Well, the worst case scenario would be that an organization
> > would obtain a .urn subdomain (in the same manner as they would
> > register an urn: subscheme) and would not provide any services
> > whatsoever relating to URIs minted in that subdomain. That's
> > no worse than the present situation with urn: URIs.
> 
> How do you come to that conclusion? I can see at least two added 
> cost burdens.

Which are..... 


> > However, in the best case scenario, and one which I expect will
> > be the norm, the managing organization will provide an effective
> > PURL or PURL like service for their customers.
> 
> Being the entire web.  PURL like services are effective in inverse 
> proportion to the number of people or machines that use them.

You're going to have to provide some hard cold facts
to convince me of that.

> > Granted, there will surely be a middle ground, which will have
> > partial or even sporadic support for URIs minted in those
> > namespaces, but at least the general architecture will not be to
> > blame for that, and customers wanting HTTP-URNs will make their
> > choices according to cost versus benefit.
> 
> Of course the 'general architecture' will be at blame for that. That 
> tt doesn't cater for it, knowingly, is no excuse.

Sorry. No. That's like saying a car's design is responsible for a
lousy taxi driver, who is rude, drives to fast and is shamelessly 
flatulant. Since there exist many acceptable and even some execellent
taxi drivers using the same technology and working within the 
same constraints, we can fairly attribute failure for a satisfactory
taxi experience to the driver, not the vehicle.

There is always a tradeoff in how general a tool can be and
how specifically that tool can affect a given result. 

My point was that organizations managing URN minting services
will be expected to provide certain basic services and if 
one particular organization fails to do so, or does so in an
unsatisfactory manner as compared to other organizations
providing the same services with the same architecture, 
then the failures or shortcomings of one organization have little 
to nothing to do with the architecture.

> As for business/social - the economics of your architecture punish 
> the provider of resolution the popular URIs. Now the web is like 
> that already to some degree, but this is the first proposal I've 
> seen that willfully encourages the problem.

???

Precisely how does it punish them?

> Look, the basic idea is probably ok given the absence of DDDS, but 
> rolling this out, ie making it 'general architecture' as opposed to 
> some quick fix is non-tenable given what we know about building web 
> systems that we didn't know 10 years ago. But It might be worth 
> doing just to force some action on the urn/http thing.

You seem to see specific flaws in the proposal, but I've yet
to get any clear picture what they are.

In either scenario, we have

1. A hierarchy of organizations that control URI allocation.
2. A means to reflect that hierarchy in URI structure.
3. A mapping from more-opaque name to less-opaque name.
4. A mapping from less-opaque name to representation.

Both my proposal as well as the urn: URI scheme and DDDS
provide solutions for the above. But applying Occam's Razor,
my proposal does so with less machinery, and particularly,
with already deployed technology.

What exactly do "we" know now that we didn't know 10 years ago
that suggests that my proposal is not an elegant solution
to this problem (even if considered less elegant, by whatever
degree, to DDDS)?

You seem to be strongly asserting that it is a flawed idea,
and I'd like to understand where you see those flaws.

Patrick

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

Received on Monday, 7 July 2003 09:21:37 UTC