Open Geospatial Consortium

Submission Date: 2018-05-17

Approval Date:   2018-09-05

Publication Date:   2019-10-31

External identifier of this OGC® document: http://www.opengis.net/doc/POL/OGC-NA/1.2

Internal reference number of this OGC® document:    09-046r5

Version: 1.2

Category: OGC® Policy

Editor:   Simon Cox, Gobe Hobona

OGC Naming Authority - Procedures

Copyright notice

Copyright © 2019 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning

This document defines an OGC Policy. It is subject to change without notice. This document is an official position of the OGC membership on this particular topic.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:    OGC® Policy

Document subtype:    Name Type Spec

Document stage:    Approved

Document language:  English

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.

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 describes the framework of documents, registers and other resources required for OGC-NA to execute that role.

ii. Keywords

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

ogcdoc, OGC document, policy, naming authority, procedures

iii. Preface

This document describes the procedures used by the OGC Naming Authority for the assignment and registration of OGC names.

iv. Submitting organizations

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

Organization name(s)

  • Commonwealth Scientific and Industrial Research Organisation (CSIRO)

  • Open Geospatial Consortium

v. Submitters

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

Table 1. Contacts
Name Affiliation

Gobe Hobona

OGC

Simon Cox

CSIRO

1. Scope

The OGC Naming Authority (OGC-NA) controls the assignment of OGC Names to resources of interest in geographic information infrastructures. In the terminology defined in ISO 19135, OGC-NA is the Control Body for the register of OGC Names. This document describes the framework of documents, registers and other resources required for OGC-NA to execute that role.

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

2. Conformance

This policy describes the procedures to be taken by the OGC Naming Authority.

3. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

Cool URIs for the Semantic Web, W3C Interest Group Note, http://www.w3.org/TR/cooluris/ (2008)

IETF: RFC 2141 URN Syntax, http://tools.ietf.org/html/rfc2141 (1997)

IETF: RFC 2616 Hypertext Transfer Protocol — HTTP/1.1 (1999) http://tools.ietf.org/html/rfc2616

IETF: RFC 3986 Uniform Resource Identifier (URI): Generic Syntax, http://tools.ietf.org/html/rfc3986 (2005)

IETF: RFC 4395 Guidelines and Registration Procedures for New URI Schemes, http://tools.ietf.org/html/rfc4395 (2006)

IETF: RFC 5141 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO), http://tools.ietf.org/html/rfc5141 (2008)

IETF: RFC 5165 A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC), http://tools.ietf.org/html/rfc5165 (2008)

IETF: RFC 5234 Augmented BNF for Syntax Specifications: ABNF, http://tools.ietf.org/html/rfc5234 (2008)

ISO: ISO 19135:2015 Geographic information—Procedures for item registration (2015)

4. Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], 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 conform to this standard.

For the purposes of this document, the following additional terms and definitions apply.

4.1. control body

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

4.2. register

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

4.3. registration

assignment of a permanent, unique, and unambiguous identifier to an item (source: ISO 19135)

5. 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).

6. Naming rule

6.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. An http Uniform Resource Identifier(URI) scheme [IETF RFC 4395] provides identifiers which may be resolved to resource representations using the standard web infrastructure, in particular the Domain Name System (DNS) system. A Uniform Resource Name (URN) scheme [IETF RFC 2141] provides equivalent identifiers which do not imply location or a specific resolution mechanism.

Http URI and URN schemes use different delimiters for the elements within the identifier ('/' and ':' respectively). Rules for the names that allow either form to be composed from the same elements requires that the elements use a reduced character set which excludes both of these delimiters.

Note

The URN scheme is essentially identical to that described in version 1 of this policy. The ABNF description below has been revised for consistency with [IETF RFC 3986] and to accommodate the URN/URI consideration above. Although the rule here excludes some identifier forms that may have previously been valid, in practice no assignments were made using the characters now excluded so there is no backward compatibility problem.

The following ABNF adapted from [IETF RFC 3986] provides some basic definitions required in the rest of this document, and in other OGC-NA policy documents:

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    = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="

