Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986)

[Edward Summers <[e-mail]>]

On Apr 17, 2014, at 9:44 PM, Mark Nottingham <[e-mail]> wrote:
> I have to say that I'm sympathetic to the proposed outcomes, albeit for different reasons, perhaps.
> 
> We have two communities using a shared artefact (URIs) with vastly differing use cases and viewpoints about them. Managing this situation has already proven extremely difficult for the IETF, and it seems to me to be very pragmatic to cease forcing them to co-exist, constantly bickering about angels dancing on pins. 
> 
> While people don't want to consider it in-scope for this discussion, I also think that doing so will make the situation with WHATWG and W3C more manageable.

I agree that, as distasteful as it might seem, it’s quite important to discuss the organizational (and personal) politics involved, to the best of our ability, in a respectful and constructive way. Pushing them off the table is just a way of making them an implicit part of any work that we do, which can result in difficulty in interpreting decisions later on...which can be expressed as angels dancing on pins. If possible I would like to hear how the proposed changes could help make the WHATWG/W3C situation more manageable.

The proposed changes to URN seem largely centered on the needs of memory organizations, who are a third community at play here. I am worried that the current draft makes this community seem monolithic in its approach to persistent identifiers and URIs. The current definition of URN as URI has not prevented useful work on persistent identifiers] by memory institutions, notably ARK [1], Memento [2], OpenURL [3], info-uri [4], ISBN [5] and Version Navigation [6] and Dublin Core [7]. I see Larry’s work on things like duri as other examples of useful work that can be done without changing the relationship of URN to URI.

I have personally found the work that has gone into Web architecture, in particular Fielding’s work on REST, has been extremely useful in designing digital preservation systems at the Library of Congress. Taking the Web seriously has lots of real benefits when it comes to application development and sustainability since there is a great diversity in software implementations and maturity with regards to scalability.  I’m not saying there aren’t challenges, but if memory institutions want to continue in their societal role, they must learn to work with the grain of the Web, not against it. I’m thinking of the excellent work that organizations like the Internet Archive have started.

So, as it stands, I think the current draft [8] is too simplistic in its approach, and actually does a fair bit of damage to people in the field. If you would prefer to have specific comments I can try to do that but I am having trouble decoding the politics at play here.

//Ed

[1] http://tools.ietf.org/id/draft-kunze-ark
[2] https://www.ietf.org/rfc/rfc7089.txt
[3] https://en.wikipedia.org/wiki/OpenURL
[4] https://www.ietf.org/rfc/rfc4452.txt
[5] https://www.ietf.org/rfc/rfc3187.txt
[6] https://www.ietf.org/rfc/rfc5829.txt
[7] http://dublincore.org/documents/dces/
[8] https://tools.ietf.org/id/draft-ietf-urnbis-urns-are-not-uris