"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Object identifiers in GML

Also see GmlIdentifiersDiscussion

Contents

Related pages



gml:id attribute

gml:id is a standard GML attribute available on every object-with-identity. It has type="xs:ID" - i.e. it is a fragment identifier, unique within document scope only, for internal cross-references. It is not useful by itself as a persistent unique identifier.

Example

Document URL: http://www.fakedomain.org/testdoc1.xml

...
<awd:WQ_Station gml:id="mdbcs99"> ... </awd:WQ_Station>
...

Reference to a node identified in this way

Full URL: xlink:href="http://www.fakedomain.org/testdoc1.xml#mdbcs99"

Cross-reference within the same document xlink:href="#mdbcs99"

These combine standard URI (including XPointer) rules combined with standard xlink semantics. The full URL form is dependent on the stability of the URL of the host document.

Note: under the http protocol, the fragment after the "#" is not sent to the server; and fragment resolution is done by the client. Thus using the extended URL for a refernece will usually incur the overhead of transmitting the entire document.

uuid attribute

uuid is an optional attribute available on every object-with-identity, provided in the GMD schemas that implement ISO 19115 in XML. May be used as a persistent unique identifier, but only available within GMD context.

Example

Document URL: http://www.fakedomain.org/testdoc1.xml

...
<gmd:CI_ResponsibleParty uuid="47a86de0-791b-11db-9fe1-0800200c9a66"> ... </gmd:CI_ResponsibleParty>
...

Reference to a node identified in this way

URI: xlink:href="urn:uuid:47a86de0-791b-11db-9fe1-0800200c9a66"

UUID reference: uuidref="47a86de0-791b-11db-9fe1-0800200c9a66"

These require adoption of a strict convention that the UUID denoting an object is recorded in the ./@uuid attribute.

gml:name element

gml:name is a standard GML property. It has type="gml:CodeType" - i.e. ./@codeSpace optional. [0..*] gml:name elements may appear; [1..*] on objects derived from gml:Definition (GML v3.1 or earlier). Multiple names may be disambiguated through the value of ./@codeSpace.

Example

Document URL: http://www.fakedomain.org/testdoc2.xml

...
<swe:Phenomenon gml:id="speed">
      <gml:name codeSpace="urn:ietf:rfc:2141">urn:ogc:def:phenomenon:OGC:Speed</gml:name>
      <gml:name codeSpace="urn:ietf:rfc:1738">https://svn.opengeospatial.org:8443/ogc-projects/ows/swe/trunk/sweCommon/current/examples/phenomena.xml#Speed</gml:name>
      <gml:name codeSpace="urn:ietf:rfc:1738">http://sweet.jpl.nasa.gov/ontology/property.owl#Speed</gml:name>
      <gml:name codeSpace="http://sweet.jpl.nasa.gov/ontology/property.owl">Speed</gml:name>
      ...
</swe:Phenomenon>
...

These are valid alternative names for the same concept.

N.B. urn:ietf:rfc:2141 denotes the RFC for URN syntax. urn:ietf:rfc:1738 denotes the RFC for URL syntax.

Reference to a node identified in this way

URL: xlink:href="http://www.fakedomain.org/testdoc2.xml#speed"

xlink:href="http://www.fakedomain.org/testdoc2.xml#xpointer(//swe:Phenomenon[./gml:name="urn:ogc:def:phenomenon:OGC:Speed"])" etc

xlink:href="http://www.fakedomain.org/testdoc2.xml#xpointer(//swe:Phenomenon[./gml:name[@codeSpace="http://sweet.jpl.nasa.gov/ontology/property.owl"]="Speed"])" etc

These combine standard URI (including XPointer) rules combined with standard xlink semantics. But they are dependent on the stability of the URL of the host document.

URI: xlink:href="urn:ogc:def:phenomenon:OGC:Speed"

xlink:href="http://sweet.jpl.nasa.gov/ontology/property.owl#Speed"

These are independent of the host-document, but do not follow "standard" xlinking semantics, so require adoption of a strict convention that a URI denoting the object is recorded in a gml:name element (but which one!?)

gml:identifier element

gml:identifier is a standard GML v3.2 property. It has type="gml:CodeWithAuthorityType" - i.e. ./@codeSpace required. [0..1] gml:identifier elements may appear; [1..1] on objects derived from gml:Definition (GML v3.2 or later).

Example

-Document URL: http://www.fakedomain.org/testdoc3.xml

