RE: uri, urn and info

_____________Original message ____________
Subject:	RE: uri, urn and info
Sender:	ext Hammond, Tony (ELSLON) <T.Hammond@elsevier.com>
Date:		Thu,  9 Oct 2003 07:48:08 +0000


Hi Ted:

> For "pure" identifiers, not
> intended to trigger protocol processing (be it dereferencing or something
> else), I can see the need for a small handful of schemes, based on
> expectations of permanence or minting algorithms suited to different
> environments.

I just wanted to comment on a couple of points you raised in the above:

	1. The "info" URI scheme does not make any claims about persistence
(or of location independence) of resource identifiers. Any such expectations
would be met by the relevant namespace authorities.

		One could say the same for probably any
		URI scheme, including http:

		And I would assert that the "cool URIs don't
		change" motto to apply as much to info: URIs 
		as to any other form of URI's; even more so,
		given the nature of the kinds of schemes
		offered as key targets of the info: proposal.

	2. Likewise, the "info" URI scheme does not provide any minting
algorithms. It merely provides a means for the registration of non-URI
namespaces so that identifiers minted under those legacy namespaces -
whether
minted by a central naming authority or delegated unto others - can be
represented "on the Web". 

		One could just as easily view the http: URI
		scheme, by way of its web authority component,
		as providing a namespace registration and
		minting delegation mechanism.

As such the "info" URI scheme provides a bridging
mechanism between resource identifiers that are "off the Web" and resource
identifiers "on the Web".

		IMO, whether something is on the web or
		not has less to do with the scheme of a
		URI denoting it as to whether one can
		access representations of that thing.

		Merely providing a source of OWL
		owl:sameIndividualAs assertions equating
		the denotation of an info: URI with the
		denotation of an http: URI can make an
		info: denoted resource "on the web".
		The presumption that the info: URI has
		any real affect on the (ultimate) accessibility 
		of a resource is an illusion. It only affects
		the ease of which resolution is possible.

	3. The main functionality of the "info" URI scheme is the projection
of identity onto the Web for commonly used identifiers which are well known
within their target communities - library, etc. (Note that the I-D mentions 
that individual namespaces registered under the "info" Registry may assert a
dereference capability, but we now realize that this lies outside of the
remit
of the "info" URI scheme and are therefore considering to exclude
dereference
as a potential functionality of "info" URIs.)

		Again, http: URIs offer all of the above, in
		addition to providing for (without requiring)
		resolution to representations and (IMO
		more importantly, for these sorts of term
		resources) descriptions.

We are currently busy enabling the "info" Registry, which will allow
"info" URIs to be used by many Web applications. We have already submitted
an
I-D (Internet-Draft) as part of the wider process to get the "info"
namespace
registered under the IANA Registry of (registered) URI scheme names. We
remain hopeful that the draft RFC will be facilitated, considered and
accepted.

		I'm sorry to be such a naysayer, but I see the
		info: URI scheme to be both unnecessary
		and (more regettable) a hinderance to 
		establishing a standardised URI based
		means of referring to key industry terms
		in a way that maximises their utiity to web
		and SW agents by merit of providing access
		to their definitions directly via those URIs.

		I have particular concerns regarding the
		adoption of info: for the kinds of key terms
		indicated as primary targets, being involved
		both academically and professionally with
		the design and deployment of systems
		relating to library science, virtual libraries,
		and metadata driven resource management.
		I.e., I'm not just a URI junkie or http: groupie.
		The global adoption of info: rather than http:
		URIs for such key industry standard namespaces
		would have a very real-world impact on what I
		do. While I am encouraged that NISO and
		others are working to provide standardised
		URI based denotations for much used terms,
		I am very dissappointed in the form of solution
		being pursued. 

Hope that helps.

		It does help (me at least) understand
		better your support for the info: scheme.

		Unfortunately, I've yet to see any argument
		in favor of info: URIs which demonstrates
		a need (technical or social) that is not fully
		met by http: URIs. And there are substantial
		benefits to be gained from the (potential)
		accessibility provided by http: URIs which
		I consider a fatal omission from the info:
		URI scheme.

		Regards,

		Patrick

--

Tony Hammond
Advanced Technology Group, Elsevier
32 Jamestown Road, London NW1 7BY, UK

<tel:+44-20-7424-4445>
<mailto:t.hammond@elsevier.com>


-----Original Message-----
From: hardie@qualcomm.com [mailto:hardie@qualcomm.com]
Sent: 08 October 2003 00:07
To: Michael Mealling; Eric Hellman
Cc: uri@w3.org
Subject: Re: uri, urn and info



Hi Eric,
	Note that the requirements for the URN NID process are set
out in RFC 3406 and that they do not require that the documentation
be a standards track document.  It requires review by a specific
mailing list (urn-nid@apps.ietf.org) and review by the IESG.   The
term "IETF consensus" has been seen as ambiguous on this, but
this case is very clear, as RFC 3406 sets out the steps admirably
well.
	The IETF tree of the URI scheme registration mechanisms are
set out in RFC 2717, and Larry Masinter is currently working on an
update to the document to define registration procedures for other
trees.  There are two key issues for me in scheme registrations: 
can the registration adequately inform the reader where to turn
for information on protocol processing based on the scheme, and
can the registration adequately indicate who has change control
over those procedures?  Like many others, I don't see a great deal
of point for the proliferation of schemes, unless the protocol processing
indicated by the schemes is different.  For "pure" identifiers, not
intended to trigger protocol processing (be it dereferencing or something
else), I can see the need for a small handful of schemes, based on
expectations of permanence or minting algorithms suited to different
environments.  But a thousand flowers in that arena will only give us
hay fever, in my opinion.
			regards,
				Ted Hardie

 

At 6:29 PM -0400 10/07/2003, Michael Mealling wrote:
>On Tue, 2003-10-07 at 17:45, Eric Hellman wrote:
>> urn
>> rigorous requirements but the real hurdle with urn is to get IETF
>> consensus.
>
>Which is proving to be a fairly easy thing to do. At present we have the
>following registered IDs:
>IETF       [RFC2648]
>PIN        [RFC3043]	
>ISSN       [RFC3044]
>OID        [RFC3061]
>NEWSML     [RFC3085]
>OASIS      [RFC3121]
>XMLORG     [RFC3120]
>publicid   [RFC3151]
>ISBN       [RFC3187]
>NBN        [RFC3188]
>WEB3D      [RFC3541]
>MPEG       [RFC3614]
>mace       [RFC-hazelton-mace-urn-namespace-02.txt]
>fipa       [RFC3616]
>swift      [RFC3615]
>
>I submitted the 'liberty' NID proposal and the process once I submitted
>it to the NID list was completely comment free. The time between request
>and approval was about 1 month total. The RFC Editor will probably
>publish it shortly. Its a heck of a lot faster than the MIME types
>registration process. ;-)
>
>> IETF lapses most URN proposals and doesn't promote or use
>> the ones it does.
>
>What do you mean by 'lapses'? All of the proposals except 'tag' and some
>where the project dropped off the face of the earth have made it through
>the process. The IETF is using the 'ietf' space fairly heavily,
>especially as it concerns the XML registry defined in
>draft-mealling-iana-xmlns-registry-05.txt. Presently the standards
>waiting on is publication are simple, provreg, and sipping (those are
>the ones the RFC Editor has, there are more I think).
>
>The identifiers have been assigned and the processes are in place. If
>there is some confusion on that process let me know and I'll make sure
>it gets clarified or straightened out....
>
>-MM

Received on Thursday, 9 October 2003 01:54:04 UTC