For Membership & Sponsorship Enquiries +44 (0)1489 668 340

Technical guidance on the encoding of UK GEMINI

Return to GEMINI 2.3 home page

1. Introduction

1.1 Purpose of guidelines

1.2 Scope

1.3 Assumed knowledge

1.4 Terminology

1.5 Structure of document

1.6 XML fragments

2. Encoding Guidelines

2.1 Schemas

2.2 Common concepts

2.3 Metadata for datasets and dataset series

2.4 Metadata for services

Appendices

XML Element Order

Dataset metadata instance example

Series metadata instance example

Service metadata instance example

1. Introduction

1.1 Purpose of guidelines

The purpose of these guidelines is to explain, with the aid of examples, how to encode UK GEMINI metadata using XSD schemas of ISO / TC 211. Examples are in the form of fragments of XML.

UK GEMINI metadata may be for a dataset, dataset series or a service. The encoding of all types is covered.

1.2 Scope

The scope of these guidelines is the encoding of UK GEMINI [4]according to ISO 19139, ISO 19119 and ISO 19136, in a way that adheres to the INSPIRE technical guidelines [9] for encoding metadata.

Outside the scope of this document is the description of GEMINI2 metadata items, their content, obligation and meaning. Readers seeking this information should consult the GEMINI2 standard [4].

1.3 Assumed knowledge

It is assumed that readers will be familiar with XML. Readers who require background information are referred to the W3Schools introduction to XML:

Readers requiring an introduction to XML Schemas are referred to the W3Schools XML Schema tutorial:

1.4 Terminology

A Glossary is provided here.

1.5 Structure of document

The core section, Encoding Guidelines, is split into four principal sections

  • The first section deals with the schemas
  • The second deals with concepts which are common to all kinds of GEMINI2 metadata instances.
  • The third explains the encoding of metadata for datasets and dataset series.
  • The fourth section explains the encoding of encoding metadata for services.

There is some overlap, and therefore duplication, between the sections but it is felt that this approach is best in that it clearly indicates the requirements for each type of metadata.

The 'Metadata for datasets and dataset series' and 'Metadata for services' sections list metadata items from GEMINI2 in the order that they appear in GEMINI2. XML elements in an XML document must follow the order expressed in the XSD schema to which the XML document conforms. The order of XML element expressed by the XSD schema will not be the same as the order of metadata items in GEMINI2.

Examples are provided by way of XML fragments throughout the document. Full metadata instances are shown here:

Dataset metadata instance example

Series metadata instance example

Service metadata instance example

1.6 XML Fragments

This document contains examples of XML encoding. The examples are considered fragments in that they are not complete XML documents. The following conventions are used:

  • The root element will generally be shown and it shall be gmd:MD_Metadata
  • XML element tags will generally be shown on a single line
  • XML will be tabbed in where possible to aid reading
  • Where an XML element, including the start tag, end tag and content, is too long to show on a single line, it shall break across more than one line automatically (i.e. under the control of browser justification and text wrapping)
  • Missing XML content, removed while forming the fragment, shall be represented by an ellipsis (...)
Figure 1 – XML fragment – tabbing

<gmd:MD_Metadata>
   <gmd:fileIdentifier>
     <gco:CharacterString>98e25be5-388d-4be3-bc5f-ba07ef6009b2</gco:CharacterString>
   </gmd:fileIdentifier>
   ...
</gmd:MD_Metadata>

Figure 1 shows an example of an XML fragment. Note that it starts with the XML element gmd:MD_Metadata. The next XML element in order is gmd:fileIdentifier and its start-tag is on the next line and is tabbed in. The following line is the content of gmd:fileIdentifier.

An ellipsis follows the end tag of the XML element gmd:fileIdentifier indicating that other content is missing

Also deliberately omitted from XML fragments is:

  • The XML declaration
  • XML namespace identifiers

In the example in Figure 1 CharacterString is an XML element in the namespace gco. It has the start-tag <gco:CharacterString> and the end-tag </gco:CharacterString>. The string 98e25be5-388d-4be3-bc5f-ba07ef6009b2 is the element’s content. The CharacterString element forms the content of another element: fileIdentifier. Its start-tag is <gmd:fileIdentifier> and its end-tag is </gmd:fileIdentifier>.  In the example below gml:id and codeSpace are XML attributes. XML attributes are encoded in the start-tag of an element with the form [namespace]:[attributeName]="[content]".

Figure 2 - XML attributes 
...
<gmx:CodeDefinition gml:id="MD_ScopeCode_dataset">
   <gml:description>information applies to the dataset</gml:description>
   <gml:identifier codeSpace="ISOTC211/19115">dataset</gml:identifier>
</gmx:CodeDefinition>
...

Note that there is no reason in practice to tab in XML and to present each XML element on a new line other than to aid humans in reading raw XML. XML parsers, on the other hand, would have no problem reading the XML were it encoded without carriage returns as shown in Figure 3.

Figure 3 - XML fragment - no tabbing 
<gmd:MD_Metadata><gmd:fileIdentifier><gco:CharacterString>98e25be5-388d-4be3-bc5f-ba07ef6009b2</gco:CharacterString></gmd:fileIdentifier></gmd:MD_Metadata>

