[Auscope-geosciml] Resolver use case
Eric.Boisvert at RNCan-NRCan.gc.ca
Thu Oct 8 12:22:32 EDT 2009
> There remains the global problem of given a new URN with no context, how does one figure out what it points to....
I though the GetCapabilities would provide the root resolver (assuming a cascading resolving mechanism).
I have an issue with this too anyway, because it binds the resolver to the service that delivered the data. It assumes the data comes from a service (killing the "GeoSciML on a CD" use case).
What we needs is a root resolver at iana level that would act as the head of the resolution process, or a registry that we can peek.
but, how do we find the registry ? you all cry and this is where I bring by "box" again.. You should find the url of the resolver the same place you found the url of the wfs/wms/wcs/csw/sos or other 3 letters acronym; a GeoSciML central registry. So far, we have OneGeology that does just that.
Do we need a CGI one ?
De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Stephen M Richard
Envoyé : 8 octobre 2009 12:02
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] Resolver use case
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 https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/CGIRegisterRegister, 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 <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 <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 <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 ?
Spécialiste TI-GI / IT-IM specialist
Eric.Boisvert at rncan.gc.ca, 418-654-3705, facsimile/télécopieur
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/dir/index_f.php?id=4186 <http://cgc.rncan.gc.ca/dir/index_f.php?id=4186> / http://cgc.rncan.gc.ca/dir/index_e.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
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...
More information about the GeoSciML