[Auscope-geosciml] Resolver use case

Stephen M Richard steve.richard at azgs.az.gov
Thu Oct 8 12:01:48 EDT 2009

As usual, its amazing what you can find trolling around the TWIKI!  We 
had this discussion a while back, and the idea of using the codespace as 
the url for the URN resolver was criticized on the grounds that its 
equivalent to just using a url as the identifier.  It seems that given 
the assumption that url's are transient, the use of the resolver URL as 
the codespace violates the intent of codespace, which identifies  the 
authority assigning a name (identifier) to something (see chapter and 
verse below). If the resolver changes url location, the codespace would 
need to change, with the implication that the name might identify 
something different.

Using http://www.cgi-iugs.org/uri as the codespace seems fine, but since 
it shouldn't be interpreted as a resolver URL, perhaps we should use a 
cgi urn here. The likely candidate would be 
|urn:cgi:register:CGI:register, |which identifies our current root 
registry at 
which contains the information necessary to track down most cgi urn's to 
what kind of thing they identify, and what authority is assigning the name.

There remains the global problem of given a new URN with no context, how 
does one figure out what it points to.... This currently requires a 
brute force visit to the ietf urn registry 
(http://www.iana.org/assignments/urn-namespaces/), discovery of the RFC 
for the urn namespace of interest (RFC5138 in the case of CGI), then to 
that RFC (http://www.faqs.org/rfcs/rfc5138.html), which in the cgi case 
has broken links to the identifier scheme page 
(http://www.cgi-iugs.org/CGIIdentifierScheme) and the resolver 
(http://www.cgi-iugs.org/uri).  Hmmm, so how is the any better than just 
using urls' for identifiers???

Perhaps scopedName or identifier elements should include an additional 
attribute 'resolver' that is the url for the current resolver location 
when the document containing the element is generated?


"The gml:name property provides a label or identifier for the object, 
commonly a descriptive name. An object may have several names, typically 
assigned by different authorities. gml:name uses the gml:CodeType 
content model.  The authority for a name is indicated by the value of 
its (optional) codeSpace attribute.  The name may or may not be unique, 
as determined by the rules of the organization responsible for the 
codeSpace.  In common usage there will be one name per authority, so a 
processing application may select the name from its preferred codeSpace."

Boisvert, Eric wrote:
> I'm writing the resolver use case and the more I dig in the details, 
> the more I find road blocks.  I think the first document I will submit 
> to the group is a discussion document, where I expose many of the 
> issues I found (I'm at #12) that should be addressed before we write 
> any useful use case.
> One thing I want to push to the group is the 
> codeSpace="urn:ietf:rfc:2141" vs codeSpace="www.cgi-iugs.org/uri".  I 
> vaguely remember that we should now use the latter.
> I read in 
> _https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/CGIIdentifierScheme#Object_and_Feature_identifiers_ 
> *Object and Feature identifiers *
> Attach an identifier to a GML-encoded feature or object using 
> gml:identifier (GML 3.2 and later) or gml:name (GML 3.1 and earlier) 
> using the following pattern:
> <gml:identifier codeSpace="http://www.cgi-iugs.org/uri 
> ">urn:cgi:feature:USGS:2feb49bc-6755-11dc-8314-0800200c9a66</gsml:value>
> <gml:name codeSpace="http://www.cgi-iugs.org/uri 
> ">urn:cgi:party:GA:LesleyWyborn</gsml:value>
> _http://www.cgi-iugs.org/uri_ is the address of the CGI URN resolver, 
> as specified in RFC 5138.
> The RFC 5138 says that there is a URN at this location 
> (_http://www.cgi-iugs.org/uri_) which by the way does not work 
> anymore, but it does not say that the codeSpace_* must*_ contain the 
> url of the resolver. In other words, are we using this url in the 
> codeSpace just as a_ flag_, or to indicate_ where the resolver is_.  
> The fact that this url does not anymore is a good demonstration of the 
> issue here, isn't it ?
> Eric
> ================================================================
> Eric Boisvert
> Spécialiste TI-GI / IT-IM specialist
> Eric.Boisvert at rncan.gc.ca, 418-654-3705, facsimile/télécopieur
> 418-654-2615
> 490, rue de la Couronne, Québec (Québec), G1K 9A9
> 490, rue de la Couronne, Quebec, Quebec, G1K 9A9
> Laboratoire de cartographie numérique et de photogrammétrie (LCNP)
> Digital Cartography and Photogrammetry Laboratory (DCPL)
> Commission géologique du Canada (Québec) / Geological Survey of Canada 
> (Quebec)
> Ressources naturelles Canada / Natural Resources Canada
> Gouvernement du Canada / Government of Canada
> _http://cgc.rncan.gc.ca/org/quebec_
> _http://cgc.rncan.gc.ca/dir/index_f.php?id=4186_ / 
> _http://cgc.rncan.gc.ca/dir/index_e.php?id=4186_
> ------------------------------------------------------------------------
> _______________________________________________
> Auscope-geosciml mailing list
> Auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Office: (520) 209-4127
Reception: (520) 770-3500 
FAX: (520) 770-3505

email: steve.richard at azgs.az.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20091008/d0fa6cf4/attachment.htm>

More information about the GeoSciML mailing list