The UK Location Information Infrastructure will accept any valid XML document that conforms to these guidelines. This includes canonical XML encodings [5] and files laid out with additional white space for human readability, and other variants in between. Similarly, XML attribute values could be delimited using single or double quotes.

2. Encoding Guidelines

2.1 Schemas

The schemas defining the structure of GEMINI2 metadata instances must implement:

  • ISO 19139:2007 – for a physical implementation of ISO 19115:2003
  • ISO 19119:2005 – for service metadata
  • ISO 19136:2007 – for GML

Several schema sets have been identified as meeting these requirements:

  1. http://schemas.opengis.net/csw/2.0.2/profiles/apiso/1.0.0/apiso.xsd, provided by OGC
  2. http://inspire.ec.europa.eu/draft-schemas/inspire-md-schemas/apiso-inspire/apiso-inspire.xsd, provided by JRC
  3. http://schemas.opengis.net/iso/19139/20070417, provided by OGC.

Both 1 & 2 import the same dataset schemas, which are authoritatively at the ISO TC211 resource site: https://schemas.isotc211.org/schemas/19139/

The schema files that shall be used for validating GEMINI2 metadata instances are:

  • gmx.xsd (Datasets and dataset series metadata)
  • gmx.xsd and srv.xsd (Service metadata)

The AP-ISO schema files given above import both of these, so a validator does not need to determine what type of record it is validating.

With schema set 3, the dataset and service schemas have separate entry points: gmx/gmx.xsd and srv/srv.xsd

Notes:

  1. the schemas provided by ISO TC211 do not include anything for ISO 19119 service metadata, but could be used directly to validate dataset metadata
  2. the older draft schemas published at http://schemas.opengis.net/iso/19139/20060504/ import GML version 3.1 instead of GML 3.2, so records that validate with one will not validate with the other.
  3. the UK GEMINI schema that was published on GI Gateway [service withdrawn in 2012] encodes GEMINI1, not GEMINI2. Also, it does not conform with INSPIRE technical guidance. Therefore, it cannot be used to encode GEMINI2 and shall not be used for metadata instances within UK Location.

Schema Validation

The XML schemaLocation property officially provides only a ‘hint’ to the validator, but many validators do use the schemas at that location.

The INSPIRE Geoportal Harvesting Checker at http://inspire-geoportal.ec.europa.eu/validator2/ emulates the checks performed by the INSPIRE geoportal during its harvesting process, including schema validation.

The INSPIRE Validator at http://inspire-sandbox.jrc.ec.europa.eu/validator/ includes metadata validation. Currently the schema validation uses the schemas hinted at in the schemaLocation property of the file.

2.2 Common concepts

2.2.1 XML declaration

Metadata instances are XML documents. XML documents should, but do not have to, begin with an XML declaration. If a metadata instance has an XML declaration then it must be the first line in the document. It must not be preceded by anything else, other than an invisible Unicode byte-order mark.

Figure 4 shows an XML declaration. The version attribute must always have the value 1.0. The encoding attribute is optional. Its value specifies which character set is in use in the document. By default (i.e. if the encoding attribute is omitted) XML documents are assumed to be encoded in the UTF-8 encoding of the Unicode character set. Care should be taken when using text editing software to edit XML, or writing XML using bespoke software code, that the XML’s actual physical encoding conforms with the encoding stated with this attribute. It is expected that the UTF-8 character set will be sufficient in nearly all cases.

An XML declaration may include a “standalone” attribute. However, this attribute is only relevant if an XML document is using a DTD. Metadata instances of GEMINI2 shall not use a DTD so it is out of scope.

Figure 4 - XML declaration 
<?xml version="1.0" encoding="utf-8"?>

2.2.2 Root element

The root element of a GEMINI2 metadata instance shall be gmd:MD_Metadata. The root element shall contain namespace references to, at least, gmd, gco, gml and xlink. Metadata for services shall, in addition, contain a namespace reference to srv. In addition reference may be made to the gmx namespace if XML elements such as gmx:Anchor are used.

An example is shown in Figure 5. Subsequent examples omit the namespace references for brevity. An ellipsis is used to indicate that required content has been omitted.

Figure  5 - Root Element
<?xml version="1.0" encoding="utf-8"?>
<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd"
                 xmlns:gco="http://www.isotc211.org/2005/gco"
                 xmlns:srv="http://www.isotc211.org/2005/srv"
                 xmlns:gml="http://www.opengis.net/gml/3.2"
                 xmlns:xlink="http://www.w3.org/1999/xlink">
  ...
</gmd:MD_Metadata>

The namespace identifier for gmd shall be: http://www.isotc211.org/2005/gmd

The namespace identifier for gco shall be: http://www.isotc211.org/2005/gco

The namespace identifier for srv shall be: http://www.isotc211.org/2005/srv

The namespace identifier for gmx shall be: http://www.isotc211.org/2005/gmx

The namespace identifier for xlink shall be: http://www.w3.org/1999/xlink

The namespace identifier for gml shall be: http://www.opengis.net/gml/3.2

Note that  http://www.opengis.net/gml/3.2 refers to GML version 3.2.1 not GML version 3.2.0.