...
<swe:Phenomenon gml:id="speed">
      <gml:identifier codeSpace="urn:ietf:rfc:2141">urn:ogc:def:phenomenon:OGC:Speed</gml:identifier>
      <gml:name codeSpace="urn:ietf:rfc:1738">https://svn.opengeospatial.org:8443/ogc-projects/ows/swe/trunk/sweCommon/current/examples/phenomena.xml#Speed</gml:name>
      <gml:name codeSpace="urn:ietf:rfc:1738">http://sweet.jpl.nasa.gov/ontology/property.owl#Speed</gml:name>
      <gml:name codeSpace="http://sweet.jpl.nasa.gov/ontology/property.owl">Speed</gml:name>
      ...
</swe:Phenomenon>
...

These are valid alternative names for the same concept.

N.B. urn:ietf:rfc:2141 denotes the RFC for URN syntax. urn:ietf:rfc:1738 denotes the RFC for URL syntax.

Reference to a node identified in this way

URL: xlink:href="http://www.fakedomain.org/testdoc2.xml#speed"

xlink:href="http://www.fakedomain.org/testdoc2.xml#xpointer(//swe:Phenomenon[./gml:identifier="urn:ogc:def:phenomenon:OGC:Speed"])" etc

xlink:href="http://www.fakedomain.org/testdoc2.xml#xpointer(//swe:Phenomenon[./gml:name[@codeSpace="http://sweet.jpl.nasa.gov/ontology/property.owl"]="Speed"])" etc

These combine standard URI (including XPointer) rules combined with standard xlink semantics. But they are dependent on the stability of the URL of the host document.

URI: xlink:href="urn:ogc:def:phenomenon:OGC:Speed"

This is independent of the host-document, but does not follow "standard" xlinking semantics, so requires adoption of a strict convention that the canonical URI denoting an object is recorded in the gml:identifier element.

-- SimonCox - 21 Nov 2006

"Primary" and "Foreign" keys

gml:name and gml:id are used to assert or record the assignment of a key to an information item - the value of the gml:name or gml:id is a "primary key" for the item.

xlink:href on a property element is used to refer to another information item - the value of the xlink:href is the "foreign key" for the other item.

In the case of gml:name, the "authority" is made explicit, which allows a single tag (gml:name) to be used for multiple aliases without risk of ambiguity - hence the @codeSpace attribute. The identifier can be a word, a number, a string, or a URI, etc. If the identifier is a urn, then the codespace is the URN scheme, which is defined by RFC 2141 and thus is identified by the URN for that RFC - i.e. urn:ietf:rfc:2141 . There is no "codeSpace" associated with an xlink:href reference - it is a URI by definition, which simply means that you refer to http://www.iana.org/assignments/uri-schemes.html to figure out how to resolve it, which in turn points through to http://www.iana.org/assignments/urn-namespaces for URN's.

A proposal for best practice patterns in cross-referencing

The issue of cross-referencing using xlink attributes in the context of the GML property "by-reference" pattern was the subject of a discussion in Canberra 2006-12-01 involving SimonCox, ClemensPortele, RobAtkinson and JoshLieberman. Rob had raised the issue primarily because of the concerns outlined in TermResolutionMechanisms but the Canberra discussion focussed on the related, but tighter, issue of resolution of URIs that are the value of xlink:href attributes.

As a background to the issue, also read ResourceIdentifiers.

By the end of the time allotted, the consensus was that there are only two basic patterns:

  1. if the reference is of the form xlink:href="http://..." (i.e. a URL or "http URI") then
    • the reader should resolve the reference using the standard http resolution mechanisms
    • if the resource is not available, there is no fallback
  2. if the value of the reference is not directly resolvable (e.g. a URN or UUID) then
    • if there are local/community rules for resolution, then use them, else
    • the value of xlink:role should provide information about a resolver service
      • Note: xlink:role was selected for consistency with AndrewWoolf's proposed usage for converting non-GML resources (e.g. netCDF). This is provisional and may be changed.
      • Note: a URN or UUID is generally considered to be suitable for persistent identifiers, or identifiers of non-instantiable resources.

However, for case 2 we did not figure out the details of the resolver, e.g.
  • is it a URL of a resolver instance (with attendant brittleness) or a resolver type (how defined?
  • how is the identifier (URN, UUID, etc) passed to the resolver, syntax etc

-- SimonCox - 06 Dec 2006

-- SimonCox - 05 Feb 2009

I added a document where I tried to look at the URN resolution (and external references in general) from the point of view of the client application. The document is for implementation of a resolution mechanism for GIN. One big important architectural difference here is that GIN has a "layer" on top of data provider service where many services and catalogs can exists (same for US GIN I believe) which is not the case for OneGeology or our international group in general (you might remember my GeoSciML 'Box' for those who were in Quebec). In GIN, we have that box. So we have a nice spot for a resolver. Which is maybe not the case for an unstructured collection of GeoSciML providers.

-- EricBoisvert - 2009-11-25
 
Topic revision: r12 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).