OGC 08-094r1 SWE Common Data Model
6.2.4 Countable discrete
Discrete countable properties are also of interest and are most accurately captured with a numerical integer representation. They do not require a unit since the unit is always the
unit of count i.e. the person if we are counting persons, the pixel if we are counting pixels, etc. Note that continuous properties can also be represented as integers with
certain combinations of scale and precision. This case should not be confused with the countable properties described here.
Examples
Array indices and sizes are countable properties with no unit. There are numerous other countable properties such as number of persons, number of bytes, number of frames, etc.
for which the unit is obvious from the definition of the property itself.
A discrete countable representation should not be confused with a continuous numerical representation whose scale and precision allow encoding the property value as an integer.
Requirement
http:www.opengis.netspecSWE2.0reqcorecountable-rep-valid
Req 5. A countable representation shall at least consist of an integer number.
The “Count” data type detailed in clause 7.2.7 is used to define a data component with an integer representation and no unit of measure.
6.2.5 Textual
A textual representation is useful for providing human readable data, expressed in natural language, as well as various alpha numeric tokens that cannot be assigned to well-defined
categories.
Examples
Comments or notes written by humans ex: data annotations, quality assessments. Machine generated messages for which there is no taxonomy ex: automatic alert messages.
Alphanumeric identifier schemes leading to a large number of possibilities that cannot be explicitly enumerated ex: UUID, ISBN code, URN.
Requirement
http:www.opengis.netspecSWE2.0reqcoretextual-rep-valid
Req 6. A textual representation shall at least consist of a character string.
12
Copyright © 2011 Open Geospatial Consortium
SWE Common Data Model OGC 08-094r1
The “Text” data type detailed in clause 7.2.5 is used to define a data component with a textual representation.
6.2.6 Constraints
Constraints can be added to some representation types to further restrict the set of possible values allowed for a given property:
- A Boolean representation cannot be restricted further since it is already limited to
only two possibilities. -
A numerical representation can be constrained by a list of allowed values andor bounded or unbounded intervals. A decimal representation can also be constrained
by the number of significant digits after the decimal point. -
A categorical representation can be constrained by a list of possible choices, which should be a subset of the list of possibilities defined by the code space.
- A textual representation can be constrained by a pattern expressed in a well known
language such as regular expression syntax. These constraints apply only to the value of the data component to which they are
associated. They shall not be used to express constraints on other data components or on any other information than the value.
Examples
A decimal representation of an angular property such as latitude can be constrained to the [-90° 90°] interval. A temperature reading produced by a sensor can be constrained to the [-50°C +250°C] range.
6.3 Nature of Data
We define “Nature of data” as the information needed to understand what property the value represents. It is thus connected to semantics and the semantic details are often
provided by external sources such as dictionaries, taxonomies or ontologies. Note that it is independent of the type of representation used and it does not include information
about how the data was actually measured or acquired. This lineage information should be described by other means as explained in clause 6.4.2.
6.3.1 Human readable information
The first means by which nature of data can be communicated is through human readable text. The data component’s description, which is present in all data types defined in this
specification, can hold any length of text for this purpose. The data component’s label is used to carry short human readable information i.e. a short name; this is useful to allow
data consumers to quickly identify the represented property.
Copyright © 2011 Open Geospatial Consortium
13