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:
A more detailed OGC public document describes the OGC URN “def” branch” (OGC Document 06-023r1).
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.
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 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.
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:
objectType value | short definition | full definition reference |
---|---|---|
axis | coordinate system axe | 9.3 in OGC 05-103 |
axisDirection | axis direction code | 9.4 in OGC 05-103 |
coordinateOperation | coordinate operation | 11.1 in OGC 05-103 |
crs | coordinate reference system | 8.2 in OGC 05-103 |
cs | coordinate system | 9.2 in OGC 05-103 |
datum | geodetic datum | 10.1 in OGC 05-103 |
dataType | data type | D.1 in OGC 05-007r4 |
derivedCRSType | derived CRS type code | 8.3 in OGC 05-103 |
documentType | document type | 4. in OGC 05-020r4 |
ellipsoid | ellipsoid | 10.2.2 in OGC 05-103 |
featureType | feature type | as specified in an application schema (ISO 19109) |
group | operation parameter group | 11.2 in OGC 05-103 |
meaning | parameter meaning | D.1 in OGC 05-007r4 |
meridian | prime meridian | 10.2.1 in OGC 05-103 |
method | operation method | 11.2 in OGC 05-103 |
nil | explanations for missing information | 8.2.3.1 in OGC 05-108r1 |
parameter | operation parameter | 11.2 in OGC 05-103 |
phenomenon | observable property | 6.2 in OGC 05-087r2 |
pixelInCell | Pixel in cell code | 10.3 in OGC 05-103 |
rangeMeaning | range meaning code | 9.4 in OGC 05-103 |
referenceSystem | value reference system | D.1 in OGC 05-007r4 |
uom | unit of measure | |
verticalDatumType | vertical datum type code | 10.3 in OGC 05-103 |
The set of authorities currently recognised is given in the following table:
authority | Referenced authority | applicable object-types | version value | code value |
---|---|---|---|---|
EDCS | Environmental Data Coding Specification ISO/IEC 18025:2005 | phenomenon | 2005 | Label or Code column value |
EPSG | EPSG database http://www.epsg.org/ | axis, axisDirection, coordinateOperation, crs, cs, datum, derivedCRSType, ellipsoid, group, meridian, method, parameter, pixelInCell, rangeMeaning, referenceSystem, verticalDatumType | Database version | EPSG numeric identifier value |
OGC | Open Geospatial Consortium | dataType, documentType, featureType, meaning, nil, phenomenon, referenceSystem, uom | ||
SI | International System of Units ISO 1000:1992, http://www.bipm.fr/en/si/ | uom | 2000 | Values from Symbol column of tables |
UCUM | Unified Code for Units of Measure http://aurora.regenstrief.org/UCUM | uom | omit | “Case sensitive” form of code |
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).
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
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
We appear have two kinds of resources for which we want URN designators:
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:
At the management level:
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.
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
[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.
The “def” branch is more interesting still. Here we have
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
1. Create a new “cite” branch for compliance-testing resources:
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
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
Receive the latest news on OGC.
© 2024 Open Geospatial Consortium. All Rights Reserved.