RE: uri, urn and info

Hi Ted:

When you have a URI such as <info:example-id:77788899> which identifies the
information asset "77788899" in the public namespace "example-id" and is
referenced on the Web using the "info" URI scheme, you can then do many
things.

A couple of examples should suffice:

1. The information asset can now be referenced within an RDF graph. For
example, 

	@prefix dc:  <http://purl.org/dc/elements/1.1/> .

	<info:example-id/77788899> dc:creator "Ted Hardie".

2. The information asset can now be referenced within a ContextObject as
defined in the OpenURL Framework [1] (The OpenURL Framework is a standard
framework - being standardized through ANSI/NISO - that provides an
extensible mechanism for defining data structures for context-sensitive
linking.) For example, on a simple OpenURL one might have (whitespace and no
URL-encoding for clarity)

	http://openurl.example.com/resolver?
      	& url_ver = Z39.88-2003
		& rft_id = info:example-id/77788899
		& req_id = mailto:t.hammond@elsevier.com
		& ...

Note that this could alternately be serialized as an XML document. Other
serializations are also possible. For example, a 'mod_context' RSS module
has already been published on the rss-dev list for review.

[Background. The "info" URI scheme has its origins in the OpenURL Framework.
Initially the Framework defined a 3-tiered naming architecture (URI/ORI/XRI)
but following public comments received a unified approach was adopted
whereby the new "info" URI scheme would allow all public information assets
to be referenced within the global URI naming architecture. Because of its
much wider applicability to Web applications of all kinds it was decided to
make the "info" URI scheme independent of the OpenURL Framework.]

Tony

[1] http://library.caltech.edu/openurl/Public_Comments.htm

-----Original Message-----
From: hardie@qualcomm.com [mailto:hardie@qualcomm.com]
Sent: 08 October 2003 22:35
To: Hammond, Tony (ELSLON); Michael Mealling; Eric Hellman
Cc: uri@w3.org
Subject: RE: uri, urn and info



At 1:46 PM +0100 10/08/2003, Hammond, Tony (ELSLON) wrote:
>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.

So this is a contrast with urn: schemes, which do make a claim about
peristence.


>	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". As such the "info" URI scheme provides a bridging
>mechanism between resource identifiers that are "off the Web" and resource
>identifiers "on the Web".

One of the questions that comes up in reading info: is what that bridge
does--it does not provide a mechanism for dereferencing, and it does not
provide a common minting algorithm or set semantics.  You say below
that it "projects identity" and above that it allows them to be "represented
'on the Web'".  It's very hard to know whether this mechanism is the
right mechanism (or a valuable mechanism) without being clearer what
use is made of these.

If I see info:example-id:77788899, what do I do then that is 'on the Web'?

Thanks for taking the time to discuss this,
					Ted



>	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.)
>
>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.
>
>Hope that helps.
>
>Tony
>
>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 06:56:41 UTC