The first draft version of the guidance for the asset identification process. For the data to be discoverable and accessible through the IOOS Data Catalog, all observing assets must be identified in accord with the present IOOS Convention.
Edit me

DISCLAIMER: This is an OBSOLETE version of the document that was DEPRECATED as an official IOOS document.
Please DO NOT refer to this publication.


Revision History

Version Description Date
0.0.1 First draft 2010-12-22
0.1 Streamlined and cleaned up draft 2013-12-06

Contributors

Name Role Association
Jeff de La Beaujardière Author NOAA/NESDIS/Technology Planning and Integration Office
Derrick Snowden Contributor U.S. IOOS Office
Carmel Ortiz Contributor U.S. IOOS Office
Alex Birger Contributor U.S. IOOS Office
Anna Milan Contributor NOAA National Geophysical Data Center (NGDC)

References

IETF RFC 2141



Informative Examples

For the sake of illustration, we first provide examples of identifiers in use by IOOS. Later sections of this document constitute the actual specification of those identifiers. In the case of conflict or ambiguity, the specification sections take precedence over these examples.

Asset Identifier  
WMO buoy 42001 urn:ioos:station:wmo:42001  
Wave sensor on WMO buoy 42001 urn:ioos:station:wmo:42001:wpm1  
CO-OPS station cb0102 urn:ioos:station:NOAA.NOS.CO-OPS:cb0102  
Active water level sensors within CO-OPS network of stations urn:ioos:network:NOAA.NOS.CO-OPS:WaterLevelActive  
Water level sensor at CO-OPS station 8454000 urn:ioos:sensor:NOAA.NOS.CO-OPS:8454000:D1  
Nortek Acoustic Doppler Profiler sensor that is measuring water currents and/or waves and is mounted on the CO-OPS cb0201 station style=white-space:nowrap urn:ioos:sensor:NOAA.NOS.CO-OPS:cb0201:Nortek-ADP-514


General Identifier Convention

Use of Uniform Resource Names

An IOOS identifier is a Uniform Resource Name (URN). URNs are commonly used as identifiers in the Internet\’s information architecture. An introductory description of URNs may be found on Wikipedia. Some of the material in this section is based on definitions and restrictions established by Internet Engineering Task Force (IETF) Request for Comments (RFC) 2141.

All URNs assigned by IOOS begin with the string urn:ioos:, followed by one or more fields also separated by colons (:). The initial urn: indicates that the identifier is a URN. The following ioos: indicates that the URN is in the IOOS namespace.

NOTE: IOOS intended to formally register the ioos namespace with IANA, but has not done it yet (2010-12-22) has not.

The additional fields may only include letters and numbers (A-Z, a-z, 0-9) and the following characters: ( ) + , - . = @ ; $ _ ! *

Special characters not in the foregoing list must be represented using hexadecimal encoding as %xx, where xx represents a two-digit hex value. The use of such characters in IOOS URNs is not recommended.

Case Insensitivity

IOOS URNs are considered to be case-insensitive. Example: urn:ioos:ABC and urn:ioos:abc refer to the same thing. This is more restrictive than, but permitted by, IETF RFC 2141. The fields in IOOS URNs are customarily lower-case but may appear in uppercase or mixed-case.

Identifier Pattern

The general pattern for IOOS asset identifiers is

urn:ioos:asset_type:authority:label[:component]

which consists of the following fields delimited by “:”:

urn:ioos
a fixed string indicating this is an IOOS URN;
asset_type
a variable indicating the type of asset being identified;
authority
an abbreviation or name for the organization that assigned the label;
label
the number or label that was assigned by the authority to the asset;
component
an optional field naming a specific component.

The following sections explain in details the use of all variable fields. Ideally these fields will be populated with values from community governed controlled vocabularies. While this is not mandated by this specification, some candidate vocabularies are suggested in the following sections.

Asset Type

The asset_type field indicates the type of asset to which this identifier applies. The following values for asset_type are recognized by IOOS:

station
A fixed installation or nominally-constant position where measurements are performed. Examples include: a water-level gauge mounted on a pier; a moored buoy that moves within a known watch radius of the nominal mooring location; an OceanSITES deep-water monitoring location; a site at which water quality samples are taken.

A component field may be added to the URN to identify a specific sensor located at the station. If component field is omitted, the URN identifies station itself.

network
A network of stations defined above.
sensor
A device associated with the station that measures one or more observed quantities at or adjacent to the station location. Examples include: a water-level sensor; a temperature sensor; an anemometer; a current meter. A sensor identifier URN includes the authority and label fields of the station, and a component field to distinguish it from other sensors at the same station. Note that label for sensor is different from label for station.
survey
A visual observation, measurement or collecting samples by a human observer performed at a station or from a ship for a follow-up analyzes in the laboratory.

