Published

OGC Policy

•
OGC Name Type Specification - definitions - part 1 – basic name
Gobe Hobona Editor Simon Cox Editor
Submission Date: 2018-07-05 Approval Date: 2022-06-09 Publication Date: 2022-06-24 External identifier of this OGC® document: http://www.opengis.net/doc/POL-NTS/DEF-1/1.3 Internal identifier of this OGC® document: 09-048r6
Version: 1.3
OGC Policy

Published

Notice

This document is not an OGC Standard. This document is an OGC Policy and is therefore not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard.

Further, an OGC Policy should not be referenced as required or mandatory technology in procurements.

Document number:09-048r6
Document type:OGC Policy
Document subtype:
Document stage:Published
Document language:English

Copyright notice

Copyright © 2022 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.ogc.org/legal/

Note

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.


License Agreement

Permission is hereby granted by the Open Geospatial Consortium, (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.



I.  Abstract

The mission of the OGC Naming Authority (OGC-NA) is to provide the means through which OGC resources such as OGC documents, namespaces and ontologies can be controlled and managed such that they can provide clear and well-defined names and definitions. In the terminology defined in ISO 19135, OGC-NA is the Control Body for the register of OGC Names. This document specifies a rule for constructing OGC names that may be used for identifying definitions, as well as rules for formally representing the meanings of the definitions.

II.  Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, policy, naming authority, definitions


III.  Preface

This document specifies a rule for constructing OGC names that may be used for identifying definitions.

IV.  Security considerations

No security considerations have been made for this document.

V.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

VI.  Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name Affiliation
Gobe Hobona OGC
Simon Cox CSIRO

OGC Name Type Specification - definitions - part 1 – basic name

1.  Scope

An OGC name may be provided for a definition of a type of object broadly classified as a “concept” or system parameter, including:

The precise scope of definitions that may be identified with OGC Names is provided by the set of items in the register at http://www.opengis.net/register/ogc-na/def-type

Note that “Definitions” may be contrasted with “instances”, which shall use names constructed following rules provided in other OGC Name Type Specifications.

2.  Conformance

This policy defines part 1 of the OGC name-type specification for definitions.

Conformance with this policy shall be checked using the naming rule and naming assignment policy defined in this document.

3.  Terms definitions and abbreviated terms

3.1.  Terms and definitions

3.1.1.  Concept

unit of knowledge created by a unique combination of characteristics (source: ISO 1087‑1:2000)

3.1.2.  control body

group of technical experts that makes decisions regarding the content of a register (source: ISO 19135)

3.1.3.  register

set of files containing identifiers assigned to items with descriptions of the associated items (source: ISO 19135)

4.  Conventions

This document uses the normative terms (SHALL, SHOULD, etc) defined in Subclause 5.3 of [OGC 06-121r3], which is based on the ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards. In particular, the word ‘shall’ (not ‘must’) is the verb form used to indicate a requirement to be strictly followed to comply with this specification.

Name production rules in this document are expressed using ABNF (IETF RFC 5324).

5.  Naming Rule

This section describes the naming rule.

5.1.  OGC name schemes

Two URI schemes IETF RFC 3986 are defined by OGC to provide persistent names for resources of interest in geographic information infrastructures. The generic syntax for OGC names is described in OGC Naming Authority – Procedures.

The generic syntax for OGC http URIs is

  URI = "http://www.opengis.net/" OGCResource "/" ResourceSpecificPath

The generic syntax for OGC URNs is IETF RFC 5165

  URN = "urn:ogc:" OGCResource ":" ResourceSpecificString

The following ABNF adapted from IETF RFC 3986 provides some basic definitions required in the rest of this document.

  segment       = *pchar
  segment-nc    = *pchar-nc
  segment-nz    = 1*pchar
  segment-nz-nc = 1*pchar-nc
  pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
  pchar-nc      = unreserved / pct-encoded / sub-delims / "@"
  pct-encoded   = "%" HEXDIG HEXDIG
  unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
  reserved      = gen-delims / sub-delims
  gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
  sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="

5.2.  Production rule for definition URIs

The basic form for an OGC name that identifies a definition shall be produced using the following rule:

  OGCResource   = "def"
  ResourceSpecificPath = definition-type "/" authority "/" version "/" code
  ResourceSpecificString = definition-type ":" authority ":" versionURN ":" codeURN
  definition-type = segment-nz-nc ; a token from the register of OGC definition types1
  authority     = segment-nz-nc ; a token from the register of OGC authorities2
  version       = segment-nz-nc / "0" ; use 0 for un-versioned names
  code          = segment-nz-nc *( "/" segment-nz-nc )
  versionURN    = segment-nc ; this may be a zero-length string
  codeURN       = segment-nz-nc *( ":" segment-nz-nc )

“version” or “versionURN” is an optional field. For un-versioned definitions:

  • within the http URI form the version field shall be “0”

  • within the URN form versionURN shall be a zero-length string—so an un-versioned definition can be detected by a pair of colons ”::”.

The actual code may be composed of a sequence of fields delimited by “/” in the http URI form, or ”:” in the URN form.

Note that the register of definition types (http://www.opengis.net/register/ogc-na/def-type) was previously presented as Table 2 in the OGC Best Practice Definition identifier URNs in OGC namespace OGC 07-092r1.

Note that the register of authorities (http://www.opengis.net/register/ogc-na/authority) was previously presented as Table 1 in the OGC Best Practice Definition identifier URNs in OGC namespace OGC 07-092r1

5.3.  Compact URIs

Compact URIs (CURIEs) are an abbreviation for strings that are intended to represent URIs. Their purpose is to support the definition of scoped names that map to URIs.

The URI of any definition registered in OGC-NA controlled registers may be represented in shortened form through use of CURIEs.

The skos:notation property shall be used for specifying the form of the registered CURIE.

The prov:wasDerivedFrom property shall be used for specifying the URI to which the registered CURIE applies.

An extract from an example registration is shown below in Turtle.

<http://www.opengis.net/def/curie/ogc/1.0/crs/EPSG> <http://www.w3.org/2004/02/skos/core#notation> "EPSG"^^<http://www.w3.org/2001/XMLSchema#string>.

<http://www.opengis.net/def/curie/ogc/1.0/crs/EPSG> <http://www.w3.org/ns/prov#wasDerivedFrom> <http://www.opengis.net/def/crs/EPSG/0/>.

Figure 1

The extract above makes it possible to use [EPSG:4326] in place of http://www.opengis.net/def/crs/EPSG/0/4326

5.3.1.  Register of CURIEs

The OGC-NA maintains a register of CURIEs at http://www.opengis.net/def/curie. The register shall be used as a look-up for CURIEs commonly used in OGC Standards.

CURIEs recorded in the register shall be treated as case sensitive.

5.3.2.  Use of Safe CURIEs

OGC Standards should only allow safe CURIEs, unless support for other forms of CURIEs is inherited from another standard (e.g. GeoSPARQL inherits its support of CURIEs from SPARQL). Safe CURIEs are specified in square brackets. For example, the safe CURIE [EPSG:3857] may be used in an API request such as : https://example.org/foo/collections/bar/items?crs=[EPSG:3857]

5.3.3.  Applying CURIEs to Coordinate Reference Systems

CURIEs representing a shortened form of the URI of a registered Coordinate Reference System (CRS) may be used as an alternative to the full URI by following the syntax below:

{authority}:{identifier} == http://www.opengis.net/def/crs/{authority}/0/{identifier}

For example, EPSG:4326 may be used to represent http://www.opengis.net/def/crs/EPSG/0/4326

When a CURIE is used to represent a CRS, the following shall apply:

  1. The version segment of the URI is assumed to be equal to 0

  2. The definition-type segment shall be assumed to be equal to crs.

  3. The definition segment shall be assumed to be equal to def.

Therefore “EPSG” as a prefix shall expand to http://www.opengis.net/def/crs/EPSG/0/.

6.  Name Assignment and Resolution

This section describes the name assignment policy.

6.1.  Definition types

The register of definition types http://www.opengis.net/register/ogc-na/def-type is controlled by OGC-NA. Changes to this register (additions, deletions, and supersession) shall be initiated by a submission to the OGC Naming Authority names@ogc.org.

6.2.  Authorities

The register of authorities http://www.opengis.net/register/ogc-na/authority is controlled by OGC-NA. Changes to this register (additions, deletions, and supersession) shall be initiated by a submission to the OGC Naming Authority names@ogc.org.

6.3.  Names

The register of names http://www.opengis.net/def/ is controlled by OGC-NA. Changes to this register (addition, deletion, and supersession) shall be initiated by a submission to the OGC Naming Authority names@ogc.org.

6.4.  Names for EPSG definitions

http URI form:

http://www.opengis.net/def/definitionType/EPSG/0/code

URN form:

urn:ogc:def:definitionType:EPSG::code

In this case, the ‘authority’ part of the URI is ‘EPSG’. The ‘code’ part of the URI is the EPSG ‘code’ unique identifier of the referenced definition. Alternately, the ‘code’ part of the URI can be the EPSG ‘name’ unique identifier. In this case, omission of the version number is recommended, as this is not required to identify a referenced record in the EPSG dataset and may even lead to confusion if a version number is provided.

The policy of the Survey and Positioning Committee of the International Association of Oil and Gas Producers (IOGP) is to not delete any entities. However, if a record is found to be incorrect, that record is deprecated and replaced. When this is done, the deprecation field of the deprecated record is changed from “false” to “true”. (In some implementations, “false” may be “0” or “no”, and “true” may be “1” or “yes”). Deprecated records are also termed ‘invalid records’. When retrieving any geodetic parameters from the EPSG dataset a user therefore needs to verify whether the record(s) is / are valid or invalid. The user then has two options: (1) follow the links provided and use the valid replacing record(s), a course typically followed when spatially referencing a new dataset, or (2) retrieve the invalid, deprecated record(s) in order to undo the effects of this error in an existing spatial dataset that had been spatially referenced using the incorrect records. Note that spatial referencing using (an) invalid EPSG entities will only generate errors if the data is subsequently subjected to coordinate conversions and/or transformations.

Example 1 The http URI value for EPSG CRS 3163 is:

http://www.opengis.net/def/crs/EPSG/0/3163

Example 2 The http URI value for the “WGS 84 longitude-latitude” CRS specified in Subclause B.3 of WMS 1.3 (previously referenced as CRS:84) is:

http://www.opengis.net/def/crs/OGC/1.3/CRS84

Example 3 The URN value for EPSG CRS 3163 is:

urn:ogc:def:crs:EPSG::3163

Example 4 The URN value for the “WGS 84 longitude-latitude” CRS specified in Subclause B.3 of WMS 1.3 (previously referenced as “CRS:84”) is:

urn:ogc:def:crs:OGC:1.3:CRS84

6.5.  Description

Each definition shall be described using the Simple Knowledge Organization System (SKOS) vocabulary of the World Wide Web (W3C) consortium. Other vocabularies may also be used in addition to SKOS.

The following predicates are mandatory for resources:

  • skos:prefLabel for providing a human-readable version of a resource’s name

  • dcterms:created for stating the date the resource was created in the register

  • dcterms:modified for stating the date the resource was modified in the register (mandatory if the resource has been modified)

  • policy:status for indicating whether the resource is valid, retired, superseded, or under consideration

  • skos:definition for providing a human-readable description of the resource

  • rdfs:label for providing a human-readable version of a resource’s name (used for compatibility with non-SKOS systems)

An example of a definition described in SKOS is shown below.

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix policy: <http://www.opengis.net/def/metamodel/ogc-na/> .
@prefix status: <http://www.opengis.net/def/status/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://www.opengis.net/def/serviceType/ogc/wcs/2.0>
  rdf:type skos:Concept ;
  dcterms:created   "2018-03-13"^^xsd:date ;
  dcterms:modified  "2018-04-16"^^xsd:date ;
  policy:status     status:valid ;
  skos:broader <http://www.opengis.net/def/serviceType/ogc/wcs>;
  rdfs:label "OGC Web Coverage Service 2.0"^^xsd:string ;
  rdfs:seeAlso <http://www.opengis.net/spec/wcs/2.0> ;
  skos:prefLabel "OGC Web Coverage Service 2.0"@en ;
  skos:definition "A Web Coverage Service (WCS) offers multi-dimensional coverage data for access over the Internet" .

6.6.  Resolution of the Same Definition to Different Encodings

The definition of a resource may be accessed in any number of encodings that are supported by a resolution service or resolver. A non-exhaustive list of example encodings relevant to different resources is below:

  • Geography Markup Language (GML): Supports the encoding on features, coordinate reference systems, and codelists.

  • Well Known Text (WKT): Supports the encoding on features, and coordinate reference systems.

  • Simple Knowledge Organization System (SKOS) in Resource Description Framework (RDF): Supports the encoding concepts, glossaries, and thesauri

A resolution service and a client application shall negotiate the encoding format to use through the content negotiation process defined in IETF RFC 7231.

6.7.  Assigning and Handling Name Aliases

Where the URI of a named resource has an alias, the OGC-NA shall entail copies of all the properties for both forms of URI, and create inverse sameAs relationships. For example, upon registering the resource example-B as an alias of example-A,

  • all of the properties of example-A shall be copied to example-B

  • the statement that example-B is sameAs example-A shall be declared

  • the statement that example-A is sameAs example-B shall be declared

In code, this is illustrated below.

<example-A> rdf:type skos:Concept.

<example-B> rdf:type skos:Concept.

<example-A> owl:sameAs <example-B> .

6.8.  Supporting Services

In some cases, additional services may be provided by OGC Staff to facilitate the use of names or URIs that are registered with the OGC-NA. Such supporting services may be provided through a path underneath http://www.opengis.net/def or its sub-paths. The interface definition and syntax for communicating with the supporting services is out-of-scope of the responsibilities of the OGC-NA.

Examples of such supporting services include:

  • AUTO2 namespace for CRS: The “AUTO2” namespace is used for “automatic” coordinate reference systems; that is, for a class of CRSs that include a user-selected centre of projection. See section 6.7.3.4 of the Web Map Service (WMS) version 1.3.0 standard (OGC 06-042). Note that although the namespace is with the OGC-NA here, the syntax is instead specified in the WMS 1.3.0 standard.

  • AUTO namespace for CRS: The AUTO namespace is used for “automatic” projections; that is, for a class of projections that include an arbitrary center of projection. See section 6.5.5.2 of the WMS 1.1.1 standard (OGC 01-068r3). Note that although the namespace is with the OGC-NA here, the syntax is instead specified in the WMS 1.1.1 standard. The supporting service is provided at http://www.opengis.net/def/crs/AUTO

  • Compound CRS: See clause 6.4 of the OGC Coverage Implementation Schema with Corrigendum Standard version 1.1.1 (OGC 09-146r8). Note that although the service is provided through the OGC Definitions Server, the syntax and interface are specified in the CIS 1.1.1 standard. The supporting service is provided at http://www.opengis.net/def/crs-compound


Annex A
(informative)
Background

A.1.  Introduction

This annex includes useful information from the previous document OGC 07-092r3

A.2.  URNs for Coordinate Reference Systems

One frequent use of URNs is referencing the CRS for an OGC Web Service input or output; another use is referencing the CRS for a feature geometry or a bounding box. These URNs are used to identify the referenced CRS, not to transfer a definition of that CRS. Most of this material is also applicable to referencing CRS components and Coordinate Operations and their components, often referred to as objects.

NOTE 1: Subclause D.14 of [OGC 06-121r3] summarizes many of the requirements considered when specifying how to reference CRSs.

Document [OGC 06-121r3] specifies that each specific OWS shall always reference a CRS by using an XML attribute or element with the type anyURI. Such an anyURI value can be used to reference a CRS whether the definition of that CRS is included in the same data transfer, is NOT included in the same data transfer, cannot be electronically accessed, or can be electronically accessed.

NOTE 2: In XML Schemas, the anyURI data type is the standard way to briefly reference (or cite) a value specified elsewhere. XML attributes with the type anyURI include the GML defined attributes named gml:srsName, gml:uom, xlink:href, and gml:codeSpace.

When using an XML attribute or element with the type anyURI to reference a CRS, CRS-related, or other object, that URI shall have a value which uses one of two alternative URI formats:

a) Universal Resource Locator (URL), with standard form. The URL format should be used whenever the referenced definition is known to be electronically available using this standard URL.

b) Universal Resource Name (URN), with a specified form. The URN format shall be used whenever the referenced definition is not, or might not be, available using a URL. This URN shall reference data that is specified by some ‘authority’ and is ‘well-known’ to both client and server software, including multiple clients and multiple servers.

NOTE 3: Two widely-used forms of URI are URL and URN. We are specifying using URNs as the way of citing CRS-related definitions that are “well-known” but are not adequately electronically available using a URL.

Subclause 10.3.2 of the OWS Common specification [OGC 06-121r3] specifies when and how to use URLs to reference a CRS or CRS-related object. Use of URNs is expected to be more common than use of URLs, and specific OWS Implementation Specifications are expected to use many standard URN values.

A.3.  URNs and URLs

URNs [IETF RFC 2141] are a kind of URI [IETF RFC 2396], and may be used as the value of references where a URI is required. This is often the case in GML-based encodings (e.g., the standard XML attributes xlink:href, xlink:role, xlink:arcrole, srsName, uom, codeSpace) and in OGC Web Services (OWS) operation requests and responses.

A URN serves as a persistent identifier of a resource or concept. A detailed description of the resource may also be available online, with a resource locator (URL) providing an access point. In general, there is no direct mapping or algorithm to obtain a URL for the resource designated by a URN. URNs are intended to be more persistent than URLs, so that they remain valid even if a resource description is relocated. However, a resolution service or resolver is expected to provide a URL corresponding to a URN.

A.4.  URN and schema component designators

In a few places in OWS interfaces, an identifier for an XML component is required. In these cases, it is important that the identifier reference the actual schema definition, which may then be used as the template for an OWS request or response.

A number of options are available for identification of schema components. The W3C XML Schema recommendation provides QName (qualified name – see XML Schema Part 2, clause 3.2.18). A QName has the lexical form ns:name where ‘ns’ is an XML namespace prefix for which a namespace declaration is in scope. The QName thus corresponds with an identifier tuple {namespace, local name} where ‘namespace’ is the fully scoped identifier for the XML namespace. In contrast, a URN identifier is complete, and does not depend on context for resolution of the namespace prefix.

NOTE  The W3C XML activity is currently considering a more complete scheme for identification of schema components, documented in the working draft XML Schema: Component Designators http://www.w3.org/TR/xmlschema-ref/.

In OWS interfaces, XML components are generally identified using a QName.

While there is some overlap of the meaning of schema component designators with the OGC URN scheme used for dataTypes and featureTypes, it should be understood that a URN identifies the concept, and not just its XML and XML Schema implementation. Of course, the concepts denoted by identifiers from the featureType branch generally have XML Schema implementations, so direct mappings are implied. Note that the mapping may be one-to-many, for example to manage versioning of the XML schema implementation independent of versioning of the concept.


Annex B
(informative)
Revision History

Table B.1

Date Release Editor Primary clauses modified Description
2008-12-04 0.1 Simon Cox N/A Initial draft document
2008-12-11 0.1 Arliss Whiteside Cover, i, ii, iii, 2, 3, 5, A Corrected format, inserted comments, and extended
2009-04-01 0.1 Simon Cox all Minor tweaks and corrections for consistency with the other OGC-NA documents.
2009-05-15 0.2 David Burggraf all Moved all references to parameterized and compound name form of URN definitions with the intention of specifying these forms in the separate documents OGC 09-054 and OGC 09-055, respectively.
2009-05-21 0.2 Simon Cox 2, 3 Additional normative references; Replace EBNF with ABNF
2010-01-31 1.1.0 Simon Cox all ABNF revised to match RFC 3986; http URI syntax made explicit
2010-02-28 1.1.1 Simon Cox 3.2 Specific token “0” to be used for un-versioned http URIs.
2010-03-31 1.1.2 Simon Cox 3.2 Amend ABNF to allow an unlimited set of fields separated by either : or / .
2018-05-16 1.2 Gobe Hobona all Conversion to asciidoctor asciidoc. Updated URL of def-type list. Added the Description section and SKOS example.
2021-06-25 1.3 Gobe Hobona 5.3 Added clause on Shortened Names of CRS’s. Fixes Issue 92.
2022-02-16 1.3 Gobe Hobona 5.2 Changed statement about version number to “version” or “versionURN” is an optional field. Fixes Issue 143.
2022-02-17 1.3 Gobe Hobona 6.7 Added clause on Assigning and Handling Name Aliases. Fixes Issue 116.
2022-02-18 1.3 Gobe Hobona 6.8 Added clause on supporting services. Fixes Issue 93.
2022-02-16 1.3 Gobe Hobona all Conversion to metanorma asciidoc.

Bibliography

[1]  OGC Definitions Server, Available at http://www.opengis.net/def.

[2]  R. Moats: RFC 2141, URN Syntax. Internet Engineering Task Force, Fremont, CA (1997). https://www.rfc-editor.org/info/rfc2141

[3]  R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee: RFC 2616, Hypertext Transfer Protocol — HTTP/1.1. Internet Engineering Task Force, Fremont, CA (1999). https://www.rfc-editor.org/info/rfc2616

[4]  T. Berners-Lee, R. Fielding, L. Masinter: RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. Internet Engineering Task Force, Fremont, CA (2005). https://www.rfc-editor.org/info/rfc3986

[5]  T. Hansen, T. Hardie, L. Masinter: RFC 4395, Guidelines and Registration Procedures for New URI Schemes. Internet Engineering Task Force, Fremont, CA (2006). https://www.rfc-editor.org/info/rfc4395

[6]  J. Goodwin, H. Apel: RFC 5141, A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO). Internet Engineering Task Force, Fremont, CA (2008). https://www.rfc-editor.org/info/rfc5141

[7]  C. Reed: RFC 5165, A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC). Internet Engineering Task Force, Fremont, CA (2008). https://www.rfc-editor.org/info/rfc5165

[8]  P. Overell: RFC 5234, Augmented BNF for Syntax Specifications: ABNF. Internet Engineering Task Force, Fremont, CA (2008). https://www.rfc-editor.org/info/rfc5234

[9]  ISO: ISO 1087-1:2000, Terminology work — Vocabulary — Part 1: Theory and application. International Organization for Standardization, Geneva (2000). https://www.iso.org/standard/20057.html

[10]  OGC 05-020r25, Technical Committee Policies and Procedures, http://docs.ogc.org/pol/05-020r25/05-020r25.html (2017)

[11]  OGC 09-046r5, OGC Naming Authority – Procedures, https://docs.ogc.org/pol/09-046r6.html (2021)

[12]  W3C: SKOS Simple Knowledge Organization System, https://www.w3.org/TR/skos-reference (2009)

[13]  W3C: CURIE Syntax 1.0, https://www.w3.org/TR/curie (2010)