6.2. Use of name structure

The naming schemes defined by OGC-NA in this and related documents have a regular structure. The structure is primarily to provide the name provider (OGC) with a mechanism to govern the names and ensure uniqueness. While name users (clients) might attempt to infer other names based on the structure, the OGC-NA registers are the normative source of OGC names.

6.3. http URI scheme

The generic syntax for OGC http URIs is

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

6.4. URN scheme

The generic syntax for OGC URNs is [IETF RFC 5165]

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

6.5. Resource type and Name Type Specification

OGCResource is a token that indicates the resource type, taken from the register http://www.opengis.net/register/ogc-na/type.

The special resource types "Resource type", "OGC-NA register" and "Name authority" are defined in this document. Each other resource type is defined in an OGC-NA policy document known as a "Name Type Specification" (NTS).

An OGC name for a resource type shall be produced using the following rule:

OGCResource   = "type"
ResourceSpecificPath = "ogc-na" "/" type
ResourceSpecificString = "OGC-NA" ":" type
type          = segment-nz-nc
                ; a token from the register of OGC resource types

Note that the type register is available from http://www.opengis.net/register/ogc-na/type.

EXAMPLE 2: urn:ogc:type:OGC-NA:def

Changes to the register of resource types (addition, deletion, supercession) shall be by submission of a proposed NTS to the OGC Naming Authority names@opengeospatial.org.

An NTS shall contain the following:

  1. A description of a class of resources which may be designated with OGC Names,

  2. The token to be used as the value of OGCResource

  3. A description of the structure of the ResourceSpecificPath and ResourceSpecificString for this resource type. NOTE: If the ResourceSpecifcPath and ResourceSpecificString refer to items from other registers, details of these must be provided in the NTS. These registers may be controlled by OGC or the OGC-NA, or may be controlled by an external authority.

  4. Details of any type-specific policies for assignment of OGC Names NOTE: This provides the information required for OGC-NA to assess requests for registration of names for this resource type

6.6. OGC-NA Register

An OGC-NA register is a set of items required for the assignment and management of OGC names. An OGC URN for an OGC-NA register shall be produced using the following rule:

OGCResource   = "register"
ResourceSpecificPath = "ogc-na"  "/" register
ResourceSpecificString = "OGC-NA"  ":" register
register      = segment-nz-nc

EXAMPLE 1: http://www.opengis.net/register/ogc-na/def-type EXAMPLE 2: urn:ogc:register:OGC-NA:def-type OGC-NA registers are created from time to time by OGC-NA for the purpose of managing OGC Name assignment.

6.7. Name authority

A Name Authority is an organization, specification document or service that is authorized by OGC-NA to provide or describe resources of designated resource types or sub-types. The set of Name authorities is provided by the register at http://www.opengis.net/register/ogc-na/authority. An OGC URN for a Name authority shall be produced using the following rule:

OGCResource   = "auth"
ResourceSpecificPath = "ogc-na" "/" authority
ResourceSpecificString = "OGC-NA" ":" authority
authority     = segment-nz-nc
                ; a token from the register of OGC Authorities

Note that the authority register is available at http://www.opengis.net/register/ogc-na/authority/

EXAMPLE 1: http://www.opengis.net/auth/ogc-na/EPSG EXAMPLE 2: urn:ogc:auth:OGC-NA:EPSG

Changes to this register (additions, deletions, supercession) shall be by submission of a Name Authority Proposal to the OGC Naming Authority names@opengeospatial.org.

A Name Authority Proposal shall contain the following:

  1. A description of, or locator for, the Name Authority

  2. The token to be used to indicate this authority where required in an OGC Name

  3. The resource type(s) (including sub-types where appropriate) that this authority is responsible for

  4. Details of any authority-specific policies for name assignment (e.g. rules for name element variables)

7. Name registration

7.1. OGC name categories

An OGC Name may fall into one of the following categories:

1. A category A name designates a discrete resource available from a service, such as a repository. These shall be registered as discrete items in the OGC name register:

EXAMPLE 2: urn:ogc:doc:AS:Topic6

2. A category X name is constructed as required, according to a rule or algorithm, and may or may not be associated with a discrete accessible resource. These shall be registered as a class, with a description of (or reference to) the rule or algorithm for names of this class:

EXAMPLE: urn:ogc:def:uom:SI::m%2Fs

7.2. Submission process

Name registration is initiated by submission of a proposal to the OGC Naming Authority names@opengeospatial.org.

A name registration submission shall contain the following information:

Category A name:

  • the identity of the person or organization requesting the name assignment

  • the resource type selected from the register at http://www.opengis.net/register/ogc-na/type.

  • the OGC Name requested

  • one of:

    • the locator for the resource

    • a representation of the resource that may be hosted by OGC

NOTE: The last option may be the case for 'def' names. The name must conform to the rules for names of that type, which may require that items are present in dependency registers used in the name production rule for that type.

EXAMPLE 2: urn:ogc:doc:IS:WMS:1.3.0 → http://portal.opengeospatial.org/files/?artifact_id=4756

Category X names: the identity of the person or organization requesting the name assignment

  • the resource type selected from the register at http://www.opengis.net/register/ogc-na/type.

  • a template for the set of OGC Names requested, with a variable for each element to be populated according to a rule or algorithm

  • the rule or algorithm for populating each variable in the template, including a reference to any dependency resource

  • one of: (preferred) a locator for a service that can provide a description of each resource in this set

    • one of:

      • locator for a definition of the set of resources

      • representation of the definition of the set of resources

The name must conform to the rules for names of that type, which may require that items are present in dependency registers used in the name production rule for that type.

EXAMPLE 4: urn:ogc:def:uom:UCUM::m%2Fs → http://unitsofmeasure.org/ucum.html

Name registration will always involve the addition of items to one or more OGC-NA registers. A name assignment request shall attempt to identify all the register changes that are required, and shall ensure that the information required for each register conforms to the requirements for that register, and shall verify that an OGC name for this resource has not already been allocated.

7.3. Processing of name assignment requests

The registration process generally follows the discipline described in ISO 19135. Items are inserted into the relevant OGC-NA Registers on submission, with the status "invalid". If a registration request is accepted the item status is set to "valid". Items may subsequently be "superseded" (typically if the locator is changed) and a pointer to its successor recorded, or "retired" (if the resource is no longer available). An item that supersedes an earlier item shall have a pointer to its predecessor.

An illustration of the approval process is shown in Figure 1.

img approval process
Figure 1. Illustration of the approval process

A proposal management record shall be maintained with status flags: proposed | valid | invalid | superseded | retired. Each flag shall be linked to its date.

As a general principle, the OGC-NA will take a "light touch" approach to acceptance of name registration proposals, and it is expected that most proposals will be accepted. The principal grounds for rejection of a name registration will be:

  1. the resource cannot be obtained using the locator provided

  2. the resource is not of the type indicated

  3. the resource already has an OGC name

  4. the name is not consistent with patterns in use for similar resources The OGC-NA will process requests in a timely manner.

Note
Most discussion and decisions will be made using the issue tracker at https://github.com/opengeospatial/NamingAuthority/issues.

8. OGC URN Resolver

RFC 5165 indicates that a resolver will be provided at http://urn.opengis.net/ . All OGC URN assignments whose status is "valid" shall be visible through the resolver.

There are two alternative rules for making an http URI (URL) from the name in order to request the resource:

3. Create an equivalent http URI as follows:

  1. replace the initial "ogc:urn:" with "http://www.opengis.net/"

  2. replace any occurrence of "::" with "/0/"

  3. replace all other occurrences of ":" with "/".

e.g. urn:ogc:doc:DP:WaterML:1.0 → http://www.opengis.net/doc/DP/WaterML/1.0

4. Use the URN as a parameter to a resolver request: e.g. http://urn.opengis.net?id=urn:ogc:doc:DP:WaterML:1.0