The root element, and in fact any element in an XML instance, may have an attribute called xsi:schemaLocation which contains a value or set of values hinting at the physical location of schemas which may be used for validation. Since this attribute provides only a hint, validating parsers are allowed to ignore it and use other means of locating the relevant schemas.

Figure 6 shows a root element containing an xsi:schemaLocation attribute. Here the schemas referenced are in the INSPIRE Metadata XSD repository.

Since the xsi:schemaLocation attribute exists in the xsi namespace, this namespace must be referenced. The xsi:schemaLocation attribute contains a pair of space separated values when one schema is identified. The first value specifies the namespace and the second value specifies the schema to use to validate elements in that namespace. When more than one schema is identified, as would be the case for validating a service metadata instance, the attribute contains a space separated sequence of namespace / schema pairs. The xsi:schemaLocation attribute is not required in a GEMINI2 metadata instance.

Figure 6 - Using the xsi:schemaLocation attribute
<?xml version="1.0" encoding="utf-8"?>
<gmd:MD_Metadata xmlns:gmx="http://www.isotc211.org/2005/gmx"
    xmlns:gmd="http://www.isotc211.org/2005/gmd"
    xmlns:gco="http://www.isotc211.org/2005/gco"
    xmlns:srv="http://www.isotc211.org/2005/srv"
    xmlns:gml="http://www.opengis.net/gml/3.2"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.isotc211.org/2005/gmx
        https://schemas.isotc211.org/schemas/19139/-/gmx/1.0/gmx.xsd
        http://www.isotc211.org/2005/srv
        http://inspire.ec.europa.eu/draft-schemas/inspire-md-schemas/srv/1.0/srv.xsd">
  ...
</gmd:MD_Metadata>

2.2.3 Dates and Times

Dates and date-time shall be expressed in the Gregorian calendar and UTC as per ISO 8601. The formatting shall be as follows, in order of increasing precision:

  • yyyy (e.g. 1995)
  • yyyy-MM (e.g. 1995-01)
  • yyyy-MM-dd (e.g. 1995-01-25)
  • yyyy-MM-ddThh:mm:ss (e.g. 1995-01-25T12:01:55)

The ISO 8601 encoding also allows negative dates to represent BC. However, gco:Date and gco:DateTime XML elements do not accept negative values.

The GEMINI2 standard states that temporal extents may be given with as coarse a granularity as century (e.g. yy or 19). However, unfortunately this cannot be encoded in ISO 19139 XML and will result in a schema validation error. The lowest level of granularity allowable is the year.

2.2.4 Element order

XML elements in a metadata instance must follow the order in which the elements are defined in an XSD schema. Failure to do so will result in schema validation errors. The order of XML elements and their corresponding GEMINI2 metadata items is shown here.

2.2.5 Patterns for multiple instances

Some metadata items, such as alternative title, have cardinalities for more than one. This means that more than one instance of the item can be encoded in metadata instances. The general approach in ISO 19139 XML is that an XML element expressing the property, in Figure7 gmd:alternateTitle, contains an XML element which expresses the data type and contains the value, in this case gco:CharacterString. Note that more than one alternative title is expressed by repeating the gmd:alternateTitle XML element, not the gco:CharacterString XML element (shown in an invalid example in Figure 8). This pattern is followed throughout ISO 19139 XML including for XML elements that have complex content, such as gmd:identificationInfo (Figure 9).

Figure 7 - Multiple alternative title elements
  ...
<gmd:alternateTitle>
  <gco:CharacterString>Digital Geological Map Data of Great Britain - 625k</gco:CharacterString>
</gmd:alternateTitle>
<gmd:alternateTitle>
  <gco:CharacterString>DiGMapGB-625</gco:CharacterString>
</gmd:alternateTitle>
...
Figure 8 - Multiple alternative title elements - invalid encoding
...
<gmd:alternateTitle>
  <gco:CharacterString>Digital Geological Map Data of Great Britain - 625k</gco:CharacterString>
  <gco:CharacterString>DiGMapGB-625</gco:CharacterString>
</gmd:alternateTitle>
...
Figure 9 - Multiple identification information elements 
<gmd:MD_Metadata>
  ...
  <gmd:identificationInfo>
   <gmd:MD_DataIdentification id="_local-id1">
     ...
   </gmd:MD_DataIdentification>
</gmd:identificationInfo>
  <gmd:identificationInfo>
    <gmd:MD_DataIdentification id="_local-id2">
     ...
    </gmd:MD_DataIdentification>
  </gmd:identificationInfo>
  ...
</gmd:MD_Metadata> 

2.2.6 File identifier

The first XML child element of any GEMINI2 metadata instance shall be gmd:fileIdentifier. The content of this XML element is the identifier of the metadata instance.   File identifier is not to be confused with the metadata item Resource Identifier.

The content of the XML element shall be a unique managed identifier, such as a system generated UUID. Once the identifier has been set for a metadata instance it shall not change.

Figure 10 - File Identifier
<gmd:MD_Metadata>
  <gmd:fileIdentifier>
    <gco:CharacterString>98e25be5-388d-4be3-bc5f-ba07ef6009b2</gco:CharacterString>
  </gmd:fileIdentifier>
  ...
