712OGC URN Internet-Draft

Remove extra dot at the end of the url : draft-creed-ogc-urn-03.txt *.*

Thanks, Yves.

Maybe I'm daft, but wouldn't EPSG:4326 just be replaced with urn:ogc:def:crs:EPSG:6.3:4326? What did you gain by doing that?

I've never understood why a URN like urn:ogc:def:crs:EPSG:6.3:26986 is better than a URL like http://urn.opengis.net/def/crs/EPSG/6.3/26986 which seems to be to be more amenable to being usable in a REST setting anyway. When I go to http://urn.opengis.net there's a web form that generates the URL http://urn.opengis.net/?urn=urn%3Aogc%3Adef%3Acrs%3AEPSG%3A6.3%3A26986&resource=url for that URN. But that results in an HTTP 400 "Bad request". So where does that leave me in knowing anything at all? Note that I'm not picking on OGC, I'm not sure I understand the reasoning behind having constructs in the web that require a resolver other than those already at play in URLs. I guess if the URN components are meant to be non-opaque, then that distinguishes them from URLs that (in REST, at least) should be treated as though they are. Also, in the case of the URN, you have to first find the authority's resolver, which means you're doing a double lookup. And, you're doing it via a mechanism that's not DNS and is thus most likely slower.

Allan, these URNs aren't intended to be resolved. Some of the rationale can be found on the SEE GRID wiki (a site that helps me understand the OGC architecture better than any other). A few of the listed URL weaknesses are bogus, but the case for URNs is made well.

Thanks for the reference, Sean. I think the authors of that Wiki page show a lack of understanding of REST, or at least are being a bit lazy about how they write things down. They also seem to fall into the trap of thinking that URLs must resolve, and that URLs reflect some physical structure on the server in their arguments for the utility of unresolvable identifiers. The bits about well-governed can apply to URLs just as much as to URIs. In the end, their argument comes down to the fact that a URI should be opaque, and that, in turn, brings us right back to Kristian's point. OGC is just replacing one string with another. But that's OGC's prerogative. In the meantime, will all those new OGC URNs get coded into PROJ and other widely used packages? The success or failure of the URN scheme will depend pretty heavily and correlate pretty directly with how quickly and cleanly it gets adopted into open source implementations.

Correction: "In the end, their argument comes down to the fact that a URI should be opaque" should have said URN instead of URI.

I agree that we're trading one name for another, but we can't leave behind the legacy of confusion (coordinate order, etc) around EPSG:4326 unless we do.

My unofficial mantra: "It's the packaging, stupid." I agree that the EPSG:4326 legacy is troubled.