NOTE: the first approach is similar to the rule given in clause 2.8 of the ISO URN NID specification (IETF RFC 5141).

NOTE: the first approach should be consistent with the http URI name variants described in this document and in OGC Name Type Specifications.

An http GET request with either of these URLs should result in a locator for the named resource with http response 307 or 303 [IETF RFC 2616]. 303 shall indicate a 'non-information resource' [Cool URIs for the Semantic Web], and 307 otherwise.

9. Historical note on URNs and URLs (informative)

URNs have been used for some years by OGC for the persistent identification of resources governed by OGC, and also for some resources governed externally for which there were not persistent URIs available (especially EPSG definitions).

At the time that OGC started using URNs, it appeared to be a good option for persistent identification, avoiding some undesirable effects and expectations around URLs. In particular, URN NID registrations (governed by IETF through IANA) are forever, while http domain registration is only as long as the owner remembers, and furthermore http server maintenance is a skilled job. There was also a general principle at stake: identification and location are different functions.

In the meantime, however, the rest of the web world has moved on. The current version of the URL story is that

  • a URL is a 'http URI' (often, though incorrectly, abbreviated to just URI), which is first and foremost a (potentially persistent) identifier

  • http URI has the highly desirable characteristic that the already deployed DNS system and http protocol mean that no independent resolver is required

The latter overcomes a legitimate criticism of all non-http URI schemes. However, use of http URIs as persistent identifiers requires a reliable strategy for managing the domain, the server, and in particular to insulate the identifier scheme from organizational name-changes that may ripple through to domain names (e.g. opengis.net → opengeospatial.org).

In this context, the existing procedures for URN assignment, accompanied by well controlled registers for elements within these, puts OGC in a good position for a transition. The name production rules in this document are almost transparent to the use of http URIs in place of URNs.

Some interesting (at times somewhat polemical) discussion of the merits of http URIs and folly of all other flavors is found in Berners-Lee’s 'Cool URIs don’t change'

http://www.w3.org/Provider/Style/URI, and Thompson and Orchard’s 'URNs, Namespaces and Registries' http://www.w3.org/2001/tag/doc/URNsAndRegistries-50. Booth’s 'The URI Lifecycle …​' http://dbooth.org/2009/lifecycle/ reinforces the story that persistence is about governance and not protocol.

Annex A: Revision History

Date Release Editor Primary clauses modified Description

2008-12-04

0.1.0

Simon Cox

N/A

Initialized draft document

2008-12-11

0.1.0

Arliss Whiteside

Cover, ii, footers, miscellaneous

Corrected format and inserted comments

2009-03-13

0.2

Simon Cox

2, miscellaneous

Accepted most of Arliss comments; completed normative references, fixed EBNF

2009-04-01

0.2

Simon Cox

all

Minor tweaks and corrections for consistency with the other OGC-NA documents.

2009-04-23

0.2

Simon Cox

3

Replaced EBNF with ABNF

2009-05-22

0.2

Simon Cox

3.2, 3.3, 5

Responses to comments received during vote to approve: 1. NTS are policy documents, 2. Note about register creation, 3. remove ‗format‘ from URI request syntax example, 4. clarify resolver syntax and operation

2010-01-31

1.1.0

Simon Cox

all

ABNF revised to match RFC 3986; http URI syntax made explicit Added historical note about URNs vs URIs.

2010-02-28

1.1.1

Simon Cox

3, 4, 5

Added 'ResourceSpecificPath' to requirements for a NTS Added note pointing out that URN URL conversion rule matches the http URI production rule Elaborated submission process to allow a resource representation (to be hosted by OGC) as an alternative to a resource locator

2018-05-15

1.2

Gobe Hobona

all

Converted to asciidoc. Added references to the OGC Definitions Server. Updated UCUM reference. Added the approval process diagram. Clarified the status flags to only include valid, invalid, superseded and retired. Added a reference to the Github issue tracker.

2018-07-05

1.2

Gobe Hobona

7.3

Added 'proposed' as a status value, as per motion passed at the Fort Collins TC.