</gmd:MD_Metadata> 

2.2.7 Citation

External resources, such as publications, controlled vocabularies, are expressed using the ISO 19115 class CI_Citation and its XML element instance, gmd:CI_Citation. This is a common structure that is used to encode:

  • Resource reference information about datasets and series
  • Resource reference information about services
  • Information about the originating controlled vocabulary of keywords
  • The specification for conformance statements
  • The authority of Spatial Reference System
  • The authority of Extent

A citation must include at least a title, a date and a date type. Figure 11 shows the citation structure used to encode information about the GEMET Concepts dictionary.

In any one citation there may be more than one date. However, there shall be only one date with a date type of ‘creation’ and there shall be only one date with type 'revision'.

Figure 11 - CI_Citation structure
...
<gmd:CI_Citation>
  <gmd:title>
    <gco:CharacterString>GEMET - Concepts, version 2.4</gco:CharacterString>
  </gmd:title>
  <gmd:date>
    <gmd:CI_Date>
      <gmd:date>
        <gco:Date>2010-01-13</gco:Date>
      </gmd:date>
      <gmd:dateType>
        <gmd:CI_DateTypeCode codeList="https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml#CI_DateTypeCode" codeListValue="revision">revision</gmd:CI_DateTypeCode>
      </gmd:dateType>
    </gmd:CI_Date>
  </gmd:date>
</gmd:CI_Citation>
...

 2.2.8 Responsible party

Figure 12 - CI_ResponsibleParty structure 
 ...
<gmd:CI_ResponsibleParty>
  <gmd:organisationName>
    <gco:CharacterString>SeaZone Solutions</gco:CharacterString>
  </gmd:organisationName>
  <gmd:positionName>
    <gco:CharacterString>Data Product Manager</gco:CharacterString>
  </gmd:positionName>
  <gmd:contactInfo>
    <gmd:CI_Contact>
      <gmd:phone>
        <gmd:CI_Telephone>
          <gmd:voice>
            <gco:CharacterString>+44 (0) 870 013 0607</gco:CharacterString>
          </gmd:voice>
          <gmd:facsimile>
            <gco:CharacterString>+44 (0) 870 013 0608</gco:CharacterString>
          </gmd:facsimile>
        </gmd:CI_Telephone>
      </gmd:phone>
      <gmd:address>
        <gmd:CI_Address>
          <gmd:deliveryPoint>
            <gco:CharacterString>Red Lion House</gco:CharacterString>
          </gmd:deliveryPoint>
          <gmd:deliveryPoint>
            <gco:CharacterString>Bentley</gco:CharacterString>
          </gmd:deliveryPoint>
          <gmd:administrativeArea>
            <gco:CharacterString>Hampshire</gco:CharacterString>
          </gmd:administrativeArea>
          <gmd:postalCode>
            <gco:CharacterString>GU10 5HY</gco:CharacterString>
          </gmd:postalCode>
          <gmd:electronicMailAddress>
            <gco:CharacterString>This email address is being protected from spambots. You need JavaScript enabled to view it.</gco:CharacterString>
          </gmd:electronicMailAddress>
        </gmd:CI_Address>
      </gmd:address>
      <gmd:onlineResource>
        <gmd:CI_OnlineResource>
          <gmd:linkage>
            <gmd:URL>http://www.seazone.com/index.php</gmd:URL>
          </gmd:linkage>
        </gmd:CI_OnlineResource>
      </gmd:onlineResource>
    </gmd:CI_Contact>
  </gmd:contactInfo>
  <gmd:role>
    <gmd:CI_RoleCode codeList="https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml#CI_RoleCode" codeListValue="author">author</gmd:CI_RoleCode>
  </gmd:role>
</gmd:CI_ResponsibleParty>
...

Addresses are expressed using the ISO 19115 class CI_ResponsibleParty and its XML element instance, gmd:CI_ResponsibleParty. This is a common structure that is used to encode:

  • Metadata contact
  • Responsible organisation

In the context of GEMINI2 a responsible party set shall include at least the organisation name (encoded using gmd:organisationName), an email address (encoded using gmd:electronicMailAddress) and a role (encoded using gmd:role).

The XML element role takes values from the ISO 19115 codelist CI_RoleCode. Any value in the code list may be chosen.

Additionally, the contact position (encoded using gmd:positionName), the postal address (encoded using a combination of gmd:deliveryPoint, gmd:city, gmd:administrativeArea, gmd:postalCode and gmd:country), telephone number (encoded using gmd:voice) and facsimile number (encoded using gmd:facsimile) may be provided.

2.2.9 Code lists

Where a sub-item takes its value from a code list, which may or may not be expressed in ISO 19115, the source code list catalogue and code list value shall be expressed using the attributes gmd:codeList and gmd:codeListValue respectively.

Figure 13 shows the encoding where a code list is specified in ISO 19115. The value of the codeList attribute should be the URL for the ISO 19115 code list catalogue that is published on the ISO website:

https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml

Plus a hash character acting as a delimiter, and then the identifier of the code list, in this case ‘MD_ScopeCode’, that contains the code list value that is used. This information could be used to validate the code list value and ensure that it is a member of the code list.