Example: a quarterly visit to a known location to collect water for chemical analysis; an assessment by a diver of the species present in a particular location, etc.

Additional asset_type values may be added by IOOS as needed. Candidate controlled vocabularies that may be adopted as the valid values in the asset_type field are:

Authority

The authority field indicates the organization that assigned the label for this asset. There is no fixed set of values, because additional authorities may become relevant as new observing systems are connected to IOOS. However, the same abbreviation or name should be used for all instances of a particular authority. These abbreviations are case insensitive. The following values for authority are currently used in IOOS:

wmo
World Meteorological Association.
noaa.nos.co-ops
Center for Operational Oceanographic Products and Services (COOPS) in the National Ocean Service (NOS) of the U.S. National Oceanic and Atmospheric Administration (NOAA).
usace
U.S. Army Corps of Engineers.
fiu
Florida International University.
test
Temporary service instance using for test.

Candidate controlled vocabularies that may be adopted as valid values for the authority field include:

  • GCMD Keywords
    • Data Centers: http://gcmdservices.gsfc.nasa.gov/static/kms/providers/providers.csv
    • Projects: http://gcmdservices.gsfc.nasa.gov/static/kms/projects/projects.csv

Label

The label is a number or string assigned by the Authority to the asset. Allowed values are defined by the particular authority. The only restrictions are that (a) the characters used must not conflict with the URN specification (see section 2.1) and (b) labels in the scope of a given authority must be unique. The label value varies between station and sensor URNs.

Component

The component field is used to distinguish between different assets associated with the same parent asset. For example, a buoy may have multiple sensors attached to it, and each sensor will have an identifier that includes the label for the buoy and the label for the sensor. The component label must be unique for each asset_type:authority:label.

Convention for Specific Asset Types

Station Identifiers

The pattern for IOOS platform identifiers is urn:ioos:station:authority:label[:version] Platform identifiers do not include a component field.

Sensor Identifiers

The pattern for IOOS sensor identifiers may be either

urn:ioos:sensor:authority:label_sensor[:version]

or

urn:ioos:station:authority:label_station:component[:version]

Depending on the option, sensor is identified either by its label_sensor, or by a station component field, which provides a name for the sensor. The specific names are at the discretion of the organization operating the sensor or the service to access data from the sensor. The component and label_sensor values may vary for the same sensor, and may reflect the make and model of the sensor (e.g., ‘‘SONTEK-ADP-419’’), the phenomenon observed by that sensor (e.g., ‘‘salinity’’), or an arbitrary label used by the organization (e.g., ‘‘A1’’). The name may not include characters not allowed in Section 3.1.

Version Control

Currently, IOOS Convention does not regulate asset versioning; therefore, no requirements have been established for the version number report. It is strongly recommended to avoid referring to any version number at all in asset’s URN.

Survey Identifiers

(To be discussed)

Visual Observations from Ships

(this is probably the same as survey identifiers)

Observer (i.e. urn:ioos:observer:…) seems just as good as other choices. 

I think it would be good to also indicate either (1) the general observing protocol or (2) the specific type of observation, as follows: 

General observing protocol

If visual estimates are made according to, for example, the NWS Observing Handbook No. 1 (2004), then perhaps the so-called “sensor” ID could be something like 

_****_

Indeed, instead of inventing our own URI for this case perhaps we should just insert the URL of the observing protocol: 

http://www.vos.noaa.gov/ObsHB-508/ObservingHandbook1_2004_508_compliant.pdf

This avoids any need for additional interpretation. In the IOOS water quality project we have seen another case where the “metadata” about the measurement procedure is a PDF file containing descriptions of laboratory procedures. 

Specific type of observation

The identifier could include the type of observation made by the human. 

For example, in the Handbook, Chapter 2, page 2-7 says “iw” is the “wind speed indicator” and that it has values 0,1,3,4 depending on how the wind speed was estimated or measured, with “3” being “wind speed estimated in knots.” We could, for example, use 

<urn:ioos:observer:iw:3>

as the “sensor” ID for such an observation.  Or, we could be less cryptic (since we are not so bandwidth-constrained these days) and expand that out: 

<urn:ioos:observer:wind_speed_indicator:estimated_in_knots>

Similarly, from p.2-76, sea surface temperature measurement could use 

<urn:ioos:observer:ss:1>

<urn:ioos:observer:sst_indicator:negative_intake_measurement>

Personally, I think the cryptic VOS codes could be recorded as-is in the DB because that is presumably what you’re getting on input, and then on output they could be converted to something more readable. 

I don’t know whether (1) or (2) or neither is best. I’m assuming that some data users need to know information like iw=3 and ss=1.

 

Tags: