[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Handle-info] URI Scheme



Title: Re: [Handle-info] URI Scheme
Hi Dan:

> Maybe we should collectively author the submission, so it comes from the community.

That is one approach.

I would say, however, we should still consider the possibility of minimizing the impact of introducing yet another new URI scheme (which is an innovation actively disliked in certain quarters) by tucking it away in a revised RFC. That would downplay any untoward attention. Seems to me to be the most likely thing to do in view of:

    1. The RFC is being revised anyway

    2. Handle is a registered Internet protocol (albeit with those grumpy IESG disclaimers)

    3. If it’s good enough for HTTP, it’s good enough for Handle

    4. It’s just plain tidier

I would also draw attention to this recent post on the URI list:

    http://lists.w3.org/Archives/Public/uri/2008Feb/0001.html

    “Ted [Hardie, Area Director, Applications] reminded me that IETF-wide review and IESG evaluation aren't  
required for all URI registrations, even those for permanent status.   
IETF review and IESG evaluation may be required at the discretion of  
the expert reviewer, assuming that the author of the registration has  
not already chosen to put a document containing the registration  
through IETF review and IESG evaluation.”

I would like to point out that this passage in Sect. 2 of the “info” RFC 4452:

    http://www.ietf.org/rfc/rfc4452.txt

    “The registration of a public namespace in the "info" Registry SHALL
   NOT preclude further development of services associated with that
   namespace that MAY qualify the namespace for additional publication
   elsewhere within the URI allocation.”

That is, the intent of the “info” URI scheme was to act as a bootstrapping mechanism. Namespaces registered under it are free to go on and register their own URI schemes. It was envisaged that certain schemes (e.g. “doi:”, “hdl:”) would go on to register in their own right. One would thus be able to reconcile URIs minted under “info” and those under a native URI scheme as folllows:

    <info:hdl/1234/567> <owl:sameAs> <hdl:1234/567> .

Cheers,

Tony



On 11/2/08 18:28, "Daniel Rehak" <daniel.rehak@gmail.com> wrote:

I've had chats with Larry about this in the past.
I think it is needed.

I know there might be politics involved, but it's time to revisit it.

I'll also endorse the idea for my colleagues in Australia working on their projects.

Maybe we should collectively author the submission, so it comes from the community.

     - Dan

On Feb 11, 2008 1:07 PM, Sean Reilly <sreilly@cnri.reston.va.us> wrote:

On Feb 11, 2008, at 5:25 PM, Hammond, Tony wrote:

> Thanks Sean for the confirmation (and explanation).
>
> Might it not be appropriate now to consider issuing a revised RFC at
> some
> point (hopefuly soon) to firm up the current position of the HS?
> These diffs
> (as well as the type diffs which I also questioned) could be taken
> care of
> in some kind of 5-year overhaul of the RFC. (And note that some
> standards
> e.g. NISO have a 5-year review.)

We do have plans to revise/update/clean-up the RFCs to clarify the
issue you mentioned as well as a few other minor issues.

> And another open question, which I hate to mention, but it's still
> open -
> and therefore fair game, is about a native URI scheme for handle, or
> URN
> namespace if that's preferred  - or both (there is a precedent, I
> think, but
> can't remember off the top of my head).
>
> I know that a "doi:" registration is likely deferring to an eventual
> ISO
> imprimatur on the DOI System, but not sure that that has any direct
> bearing
> on handle. I wonder if it might be appropriate to consider the
> bundling of a
> URI scheme specification (or URN) together with any revised RFC
> spec, rather
> than being undertaken as a separate business (which will only draw
> flak and
> grief and "woe is us"). Other protocols - notably HTTP (RC 2616) - are
> responsible for declaring their own URI schemes. Seems to me this
> could be
> the right opportunity to deftly tuck that away in some kind of
> appendix.
> There has already been a relaxing of the URI registration stranglehold
> (witness "info"). And may be better to get in before the "linked
> data" wave
> converges all to HTTP.

Great idea, I would like to see a top level handle URI.  One potential
issue with the registration authority might be registering a top level
scheme (hdl:) that is already represented by existing URIs (info:hdl
or urn:hdl).  Although there are some that would argue http://hdl.handle.net/
  is an existing "scheme" and therefore hdl: isn't needed.  Of course
that doesn't mean we shouldn't try.

I think the design of the top level hdl: URI scheme would be a good
topic of discussion on this list.  Anyone else have any input/
preferences?

Cheers,
Sean


_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info



********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************