The value of the code list value attribute (gmd:codeListValue) shall be a valid entry from the specified code list dictionary.

The element value (i.e. in Figure 13  <gmd:MD_ScopeCode ...>dataset</gmd:MD_ScopeCode>) is human readable text. It can be omitted or given a value different from that of the attribute codeListValue (e.g. Dataset).  Developers of GEMINI aware applications should note that reliance should not be placed on the element value of code list elements but rather on the value of the attribute gmd:codeListValue.

Figure 13 - Code list
<gmd:MD_ScopeCode codeList="https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml#MD_ScopeCode"
  codeListValue="dataset">dataset</gmd:MD_ScopeCode>

Figure 14 shows a fragment of the code list catalogue with the entries of MD_ScopeCode that are relevant to GEMINI2 metadata.

Figure 14 - Fragment of the code list catalogue
<CT_CodelistCatalogue xmlns="http://www.isotc211.org/2005/gmx"
                      xmlns:gco="http://www.isotc211.org/2005/gco"
                      xmlns:gml="http://www.opengis.net/gml/3.2"
                      xmlns:xlink="http://www.w3.org/1999/xlink"
                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  ...
  <!--=== MD_ScopeCode ===-->
  <codelistItem>
    <CodeListDictionary gml:id="MD_ScopeCode">
      <gml:description>class of information to which the referencing entity applies</gml:description>
      <gml:identifier codeSpace="ISOTC211/19115">MD_ScopeCode</gml:identifier>
      ...
      <codeEntry>
        <CodeDefinition gml:id="MD_ScopeCode_dataset">
          <gml:description>information applies to the dataset</gml:description>
          <gml:identifier codeSpace="ISOTC211/19115">dataset</gml:identifier>
        </CodeDefinition>
      </codeEntry>
      <codeEntry>
        <CodeDefinition gml:id="MD_ScopeCode_series">
          <gml:description>information applies to the series</gml:description>
          <gml:identifier codeSpace="ISOTC211/19115">series</gml:identifier>
        </CodeDefinition>
      </codeEntry>
      ...
      <codeEntry>
        <CodeDefinition gml:id="MD_ScopeCode_service">
          <gml:description>information applies to a capability which a service provider entity makes available to a service user entity through a set of interfaces that define a behaviour, such as a use case</gml:description>
          <gml:identifier codeSpace="ISOTC211/19115">service</gml:identifier>
        </CodeDefinition>
      </codeEntry>
      ...
    </CodeListDictionary>
  </codelistItem>
</CT_CodelistCatalogue> 

2.2.10 Null Values

The ISO 19139 XML schemas provide a means for indicating that the contents of an element may be unknown or withheld, through the use of the gco:nilReason attribute. This attribute can be added to any element in the gmd namespace. It can take the following values:

  • inapplicable
  • missing
  • template
  • unknown
  • withheld
  • other:[any text]

Empty XML elements (see Figure 15) are not permitted in ISO 19139 metadata instances. Although this is not checked by the “Table A” schematron rules in use in UK Location, those creating metadata records should avoid creating empty XML elements if at all possible. If an optional element is not required, don’t include it; if a mandatory element is not available use gco:nilReason.

Figure 15 - Examples of empty elements not permitted in GEMINI metadata instances

<gco:CharacterString/>

<gco:CharacterString></gco:CharacterString>

<gmx:Anchor />

<gmx:Anchor></gmx:Anchor>

The following metadata items shall not be nillable:

  • Title
  • Abstract
  • Bounding box (west, east, south and north coordinates)
  • Unique resource identifier
  • Responsible organization
  • Metadata point of contact
  • Topic category
  • Originating controlled vocabulary title
  • File identifier

2.2.11 By Value or By Reference

The content of a metadata instance may be expressed by value or by reference. By value means that the metadata instance carries all the necessary information. By reference means that a metadata instance indicates that content is to be found in an external repository or another place within the same instance. The by reference case is supported by the object reference (gco:ObjectReference) attribute group. This provides two mechanisms for referencing remote resources:

  • XLink, primarily using the xlink:href attribute
  • By UUID using the uuidref attribute

Figure 16 shows the use of the XLink href attribute to specify a vertical CRS by reference to the EPSG Geodetic parameter dataset while Figure 17 shows the same information encoded by value (note however, that in this case the domain of validity (gml:domainOfValidity), vertical coordinate system (gml:verticalCS) and vertical datum (gml:verticalDatum) are themselves encoded by reference).

Encoding information by reference is clearly advantageous in the sense that it is more efficient (in terms of file size but also avoiding data duplication) than by value. However, it presupposes that an XML software application will ‘know’ how to dereference the reference. Dereferencing is the act of obtaining the externally referenced information. It is also important that the referenced information is universally available in a structured machine readable form so that it can be incorporated by value. In the case of the examples below the EPSG web service endpoint can be used to dereference the EPSG URN to return the GML encoded vertical CRS. The GML can be directly incorporated in an XML metadata instance, where the metadata element accepts a GML value (noting that there will be a difference in the GML namespace identifier – EPSG returning GML 3.1.1 while metadata instances shall identify the GML 3.2.1 namespace – in the case of the CRS XML elements of GML there is no difference between these versions of GML).

