FW: Announcement: A revised I-D for "info"

Hi All:

Hope it is not too inappropriate to post this announcement here on the
SIMILE list given the ongoing discussions about gettable v non-gettable
URIs. This URI scheme ("info") is definitely for non-gettable URIs. The
intent is to be able grandfather legacy namespaces and make the information
assets identified in those namespaces available to web applications such as
XLink, RDF, Topic Maps, OpenURL, etc.

Cheers,

Tony



   Internet-Draft                                   Herbert Van de Sompel 
   Document: draft-vandesompel-info-uri-01.txt                       LANL 
   Expires: June 2004                                        Tony Hammond 
                                                                 Elsevier 
                                                            Eamonn Neylon 
                                                       Manifest Solutions 
                                                         Stuart L. Weibel 
                                                                     OCLC 
                                                                          
                                                            December 2003 
    
                                          
                   The "info" URI Scheme for Information Assets 
                      with Identifiers in Public Namespaces 

   http://www.ietf.org/internet-drafts/draft-vandesompel-info-uri-01.txt


>  -----Original Message-----
> From: 	Hammond, Tony (ELSLON)  
> Sent:	06 December 2003 06:49
> To:	'uri@w3.org'
> Subject:	Announcement: A revised I-D for "info"
> 
> Hi All:
> 
> Following our announcement of the "info" URI scheme a couple months back
> [1] we would like to notify the list of a revision to the I-D which has
> now been posted on the I-D repository [2]. The revision targets three key
> areas which further simplify the "info" URI scheme as a facilitator for
> referencing information assets:
> 
> 	a) "info" now excludes any dereference capability
> 	   Consequence: no resolution systems are to be associated with
> "info" URIs
> 
> 	b) "info" now includes support for full hierarchy
> 	   Consequence: the identifier component of an "info" URI may
> include "/" chars 
> 
> 	c) "info" now includes support for URI fragments
> 	   Consequence: secondary resources may be indirectly identified by
> "info" URIs
> 
> Additionally, three other changes have also been made:
> 
> 	d) The BNF now reuses many of the RFC2396bis productions
> 	   Consequence: facilitates comparison with future generic URI
> syntax
> 
> 	e) Some of the examples have been changed for simplification
> 	   Consequence: removes possible confusion with other works in
> progres
> 
> 	f) Section 7 "Rationale" has been improved
> 	   Consequence: clearer justification why "info" URI scheme is
> required
> 
> Together with this new I-D we are pleased to announce that an early
> implementation of the "info" URI Registry is now available online at the
> "info" website [3]. The namespace registration records are human/machine
> accessible and can be harvested using the OAI-PMH protocol [4].
> Alternative disclosures of registration records using e.g. RDF/XML may be
> made available at a future time.
> 
> Two additional documents are also made available on the "info" website
> [3]:
> 
> 	1. A comprehensive FAQ which answers common questions re "info"
> 	  (Follow the link <About "info" URI> on the menu bar)
> 
> 	2. An "info" Registry policy document
> 	  (Follow the link <Registry Policy> on the menu bar)
> 
> Please note that both documents are currently evolving and are being made
> available at this time for discussion purposes. They should not be treated
> as authoritative but will be improved through comments received. [Also
> note that the link to the I-D on the "info" website points to the previous
> version ('-00'), not the current version ('-01') - we will amend this.]
> 
> We would like to invite feedback on the Registry and associated documents
> and any comments on the revised I-D.
> 
> One particular question we have regards the use of the BNF productions
> from the draft RFC2396bis [5] rather than from the reference RFC2396 [6]
> itself. The reasons are twofold: i) we would like to futureproof this
> specification, and ii) the "segment" production in RFC2396 is overly
> restrictive, and has now been generalized in the work ongoing in the
> successor to that RFC. We believe this is the correct approach - and seems
> to follow the approach taken in the IRI work [7].
> 
> Thanks,
> Tony 
> 
> Tony Hammond
> Advanced Technology Group, Elsevier
> 32 Jamestone Road, London NW1 7BY, UK
> 
> <tel:+44-20-7424-4445>
> <mailto:t.hammond@elsevier.com>
> 
> 
> [1] http://lists.w3.org/Archives/Public/uri/2003Sep/0100.html
> [2] http://www.ietf.org/internet-drafts/draft-vandesompel-info-uri-01.txt
> [3] http://info-uri.info/
> [4] http://www.openarchives.org/OAI/openarchivesprotocol.html
> [5]
> http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-03.txt
> [6] http://www.ietf.org/rfc/rfc2396.txt
> [7] http://www.ietf.org/internet-drafts/draft-duerst-iri-05.txt
> 
>

Received on Sunday, 7 December 2003 05:25:42 UTC