[Auscope-geosciml] Resolver use case

Laxton, John L jll at bgs.ac.uk
Thu Oct 8 12:21:18 EDT 2009

If we are going to have an attribute of scopedName or identifier which is the url of the resolver why not just have an attribute which is the url of the resource and miss out the resolver? Otherwise we have an attribute containing a url to point to a resolver to get the url of the resource - which seems unnecessarily complicated. The only argument I guess is that the url of the resolver will be less ephemeral than the url of the resource - but is that really the case?


From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Stephen M Richard
Sent: 08 October 2009 17:02
To: auscope-geosciml at lists.arcs.org.au
Subject: 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?


from http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19136_Schemas//gmlBase.xsd:<http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19136_Schemas/gmlBase.xsd:>
"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<http://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 Boisvert
Spécialiste TI-GI / IT-IM specialist
Eric.Boisvert at rncan.gc.ca<mailto: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_e.php?id=4186



Auscope-geosciml mailing list

Auscope-geosciml at lists.arcs.org.au<mailto: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<mailto:steve.richard at azgs.az.gov>

This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.

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

More information about the GeoSciML mailing list