OGC URN Policy

Back to OGC Naming Authority. This page is available publicly and to Member’s only.

 The OGC URN scheme is defined in the OGC Document:

• 07-107r1 – the IETF RFC that defines the ogc:urn scheme, for IANA registration. (Note – this will become a public document once approved by the IESG)

 A more detailed OGC public document describes the OGC URN “def” branch” (OGC Document 06-023r1).

Overview of the OGC URN Syntatic Structure

 The Namespace Specific String (NSS) of all URNs that use the “ogc” NID will have the following structure:

 urn:ogc:{OGCresource}:{ResourceSpecificString}

 where the “OGCresource” is a US-ASCII string that conforms to the URN syntax requirements [RFC2141] and defines a specific class of resource type. Each resource type has a specific labeling scheme that is covered by “ResourceSpecificString”, which also conforms to the naming requirements of [RFC2141]. The only exception is that the character “:” shall not be used as part of the “OGCResource” string. This is to avoid possible confusion. Further, “OGCResource is case sensitive.

Governance

 The OGC Naming Authority (ONA) manages the assignment of “OGCresources” and the specific registration values assigned for each resource class. The ONA is a special Subcommittee of the OGC Technical Committee (TC) and reports to the Architecture Working Group of the TC. The ONA is comprised of seven OGC members nominated and approved by the membership. The current ONA membership is comprised of Simon Cox (CSIRO), Richard Martell (Galdos), Clemens Portele (Interactive Instruments), Farrukh Najmi (Wellfleet), John Herring (Oracle), Doug Nebert (USGS), and Carl Reed (CTO, OGC Staff).

 A key function of the OGC naming authority to is review and approve or deny any new definition or use of the {ResourceSpecificString}. Any time that a new definition or use of the {ResourceSpecificString}, the member or members shall complete a OGC URN {ResourceSpecificString} proposal and send this proposl to the ona@opengeospatial.org email reflector. The ONA will review the proposal and either accept or reject with guidance the proposal. If accepted, the URN will be added to the OGC URN registry. If rejected, the proposer(s) can mpdify the proposal and resubmit to the ONA for consideration. The template for the URN {ResourceSpecificString} can be accessed from (URL to public template document to go here once the OGC URN is approved). In all cases, the ONA will review and provide a response in less than two weeks time. Once approved, the new OGC urn will be added to the OGC URN “resolver” application.

 Another function of the ONA is to consider and make recommendations regarding a new {OGCresource}. In this case, a more detailed proposal is required. The tempalte for submission of an {OGCresource} submission is the standard OGC document template used for all OGC standards (https://portal.ogc.org/files/?artifact_id=3244). Upon reviewing the proposal, the ONA will make a recommendation to the OGC Architecture Board (http://www.opengeospatial.org/projects/groups/oab). The OAB will make the final decision regarding the assignment of a new {OGCresource} branch.

The OGC URN Resolver

 The OGC maintains a publicly accessible URN resolver at http://urn.opengis.net/. Whenever the OBA approves a new use of the {ResourceSpecificString}, the new urn will be made accessible through the resolver.

Definition Branch

The most mature OGC URN Branch is the “def” branch. This branch was first defined in 2004 on an experimental basis. Since then, OGC members have approved a formal OGC document that describes the “def” branch”.

 The purpose of the “def” branch of the OGC URN designation is to provide identifiers for concepts and definitions. These include coordinate reference systems and related components, units of measure, nils, and various object types and definitions.

 These also include definitions and concepts maintained by OGC and also by other authorities who do not provide URIs for the concepts, but which are of importance in OGC Web Services and encodings.

 The “def” branch shall be composed with the following node designations:

“urn:ogc:def” “:” objectType “:” authority “:” [ version ] “:” code

 The set of objectTypes currently available is given in the following table:

 The set of authorities currently recognised is given in the following table:

 Examples:

 urn:ogc:def:dataType:OGC:1.1:measure urn:ogc:def:nil:OGC:unknown

 The specification for the “def” branch is published as an OGC Best Practice document: Definition identifier URNs in OGC namespace (OGC document 06-023r1).

Service Type Branch

 Another branch that has been defined and is now in use in a number of OGC standards is the Service Type Branch.

 The purpose of the “serviceType” branch of the OGC URN designation is to provide a lookup for encodings and implementations of those encodings.

 The “serviceType” branch shall be composed with the following node designations:

“urn:ogc:serviceType” “:” name “:” version “:” [binding] [“:” profile]

 “name” is the service

 Names of service types should be represented as full words concatenated using an “upper camel case” style, describing as fully as practical the actual title of the specification. Abbreviations are acceptable and should be all upper case. Names shall not include the specification version, nor the term OGC or OpenGIS. Special characters such as Trademarks shall be omitted.

“version” is an up-to three-part version, subversion, and revision in the format:

 version = [DIGIT] DIGIT “.” DIGIT [DIGIT] [“.” DIGIT]

 “binding” is either an implementation type or conformance alternative within the service type that is formally recognized and published by the OGC.

 “profile” is used when multiple tiers of implementation types or conformance alternatives are allowed within the service, if omitted, there may still exist a profile (see binding).

 Examples:

 urn:ogc:serviceType:CatalogueService:2.0.1:CORBA

 urn:ogc:serviceType:CatalogueService:2.0.1:HTTP:ISO19115/19119

 urn:ogc:serviceType:GridCoverage:1.0:COM

Specification Branch

 The purpose of the “specification” branch of the OGC URN designation is to provide a lookup for OGC specification documents and related materials that may be bundled with them. There is a 1:1 correspondence between a specification URN and a resolvable document. The expected return formats shall be documents or an extractable group of documents conveyed in a single file.

 The “specification” branch shall be composed with the following node designations:

“urn:ogc:specification” “:” name “:” version “:” [type] [“:” status]

 “name” is the document name

 Names of specifications should be represented as full words concatenated using an “upper camel case” style, describing as fully as practical the actual title of the specification. Names shall not include the specification version or document number, nor the term OGC or OpenGIS^?. Puncutation and special characters such as Trademarks shall be ommited.

“version” is an up-to three-part version, subversion, and revision in the format:

 version = [DIGIT] DIGIT “.” DIGIT [DIGIT] [“.” DIGIT]

 “type” is a specification document type recognized and published by the OGC, if omitted, its value is implementation specification, “is”

 type = [“is”] / “isc” / “ap” / “rp” / “bp” / “dp” / “wp” / “rfc” / “cr”

 is = Implementation Specification isc = Implementation Specification Corrigendum ap = Application Profile rp = Recommendation paper bp = Best Practices Paper dp = Discussion Paper wp = White paper rfc = Request for Comment cr = Change Request

 “status” is an optional tag denoting the adoption status of the document. The default value, if omitted, is “active”

 status = [“active”] / “draft” / “deprecated” / “retired” / “corrigendum”

 Examples:

 urn:ogc:specification:CatalogueService:2.0.1:is:deprecated

 urn:ogc:specification:GeographyMarkupLanguage:3.1.1:

 urn:ogc:specification:WebMapService:1.1.1::deprecated

 — GregBuehler – 24 May 2007

Discussion

Is the URN resolver just a redirection-service, or is it a registration-service?

 We appear have two kinds of resources for which we want URN designators:

1. artefacts, i.e. single resource representations
2. non-artefact resources, with potentially multiple representations

Single resource representations – the specification branch

 Doug is focussing on the first case, which has the “specification” branch as the archetype. In this branch, a URN such as urn:ogc:specification:CatalogueService:2.0.1:is:deprecated is essentially a logical alternative to https://portal.ogc.org/files/?artifact_id=5929&version=2 – preferable because the latter contains no hints as to its content. This merely requires a single mapping table to be maintained, and the governance arrangements are essentially the OGC P&P’s.

 A URN resolver for this branch can be (and largely has been) implemented without much more trouble (i.e. URN as input, http 303 redirect to the artefact URL as output). Looking at the roles identified in ISO 19135:

 At the Executive level:

• OGC is the Register Owner
• OGC is the submitting organization (for OGC specs)

 At the management level:

• OGC TC is the Control Body
• Carl/Greg (?) is the Register manager
• Greg/Kevin is the Registry manager.

 So far, so good.

 The spec list should be completed with all the specs linked from here http://www.ogc.org/standards (including the deprecated and replaced ones, etc).

 Doug is happy.

Resources with multiple representations – e.g. serviceType branch

 But as soon as we go even one step further, it is more complicated. For example, lets look at the “serviceType” branch. A serviceType may be described by a (clause from a) document, but other representations might sensibly exist (e.g. WSDL?). So while a URN like urn:ogc:serviceType:CatalogueService:2.0.1:Z39.50 serves fine to designate (#) the service type, more arguments (e.g. the “representation type” e.g. (specification clause|wsdl|html|text)), or some negotiation, are required to retrieve a corresponding resource representation.

 (#) Note that the designator by itself still plays a key role that it is required for – it can serve as a “key” or switch in applications (supporting the operation “identity comparison”).

 But we are probably still dealing with a case where the resources being designated by URN’s are relatively small in number, or at least enumerable, and (even if there are multiple resources) they can be added by the “submitting organization” one at a time.

 I guess that what gets registered is

• the URN
• at least one representation-type <-> artefact-URL association per URN

 [There needs to be a set of representation-types – are the MIME types enough?]

 If an artefact is not already in a web-accessible repository (i.e. no existing URL) then either (i) the registration of the URN should be rejected, or (ii) our registry should have a coupled repository.

“def” branch

 The “def” branch is more interesting still. Here we have

1. a very large number of resources per type – typically too many to register one by one, and unenumerable for some resource types (e.g. UOM)
2. multiple representations of some types (e.g. property-type definitions in GML or OWL; Feature-type definitions in XML Schema or UML/XMI)
3. no easily extracted discrete representation available for some types (definition is a fragment of a resource – e.g. an XML Schema element declaration; a UML Class; a row in a database)
4. no prior representation available for some types (definition is an algorithm – e.g. UCUM compound units, parameterized CRS’s, compound CRS)

 There is a lot of variation. So we need to think of delegating the control-body role on a per type basis – i.e. a submitting organization proposes a new urn:ogc:def:objectType, and a control-body for URN’s in that branch.

 For some types (e.g. phenomenon) the resolution rule varies according to the authority (e.g. OGC vs SWEET) so delegation to that level is also required.

 For some types, the URN essentially maps to an algorithm (e.g. UOM), so it is probably reasonable for a resolver to return a description of the algorithm for all URNs for the type (e.g. the UCUM spec)

 Where possible, the algorithm required for these types can lead to a “service-call” that returns a dynamically generated resources (e.g. a gml:UnitDefinition XML representation, e.g. gml:CRS XML representation). URN’s for CRS and UOMs may also be used in calls to CRS and unit conversion services. Etc etc.

 Again, there may be a requirement for a coupled repository. More likely in this case the requirement will be for the Submitting Organization to set up a web-service that implements the algorithm/rule separate from the URN registry administered by OGC.

 — SimonCox – 13 Jun 2007

Content of the “ogc” URN namespace

 1. Create a new “cite” branch for compliance-testing resources:

• ats – Abstract Test Suite
• ets – Executable Test Suite

 Example (Compliance test suite for WFS 1.1): urn:ogc:cite:ets:WebFeatureService:1.1:2007.1

 2. In the “def” branch, broaden the authority node to allow reference to a standard.ExamplesISO-19136, RFC-2616, OGC-07-110

 3. Permit registration of a “template”: a regular expression that denotes a family of related identifiers (to reduce “register bloat”).

 Example (current EPSG CRS definitions): urn:ogc:def:crs:EPSG:\d{4,5}

 — Main.rmartell – 02 Oct 2007

Managing the namespace

 Presumably the OGCNA manages the namespace and reviews/approves id assignments. What is the process for this? How are identifiers submitted? For example, could one use a web form to create and automatically verify a new entry? Submit a gml:dictionaryEntry?

 By way of illustration, here’s an OID repository that strikes me as a good example of something the OGCNA might work towards developing.

 — Main.rmartell – 02 Oct 2007

History: r8 – 19 Dec 2007 – 22:02:38 – KevinStegemoller