Typically, by reference shall be used for identifying the vertical CRS of a vertical extent and the implementation of coupled resource (following INSPIRE guidelines) alone. The XLink mechanism shall be used (see Figure 16 for vertical CRS and Figure 18 for coupled resource). Note that in encoding coupled resource by referencing the uuidref attribute may also be used, in addition to XLink. All other metadata items shall be implemented by value.

Figure 16 - Vertical CRS by reference
<gmd:verticalCRS xlink:href="http://www.opengis.net/def/crs/EPSG/0/5701"/>
Figure 17 - Vertical CRS by value
...
<gmd:verticalCRS>
  <gml:VerticalCRS gml:id="epsg-crs-5701">
    <gml:identifier codeSpace="OGP">http://www.opengis.net/def/crs/EPSG/0/5701/</gml:identifier>
    <gml:name>ODN height</gml:name>
    <gml:domainOfValidity xlink:href="http://www.opengis.net/def/crs/EPSG/0/2792/"/>
    <gml:scope>Geodetic and engineering surveying.</gml:scope>
    <gml:verticalCS xlink:href="http://www.opengis.net/def/crs/EPSG/0/6499/"/>
    <gml:verticalDatum xlink:href="http://www.opengis.net/def/crs/EPSG/0/5101/">
  </gml:VerticalCRS>
</gmd:verticalCRS>
... 
Figure 18 - Coupled resource by reference
<srv:operatesOn xlink:title="Digital Geological Map Data of Great Britain - 625k (DiGMapGB-625) 2008"
xlink:href="http://metadata.bgs.ac.uk/geonetwork/srv/en/csw?SERVICE=CSW&REQUEST=GetRecordById
&ID=9df8df52-d788-37a8-e044-0003ba9b0d98&OutputSchema=http://www.isotc211.org/2005/gmd&elementSetName=full#BGS-13480426&" uuidref="9df8df52-d788-37a8-e044-0003ba9b0d98" />

2.2.12 Identifiers

GML XML elements which are used in metadata have an optional gml:id attribute. The value domain of the identifier is referred to as XML name. XML names have certain restrictions. They may contain any alphanumeric character, non-English alphanumeric characters, ideograms and the underscore, hyphen and period. They may not contain any other punctuation characters. The colon is allowed, but its use is reserved for namespaces, so it cannot appear in an identifier. XML names may not include any whitespace including spaces and carriage returns. All names beginning with the letters XML (in uppercase, lowercase or any mixture thereof) are reserved (see [11] pages 18 and 19).

XML names may only start with letters, ideograms and the underscore character. Consequently, care must be taken when using the value of a UUID as the value of an identifier because these can begin with numeric characters.  If using UUIDs as the basis of such an identifier best practice is to prefix the UUIDs with an underscore.

An identifier must be unique within the scope of any XML document (i.e. there shall not be more than one id type attribute with a particular identifier value) that the metadata record might occur in, such as a result set from a CSW query and not just the metadata document itself. 

If an id type attribute contains an illegally formed XML name the result will be a schema validation error.

2.2.13 Free text

In GEMINI2 there are two ways of encoding free text.  The basic element for providing text of unrestricted length with no internal XML structure is gco:CharacterString. This element is appropriate when the text does not refer to a specific external resource or registry.  When the  provided text is a term or code referring to an externally defined explanation or registry value, gmx:Anchor element is recommended over gco:CharacterString. gmx:Anchor contains an additional attribute group enabling linking the provided piece of text with an external describing resource. The most important of these attributes in this context is xlink:href, which contains the actual reference in Uniform Resource Identifier (URI) format.

For example the encoding of an identifier/code value should be done with gmx:Anchor as in Figure 19, rather than gco:CharacterString (Figure 20), when the unique resource identifier is referenceable,

Figure 19 - Non-empty free text, with gmx:Anchor
<gmd:identifier>
  <gmd:MD_Identifier>
    <gmd:code>
      <gmx:Anchor xlink:href="http://data.bgs.ac.uk/id/dataHolding/13480180">
       World Mineral Statistics Dataset
      </gmx:Anchor>
    </gmd:code>
  </gmd:MD_Identifier>
</gmd:identifier>
Figure 20 - Non-empty free text, with gco:CharacterString
<gmd:identifier>
  <gmd:MD_Identifier>
    <gmd:code>
      <gco:CharacterString>
        http://data.bgs.ac.uk/id/dataHolding/13605835
      </gco:CharacterString>
    </gmd:code>
  </gmd:MD_Identifier>
</gmd:identifier>

2.2.14 Limitations, conditions, and licences

GEMINI contains two elements, 25 Limitations on public access and 26 Use constraints. These represent the two INSPIRE elements Limitations on public access and Conditions applying to access and use, and are therefore both encoded with ISO 19115 MD_LegalConstraints elements. INSPIRE requires that they are encoded in separate MD_LegalConstraints elements. This means that a GEMINI metadata record must contain at least two MD_LegalConstraints elements.

INSPIRE requires that both of these elements use MD_RestrictionCode = otherRestrictions. Because GEMINI element 26 is for use constraints, it makes sense for both elements to place this inside a useConstraints element. Having specified otherRestrictions, each shall then use one or more otherConstraints elements to specify the actual constraints.

