[Auscope-geosciml] Resolver use case

Rob.Atkinson at csiro.au Rob.Atkinson at csiro.au
Fri Oct 9 05:13:14 EDT 2009


Hi,

Actually the URN should identify the register, not the registry or the owner of the register. The examples show this

urn:cgi:register:CGI:register

cgi

cgi:register is the registry, (I think - a logical definition of the the type of  thing owned by cgi)

CGI:register is the name of the register itself (which is a scoped name in its own right, hence the multi-part form)

One might argue that the register owner (cgi) is incomplete, except that as a registered URN code it is not a ScopedName, its an atomic identifier.

Its confusing because the syntax collapses all these into parts whose position is important, but the absolute position is dependent on the structure of each part.

Rob Atkinson
Team Leader, Interoperable Systems
CSIRO Land & Water
Ph (mobile) +61 419 202 973


________________________________
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: Friday, 9 October 2009 3:02 AM
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?

steve

from 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



================================================================
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
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<mailto: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

Phone:
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20091009/a97f52bd/attachment.htm>


More information about the GeoSciML mailing list