Re: URN Proposals: What they have in common

Dirk.vanGulik (Dirk.vanGulik@jrc.it)
Mon, 17 Jul 1995 22:59:48 +0200


Date: Mon, 17 Jul 1995 22:59:48 +0200
From: "Dirk.vanGulik" <Dirk.vanGulik@jrc.it>
Message-Id: <9507172059.AA25847@ jrc.it>
To: uri@bunyip.com, Michael.Mealling@oit.gatech.edu
Subject: Re: URN Proposals: What they have in common


Summary of a long email following:

	URNs are nearly there. But what is needed is a good
	excuse for a real live application which solves
	some of the worlds problems tomorrow. IMHO they
	are most needed in cataloguing indexing etc.
-
	Then they make only sense as a key/handle
	for meta data thus lets focus on that and show
	the world one or two working examples.
-
	So give me a URN def... and I give you
	a resolver and an example where URNs
	get resolved into meta data, among which
	is possible a URL or one or more URI's if
	it applies to the resource you tried to
	resolve.
-
	As a side effect, you will have a more effective
	Aliweb type of search engine as well.
-
	Sorry if anything of this sounds overly
	pedantic, but I lack the subtly in this language.

-- long version:

> From owner-uri@bunyip.com Mon Jul 17 19:03:12 1995
> From: Michael.Mealling@oit.gatech.edu (Michael Mealling)
> Subject: URN Proposals: What they have in common

With a lot of cutting and pasting, Michael Mealling, 
once wrote:

> I was pleasantly suprised at how similar they are. Here is a brief
> synopsis of basically what every has already said:
 
I very much agree ! Thanks for making this point, it might just
help to focus.

> I believe that if we all were to "give up" a little we could fold about
> 4 of the proposals together (that is all except the handle proposal).

Isofar as what a URN should look like, I could not agree more; and really
it does not matter all that much because most schemes can be extended
or evolved into something like 'better practice' anyway. (like 
DNS names which now tend to have sensible aliases like dns.site
,www.institute.site.... or relay.site etc..)

What does need to be sorted out is *what* URNs are. The charter is, and 
cannot be that helpfull. Neither should it IMHO. In RFC 1737 point 2 for 
example, it is specified that it should be global, unique, scalable... 

And that is good. That really is the major concerns to get URNs right,
and it prevents people like me from taking shortcuts when we apply them 
to some application where we need something like it, but not need quite all
that.

But if the world wants to see real live applications, or if some exsisting
development is to show that it uses URN's, then there needs to be a drive. 
This drive can only come from what a URN really is, i.e. what you do with it. 

I think there are only two or three 'meanings' or 'uses' of a URN which 
have enough 'market push' behind them to make them happen:

-o As a simple direct, unique, etc, mapping/pointer of a fairly 
   low level resource, say a site, a document, a mailserver. Such 
   just fullfills exactly the points of the RFC 1737 and stops just there.

-o As a fancy URL, giving some extra information on something which
   has esentially already a single URL, but might have some several
   versions and is mainly to enhance our searching. With a little
   meddling one could squeeze it into some header format as well.

-o As a 'handle' to a collection of metadata concerning one or
   more resources which can be obtained at will; one of the bits
   of metadata might be a URL or some URI's.

The first use is just there because it is simple to implement, might help
a little when resources move etc, but I do not see much of a market
push at all and I cannot easily see a quick working example which
is more than a proof of principle.

The second and third point are different; the do coincide with a
marked need for having means to handle meta data on resources; to
catalogue, manage, index, cache and heaven knows what more. It might
be good to realize that this need is there on a very low, almost 
hardware level; i.e. to find a 'resource' in the sense of a printer,
up to say finding documents, articles, software, right up to finding
meta services, organizations and other 'entities' which have a more
organizational ring to it.

Of course, this second point really could live with the HTML working
group, or in the Mime area, service location area (low level) and 
other info/metadata concerned groups and URNs could play no part of 
it and in fact all this, or at least a lot of meta/library information 
stuff has no place in the URN area.

Likewise, point one could be moved down to service location on
a really mundane level. (like in draft-ietf-srvloc-protocol-6)

However a prime area of use for giving resources a unique identifier
is for cataloging, tracking and indexing... and for all that
I would like to stress that IMHO the URN is only a facilitating
unique number most of the time; for which things like scalability
and global uniqueness are not required all the time by most
implementors; it just gives you some ease of mind if you
bother to comply during the implementation phase and possibly
keeps some hot breath out of your neck.

I would like stress again that the actual URN definition does not
really matter for this kind of use; often anything unique will
do quite nicely in the acutal implementation.

If there would be a good way of 'resolving' a URN into its'
meta data; with content negotiation if you only want to
have a URL, and the meta data could, certainly in the
early phase, be as loose as say the Aliweb set or the
things you see in the header of a mail msg or news msg,
then I think we will see some examples to play with really
fast.

If on top of that there would be an http version of the resolver
whihc defaults to http forwarding (status 302 kinda)
resolving; a demonstration can be set up in a very usefull
way allowing searches to yeild a urn and showing that a
click on the urn actually brings you to the right location. 

If nessesarry ther is an example of a search engine which
yields URN's as result pointers, rather than URLs.

The 'fake' URN is, http://urn.jrc.it:4500/search-engine.41883.urn
or if that one is down http://elect6.jrc.it:4500/search-engine.41883.urn
which both 'forward' you in a hidden way to a page on http://ewse.jrc.it/
and http://elect6:1080/. The search result pages again point you
out to 4500 and the demon there resolves and forwards you somewhere
else. On some browsers you can see this happening at the status line.

Hope this helps.

Dirk-Willem van Gulik