For Limitations on public access, at least one of the otherConstraints elements shall use gmx:Anchor to indicate the kind of constraint, by reference to the appropriate entry in the INSPIRE registry (http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess). The free text within the anchor can provide human readable detail.

For Use constraints, if there are no conditions, or the conditions are unknown, then use gmx:Anchor to reference the appropriate entry in the INSPIRE registry (http://inspire.ec.europa.eu/metadata-codelist/ConditionsApplyingToAccessAndUse). Similarly, if the conditions are documented in a license, use gmx:Anchor to reference the full license text. The free text within the anchor can provide a human readable summary. If the conditions are not available at a URL, they can be entered as plain text; see FIgure 22b.

Three examples:

Figure 21 describes a commercial product, not available to the public for IPR reasons, and with a web page describing licences

Figure 21 - OS licence
<!-- INSPIRE C.17; GEMINI 25 Limitations on public access --> 
<gmd:resourceConstraints>
 <gmd:MD_LegalConstraints>
  <gmd:accessConstraints>
   <gmd:MD_RestrictionCode
codeList="https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml#MD_RestrictionCode"
 codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
   </gmd:accessConstraints>
  <gmd:otherConstraints>
   <gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/INSPIRE_Directive_Article13_1e"/>
  </gmd:otherConstraints>
 </gmd:MD_LegalConstraints>
</gmd:resourceConstraints>

 <!-- INSPIRE C.18; GEMINI 26 use constraints -->
<gmd:resourceConstraints>
 <gmd:MD_LegalConstraints>
  <gmd:useConstraints>
   <gmd:MD_RestrictionCode
codeList="https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml#MD_RestrictionCode"
 codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
   </gmd:useConstraints>
  <gmd:otherConstraints>
   <gmx:Anchor xlink:href="https://os.uk/business/licences/index.html">Use limitation dependent upon licence</gmx:Anchor>
  </gmd:otherConstraints>
 </gmd:MD_LegalConstraints>
</gmd:resourceConstraints>

Figure 22a describes an open data product, with no limitations on public access, the Open Government Licence referenced, and summarised in plain text.

Figure 22a - INSPIRE no limitations; OGL
<!-- INSPIRE C.17; GEMINI 25 Limitations on public access --> 
<gmd:resourceConstraints>
 <gmd:MD_LegalConstraints>
  <gmd:accessConstraints>
   <gmd:MD_RestrictionCode
codeList="https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml#MD_RestrictionCode"
 codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
   </gmd:accessConstraints>
  <gmd:otherConstraints>
   <gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/noLimitations">no limitations</gmx:Anchor>
  </gmd:otherConstraints>
 </gmd:MD_LegalConstraints>
</gmd:resourceConstraints>

 <!-- INSPIRE C.18; GEMINI 26 use constraints -->
<gmd:resourceConstraints>
 <gmd:MD_LegalConstraints> <!-- change existing example here, was MD_Constraints -->
  <gmd:useConstraints>
   <gmd:MD_RestrictionCode
codeList="https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml#MD_RestrictionCode"
 codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
   </gmd:useConstraints>
  <gmd:otherConstraints>
   <gmx:Anchor xlink:href="http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/">Attribution required</gmx:Anchor>
  </gmd:otherConstraints>
 </gmd:MD_LegalConstraints>
</gmd:resourceConstraints>

Figure 22b describes an open data product, with no limitations on public access, but plain text conditions of use.

Figure 22b - INSPIRE no limitations on access; constraint on use
<!-- INSPIRE C.17; GEMINI 25 Limitations on public access --> 
<gmd:resourceConstraints>
<gmd:MD_LegalConstraints>
<gmd:accessConstraints>
<gmd:MD_RestrictionCode
codeList="https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml#MD_RestrictionCode"
codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
</gmd:accessConstraints>
<gmd:otherConstraints>
<gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/noLimitations">no limitations</gmx:Anchor>
</gmd:otherConstraints>
</gmd:MD_LegalConstraints>
</gmd:resourceConstraints>

<!-- INSPIRE C.18; GEMINI 26 use constraints -->
<gmd:resourceConstraints>
<gmd:MD_LegalConstraints> <!-- change existing example here, was MD_Constraints -->
<gmd:useConstraints>
<gmd:MD_RestrictionCode
codeList="https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml#MD_RestrictionCode"
codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
</gmd:useConstraints>
<gmd:otherConstraints>
<gco:CharacterString>Not to be used for navigation</gco:CharacterString>
</gmd:otherConstraints>
</gmd:MD_LegalConstraints>
</gmd:resourceConstraints>

2.3 Metadata for datasets and dataset series

2.3.1 Data identification

XML elements for encoding metadata for datasets and series of datasets are drawn, primarily, from the gmd and gco namespaces and also the gml and xlink namespaces. Identification information is encoded using the gmd:MD_DataIdentification type (Figure 23).

Metadata instances may include more than one gmd:identificationInfo XML element. The first gmd:identificationInfo XML element in a GEMINI metadata instance for datasets or series shall have as its first and only child XML element gmd:MD_DataIdentification. The ISO 19115 hierarchyLevel element shall be set to “dataset” or “series”. For a series, ISO 19115 hierarchyLevelName element must also be set, to "dataset" or "series" as appropriate.

Figure 23 - Metadata for datasets using the gmd:MD_DataIdentification type 
<gmd:MD_Metadata>
  ...
  <gmd:hierarchyLevel>
    <gmd:MD_ScopeCode codeList="https://schemas.isotc211.org/schemas/19139/resources/gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset">dataset</gmd:MD_ScopeCode>
  </gmd:hierarchyLevel>
  ...
  <gmd:identificationInfo>
    <gmd:MD_DataIdentification>
      ...
    </gmd:MD_DataIdentification>
  </gmd:identificationInfo>
  ...
</gmd:MD_Metadata>

2.3.2 Detailed guidance for each metadata element

2.4 Metadata for services

2.4.1 Service identification

XML elements for encoding metadata for services are drawn from the gmd, gco, gml, xlink and srv namespaces. Identification information is encoded using the srv:SV_ServiceIdentification type (Figure 24).

Metadata may include more than one gmd:identificationInfo XML element. The first gmd:identificationInfo XML element in a GEMINI metadata instance for services shall have as its first child XML element srv:SV_ServiceIdentification. The ISO 19115 hierarchyLevel element shall be set to “service”, ISO 19115 hierarchyLevelName element must also be set, to "service".

Figure 24 - Metadata for services using the srv:SV_ServiceIdentification type
<gmd:MD_Metadata>
  ...
  <gmd:hierarchyLevel>
    <gmd:MD_ScopeCode
      codeList="https://schemas.isotc211.org/schemas/19139/resources/codelist/gmxCodelists.xml#MD_ScopeCode"
      codeListValue="service">service
    </gmd:MD_ScopeCode>
  </gmd:hierarchyLevel>
  <gmd:hierarchyLevelName>
    <gco:CharacterString>service</gco:CharacterString>
  </gmd:hierarchyLevelName>
  ...
  <gmd:identificationInfo>
    <srv:SV_ServiceIdentification>
      ...
    </srv:SV_ServiceIdentification>
  </gmd:identificationInfo>

2.4.2 Service metadata null values

The ISO 19119 class SV_ServiceIdentification includes two mandatory properties that are out of scope of GEMINI2 metadata. These are srv:couplingType and srv:containsOperations. Both shall be implemented with null values with the nil reason being missing (Figure 23).

Figure 25 – Coupling Type and Contains Operations – Null values
<gmd:MD_Metadata>
  ...
  <gmd:identificationInfo>
    <srv:SV_ServiceIdentification>
      ...
      <srv:couplingType gco:nilReason="missing"/>
      <srv:containsOperations gco:nilReason="missing"/>
      ...
    </srv:SV_ServiceIdentification>
  </gmd:identificationInfo>
  ...
</gmd:MD_Metadata>

2.4.3 Detailed guidance for each metadata element

Last technical update: March 2019

Creative Commons Licence
This work is licensed under a Creative Commons Attribution 4.0 International License

Membership Benefits

Convene, connect and collaborate

We provide many networking opportunities for members at our events, seminars and workshops, encouraging debate and forward thinking for the benefit of the whole community.

Promoting the value and benefits of GI

We work hard to ensure that the AGI's voice extends beyond the GI industry, as the considerable pace of technological advancements enables everyone to do more with their data.

Representing the GI community to policy makers

We are continually engaging with the Geospatial Commission's senior leadership team to represent your views and influence policy. We advocate for the investment in skills, shared standards and best practice, as well as better access to data.

Providing a focus for the GI community

The AGI's flagship event, GeoCom, provides a platform for world class speakers to share their vision of where geospatial information professionals can create a step change to deliver economic and societal value.

CPD, training and education

We actively encourage all our members to continue learning by participating in our free CPD scheme and to exchange their geospatial expertise with each other. Corporate members can seek CPD accreditation points for their training courses.

Latest News

thinkWhere Supports GIS Innovation at Scotland’s Rural College

Thursday, 24 September 2020

Stirling, Scotland, 24 September 2020 - thinkWhere has delivered a field-to-desk GIS solution for Scotland’s Rural College (SRUC). 

MGISS Scores Accreditation Hat-trick for Cloud Software and Workplace Wellbeing

Tuesday, 22 September 2020

Liverpool, UK, 22 September 2020 - Mobile GIS Services (MGISS) has been awarded a place on the UK Government’s procurement platform G-Cloud.

AGI Council 2021 Nominations

Sunday, 20 September 2020

Nominations for AGI Council 2021 will be open from 25 September - 30 October 2020.

1Spatial welcomes the Department for Digital, Culture, Media & Sport’s (DCMS) National Data Strategy

Thursday, 17 September 2020

DCMS published the National Data Strategy. 1Spatial welcomes this strategy, at a time when there are rapidly increasing demands and expectations for data driven decision making, benefitting our economy, environment and society.

Connect

Lancaster Court
8 Barnes Wallis Road
Fareham
Hampshire PO15 5TU

Tel: +44 (0)1489 668 340
Email: info@agi.org.uk