Date: Mon, 24 May 93 10:54:17 -0500
From: Dirk Herr-Hoyman <hoymand@joe.uwex.edu>
Message-Id: <9305241554.AA05477@joe.uwex.edu>
To: uri@bunyip.com
Subject: Re: URLs, URIs, and references
Peter's comments over the last few days have been very helpful in filling out
the details of what URNs are supposed to be. And I agree with Peter's thought
that the work on URNs and URLs should be kept simple at this point, so that we
can get something working.
There does seem to be some confusion, and I suffer from it too, between
identification and classification. What Peter is suggesting, as best I can
tell, is that we need to solve the identification problem, not the
classification one. But, it's easy to back into classification.
For example, Larry Masinter is suggesting this additional to URLs:
From: Larry Masinter <masinter@parc.xerox.com>
Date: Sun, 23 May 1993 22:06:19 PDT
> Maybe it would avoid some of the politics to say, instead of 'URLs
> should contain types' to say:
>
> references to data should be typed
>
> or perhaps, in a more object oriented way:
>
> references to data should support not only the 'fetch
> this thing' operation, but also an operation of 'what is
> the (content-) type of this thing'.
While this looks to be a promising idea, perhaps it's better not to ask URLs
or URNs to take this on, but rather, we should punt this, and any other
potential classifications, to URCs. As I understand it, URCs will be like a
bibliographic record, and looks to be the right way to get at meta-information
and classification. At this point, I would like to see any attempt to deal
with meta-information pushed into URCs (gee, I hope this is not the old shell
game :-), and let the URN -> URL function as a mechanism for identification.
Peter's comments on this area pretty well sum it up for me:
From: Peter Deutsch <peterd@bunyip.com>
Date: Fri, 21 May 1993 18:21:58 -0400
> I think we should agree that the URL is _only_ a mechanism
> for providing general access method and identifier
> information to allow us to specify locations of specific
> resources. If that's _all_ it does, we're still going to
> be miles ahead of where we are now. Those access methods
> that support fragment specification information now may go
> ahead and encode them into their URL scheme, but there
> is no onus on all systems to support the concept at this
> point.
>
> Similarly for URNs. I claim that the goal of a URN is to
> uniquely identify, within a particular naming space, a
> particular resource object. this is a clearly definable
> need and I think we should concentrate on providing a
> simple, extensible and easily deployable mechanism for
> doing this. The question of providing "fragments of
> objects" should be punted. The question of whether we
> should impose hierarchal naming structure onto all name
> spaces that will be using URNs should be punted. The
> question of whether we should impose checksum mechanisms
> onto all URNs should be punted. And so on.
> ...
>
> There is a definite need for fragment specifiers and the
> various other things people have mentioned but personally,
> I think we can include most such items into the putative
> URC as one of its many potential fields, or provide for
> them through composite techniques, combining say a URN and
> a fragment sepcifier, a URN and a checksum, etc.
> Meanwhile, we can all start using the basic stuff now.
>
--- Dirk Herr-Hoyman | PracticeInternet Publishing Specialist | random acts of
Electronic Journal of Extension | kindness Project Coordinator | and University of Wisconsin-Extension | senseless beauty hoymand@joe.uwex.edu (NeXTmail accepted) | 608-265-3893 (voice) 608-265-2530 (fax) |