8.1.1.  Dependency on ISO TC 211 Models

Figure 3 — External Package Dependencies – ISO TC 211

The SensorML standard utilizes the ISO 19115 models for common metadata properties such as citations, online resources, responsible party, and constraints. While Version 1.0 of SensorML defined encoding based on the ISO 19115 models, this version utilizes these models directly.

Figure 4 — ISO 19115 Models for dependent classes.

8.1.2.  Dependency on SWE Common Data Models

In particular, SensorML is heavily dependent on the SWE Common Data Model standard for defining inputs, outputs, and parameters, as well as for specifying characteristics, capabilities, interfaces, and event properties. The SWE Common Data Models, which were originally defined within the version 1.0 SensorML specification, are since version 2.0 defined as a separate specification and are utilized throughout the SWE family of encoding and web service specifications.

Figure 5 — External Package Dependencies - SWE Common Data

The SWE Common specification provides a flexible yet robust means of defining data types and data values, including support for simple data types such as Quantity, Boolean, Category, Count, Text, and Time, as well as aggregate data such as DataRecord, DataArray, Vector, and Matrix. Additionally, SWE Common supports the concept of DataChoice, which will be utilized by SensorML for providing multiplexed messages in data streams and configurable options for processes and physical systems.

The data models in SWE Common provide additional properties than are provided by basic data types, including for example, units of measure (uom), quality indications, allowable constraints, significant digit counts, and in particular, the meaning and semantics of a data component. Both simple and aggregate data components in SWE Common allow for unambiguous definition of that data component through a resolvable link to an online dictionary or ontology. The definition of the SWE Common Data Models can be found in OGC 08-094r1.

The main objective of SWE Common Data Models is to achieve interoperability, first at the syntactic level, and later at the semantic level (by using ontologies and semantic mediation) so that sensor data can be better understood by machines, processed automatically in complex workflows, and easily shared between intelligent sensor web nodes.

SensorML depends heavily on the AbstractDataComponent element defined in SWE Common. This element serves as the base component from which all relevant data types in SWE Common are derived, including Quantity, Count, Category, Boolean, Text, DataRecord, DataArray, Vector, Matrix, and DataChoice. AbstractDataComponent thus serves as a substitution group that any of these data types can satisfy. AbstractSWEIdentifiable will serve as the basis for the ObservableProperty element defined in this specification (Clause 8.2.1).

The model for the SWE Common AbstractDataComponent is given in the figure below:

Figure 6 — Models for dependent SWE Common AbstractDataComponent class.

8.1.3.  Relationship to Observations and Measurements (O&M)

Conceptual models for Observations and Measurements are provided by ISO 19156, which also provides models for sampling feature types. XML Schema encodings of these models are provided by the OGC Observations and Measurements XML Implementation Document (OGC 10-025). The model for Observation defines a procedure of type AbstractFeature which references or describes the origin of the observation (i.e., how the observation came to be).

SensorML has an association to the O&M models but no direct dependencies on them. The result of a SensorML process is typically considered to be an observation result if it is measuring or deriving some value of a physical property or phenomenon. Thus, the output values described in SensorML and resulting from a sensor or process may be packaged in an O&M Observation object or provided as a SWE Common DataStream. Inversely, the procedure property within an Observation instance may reference a SensorML description of the measurement process.

8.1.4.  Relationship to OGC API — Processes

The OGC API — Processes — Part 1: Core standard (OGC 18-062r2) supports the wrapping of computational tasks into executable processes that can be offered by a server through a Web API and be invoked by a client application. The standard specifies a processing interface to communicate over a RESTful protocol using JSON encodings.

Even though the the standard recommends implementations to support its own encoding for process descriptions, the OGC Process Description, SensorML Simple Processes and Aggregate Processes are a suitable substitution. While the OGC Process Description allows for the definition of inputs and outputs using JSON Schema, a SensorML process description would allow for a definition using SWE Common.

Physical Components and Physical Systems are also suitable surrogates for the OGC Process Description would for example allow OGC API — Processes to becoming a tasking interface for real world sensors.

8.2.1.  ObservableProperty

An ObservableProperty is a physical property of a phenomenon that can be observed and measured (e.g., temperature, gravitational force, position, chemical concentration, orientation, number-of-individuals, physical switch status, etc.), or a characteristic of one or more feature types, the value for which must be estimated by application of some procedure in an observation. It is thus a physical stimulus that can be sensed by a detector or created by an actuator.

Example

ObservableProperty is derived as a concrete instance of the SWE Common AbstractSWEIdentifiable and adds the definition property to this model. It will be used as a potential input (e.g., for detectors), output (e.g., for actuators), and for parameters (e.g., for a sensor whose measurement varies with fluctuations of atmospheric pressure on a diaphragm).

In ObservableProperty the phenomenon property will be defined by reference using the definition attribute. The definition attribute value will reference a property defined within a dictionary or ontology. An ObservableProperty may also include a name and a description. However, unlike the simple data types in SWE Common, an ObservableProperty does NOT include the properties uom, quality, or constraints, since these are typically characteristics of the measuring procedure and not properties of the observable phenomenon itself.

8.2.2.  DescribedObject

As shown in the UML model below, the DescribedObject class provides a specific set of metadata for all process classes in SensorML. The DescribedObject provides a unique ID, and support for a label and a description. The unique ID in SensorML will be supported by a single uniqueId property.

Metadata about each process is essential to supporting identification, discovery, and qualification of the process. Metadata is provided by the base class, DescribedObject, from which AbstractProcess is derived. While these metadata may provide relevant information to understand quality of output from the process, the values of properties within the DescribedObject should not be required for execution of the process. The model for the DescribedObject is shown in Figure 7, while the models for the individual property values are provided in either Figure 8 or in the ISO 19115 models in Figure 9.

The DescribedObject includes several descriptive properties that support rapid discovery (keywords, identification, and classification), constraints (validTime, securityConstraints, legalConstraints), qualification (characteristics and capabilities), references (contacts and documentation), and history. These are each grouped in lists, which provide for easy separation and parsing of these properties.

8.2.2.1.  Extension Property

The extension property allows one to add domain or community-specific content to a DescribedObject instance. This might include, for example, security taggings, vendor or community-specific metadata, or information encoded in other models or schema. Extension properties must exist in a separate namespace and SensorML-compliant software is not required to understand or utilize the information contained within the extension property.

The constraints on the extension property include: a) the extension model must be defined in a separate namespace, b) the information added by the extension model must not be required for execution of the process, and c) SensorML-compliant parsers may parse and utilize the information within these extensions but they are not required to do so in order to be compliant to the SensorML standard.

Requirement 9
Identifier	/req/model/coreProcess/extensionIndependence
Included in	Requirements class 2: /req/model/coreProcess
Statement	Models inside of the extension property must exist within a namespace other than SensorML.

Requirement 10
Identifier	/req/model/coreProcess/extensionRestrictions
Included in	Requirements class 2: /req/model/coreProcess
Statement	Information provided inside of the extension property must not be required for execution of the process and shall not alter the execution of the process.

 

Figure 7 — DescribedObject with Metadata Properties

 

Figure 8 — Models for Metadata Elements

8.2.3.  Legal Constraint

The legalConstraints property is based on ISO 19115 and specifies whether such legal and ethical considerations as privacy acts, intellectual property rights, copyrights, or scientific publication ethics apply to the content of the process description and its use.

8.2.4.  Capabilities

The capabilities property is intended for the definition of properties that further qualify the input or output of the process, component, or system for the purpose of discovery. These properties are defined using one or more SWE Common DataRecord elements.

Once a user has identified candidate sensors or processes based on the classifiers described above, the capabilities parameters might prove useful for further filtering of processes or sensor system during this discovery stage. Thus, the capabilities properties should be considered as information suitable for the discovery process.

Example

8.2.5.  Characteristics

A physical or non-physical process may have characteristics that may not directly qualify the output. These properties are defined using one or more SWE Common DataRecord elements.

Example

The characteristics properties may or may not be considered as information suitable for the discovery process.

8.2.6.  Contacts

Contact information can provide access to manufacturers, system experts, equipment owners, or any other persons responsible in some way for design, deployment, maintenance, or additional information regarding the DescribedObject. The contact property within the ContactList takes the ISO 19115 classes CI_ResponsibleParty as its values.

8.2.7.  Documentation

Documentation can be provided which provides further clarification about the DescribedObject. This might include technical manuals, manufacturer brochures, journal references, or theoretical-basis documents. The DocumentList document property takes the ISO 19115 CI_OnlineResource as its value.

8.2.8.  History

Within SensorML, the history of a process can be provided through a collection of Event objects. These are provided within an EventList that serves as the value of the history property. Events might for instance, specify calibration or maintenance history of a sensor, changes to an algorithm or parameter within a computational process, or deployment and maintenance events.

Figure 9 — Model for history events

8.2.9.  AbstractProcess

As discussed in the Core Concepts, the major elements of SensorML are modeled as physical and non-physical processes. All SensorML process elements shall derive from AbstractProcess,shown in Figure 10. The class AbstractProcess itself derives from the DescribedObject class and thus inherits a wide range of optional metadata supporting discovery, identification, and qualification and an option for domain and community-specific extensions. In addition to the metadata provided by DescribedObject, the AbstractProcess includes the properties of inputs, outputs, and parameters, as required by the process model defined in the Core Concepts, as well as the properties typeOf, featureOfInterest, configuration, and modes which will be discussed below.

Figure 10 — UML models for DescribedObject and AbstractProcess

8.2.9.1.  Inputs, Outputs, and Parameters

As discussed in the Core Concepts, any process can have inputs, outputs, and parameters. Processes typically receive input and based on the parameter settings and methodology, generate output. Some processes, such as detectors, receive physical stimulus as input and generate digital numbers as output. In such cases, the input would be represented as an ObservableProperty, and the output as a DataComponent (e.g., a Quantity). If this output is encoded and accessible directly, then the output can be represented as a DataInterface.

Example

Examples

A digital thermometer is stimulated by an observable property of the environment (temperature), which is modelled as its input (ObservableProperty), and outputs a digital number (Quantity) that represents a measure of that property.

Thus, an AbstractProcess model supports the inputs, outputs, and parameters properties in conformance with the Core Concepts. These properties can accept ObservableProperty or SWE Common elements AbstractDataComponent or DataStream as their values. Classes derived from AbstractDataComponent include Quantity, Count, Category, Boolean, Text, and Time, as well as ranges and aggregates of these simple data types.

 

Figure 11 — UML models for process inputs, outputs, and parameters

The core process model will utilize the SWE Common Data Models for defining inputs, outputs, and parameters, as well as for other metadata properties. SensorML models are required to support the SWE Common Data Model up to the Block Components Requirements Class, but many instances of SensorML will find ALL conformance levels of SWE Common Data to be useful, including binary encodings.

Requirement 11
Identifier	/req/model/coreProcess/SWE-Common-dependency1
Included in	Requirements class 2: /req/model/coreProcess
Statement	Any derived model or encoding for process shall utilize ObservableProperty or SWE Common Data Components as values for inputs, outputs, and parameters, and shall at a minimum conform to the SWE Common Data “Block Components Package” class (http://www.opengis.net/spec/SWE/3.0/req/uml-block-components).

The input, output, or parameters of many processes include multiple values, possibly of different data types, that are tightly related to one another. Sometimes referred to as tuples or records, these data aggregates can consist of values that are perhaps meaningless without the other associated values (e.g., the coordinates within a spatial reference system), or provide a more complete understanding because of their association with one another (e.g., a set of measured values taken by a sensor at a given time). Such data shall be modelled using the aggregate data types defined by the SWE Common Data standard.

Example

Examples

The location of a dynamic object can be specified through the aggregate values of time, latitude, longitude, and altitude. In such cases, the expression of one of the values separate from the others is meaningless or less complete than the expression of these values as a set or aggregate. These four values should be encapsulated in a Vector data type that also identifies the reference frame in which the latitude, longitude and altitude coordinates are expressed.

Weather stations often express a set of measurements of the atmosphere as a single record that might include for instance temperature, pressure, relative humidity, cloudiness, wind speed, and wind direction. These would be considered a tuple of values that provides a more complete picture of the environment at a particular time. This tuple should be modeled as a DataRecord with 7 fields (one for each measured parameters listed above + one time stamp) to indicate that the sampling time applies to all observable values included in the record.

Requirement 12
Identifier	/req/model/coreProcess/aggregateData
Included in	Requirements class 2: /req/model/coreProcess
Statement	Multiple input, output, and parameter values that are tightly related with one another shall be modelled as a SWE Common Data aggregate data type.

8.2.10.  SWE Common Data Types

Many properties in the DescribedObject and AbstractProcess classes described above are of type AbstractDataComponent as defined in the SWE Common Data Model standard. This data type is used for defining inputs, outputs and parameters, as well as for other metadata properties.

This requirements class only mandates the support of the “Simple Components” and “Record Components” as defined in the SWE Common Data Model standard. These include the scalar data types Boolean, Text, Count, Quantity, Category, Time and their range equivalents, as well as DataRecord and Vector.

However, many implementations of SensorML will find ALL conformance levels of the SWE Common Data Model to be useful, including arrays, choices and encodings. An implementation claiming support for more than the record components can pass the “Processes with Advanced Data Types” conformance test class of this standard.

8.3.1.  Simple Process Definition

A simple process is a process that, for whatever reason, is considered indivisible. That is, there is no intent to further divide the process description into an aggregation of sub-processes. While the process method may describe several steps within the algorithm, the actual execution of this process is expected to occur as a single modular unit.

Often simple processes are computational processes that can be executed with an associated piece of software. Simple processes are often one component of a physical or non-physical aggregate process.

The SimpleProcess model, as shown in Figure 12, is a concrete instantiation of the AbstractProcess model. The SimpleProcess requires a method description.

Figure 12 — Model for Simple Process

Example

8.3.2.  Process Method Definition

The ProcessMethod provides a description of the methodology used by the process to execute and generate output based on the input and parameter values. This includes a textual description, as well as an optional description of the algorithm in an appropriate format (e.g., mathML) and optional references to particular executable implementations.

The ProcessMethod definition should be sufficient to allow one to understand how input values are converted to output values, given a particular set of parameter values, and be able to write software that is capable of executing this process.

A ProcessMethod description may be protected by security or legal constraints, which would purposely prevent access to the method description as well as restrict knowledge of the methodology to authorized personnel only. However, regardless of access restrictions, a ProcessMethod should always be able to be referenced and identified by a unique identifier.

Figure 13 — Model for ProcessMethod

8.4.1.  Aggregate Process Definition

An aggregate process is a collection of autonomous component processes with an explicit mapping of the data flow between these processes. Components of an aggregate process can be simple processes (i.e., atomic) or be aggregate process themselves. Aggregate processes can include both physical and non-physical (i.e., logical) components.

In SensorML, an aggregate process is agnostic to the execution engine that may perform the actual execution of individual sub-processes and manage the execution sequencing and the flow of data between the components. Also, while it is possible in SensorML to more explicitly define the data encoding if desired by using the encoding specifications defined in the SWE Common Data Specification, SensorML is typically agnostic to the protocol and format of data flowing between logical processes.

This provides significant flexibility as to where and how a SensorML-defined aggregate process is executed. While the ProcessMethod explicitly defines the algorithm for executing an atomic process, the actual execution of that algorithm and the management of data flow between processes can be handled by any software system able to parse a SensorML-defined aggregate process and sequence the execution of the processes.

A SensorML-defined process component or aggregate process can be executed through web services, within the CPU of a laptop, mobile device, or supercomputer, or a mix of these. Furthermore, a SensorML-defined aggregate process can be executed wherever desired, be it at a large data or computation center, within a visualization and analysis client on a laptop, or on-board a sensor or actuator system. Thus, SensorML provides the choice to either bring the process to the data or bring the data to the process.

The model for AggregateProcess is shown in the figure below. AggregateProcess extends the AbstractProcess model and adds one or more process components and explicit linking of data flow between these components. The component property takes any component derived from AbstractProcess as its value. Component process descriptions can be provided inline or by reference.

The derivation from AbstractProcess means that an AggregateProcess instance itself has its own inputs, outputs, and parameters, as well as identification and possible metadata.

Figure 14 — Model for Aggregate Process

8.5.1.  Abstract Physical Process Defined

The AbstractPhysicalProcess model is derived from AbstractProcess and thus includes the metadata and properties of a core process. Additionally, AbstractPhysicalProcess supports additional properties that allow one to define spatial and temporal coordinates for the physical process device.

The model for AbstractPhysicalProcess is shown in Figure 15 below. The additional properties of the AbstractPhysicalProcess will be discussed in subsequent clauses.

Figure 15 — Model for Physical Process Component

8.5.1.2.  Position and Spatial Reference Frames

In this standard, the position or dynamic state of a physical object is defined as a relationship of the reference frame of the object to some external reference frame. SensorML allows for the definition of direct orthogonal (i.e., Cartesian) reference frames that are assumed to be attached to the physical component where they are described.

A reference frame is defined by its origin and its axes, which are described relative to the physical object itself using natural language and are not relative to any relationship of the object to some external frame. The relationship of this object’s reference frame to an external reference frame is defined by the position or dynamic state of the object. The models for reference frames and spatial position are provided in Figure 16. The origin of an airplane’s spatial reference frame can be defined as the being at the center of the Inertial Navigation Unit main gyro. The axes can be defined by the following statements: “X is along the symmetric axis of the airplane’s fuselage from the gyro to the nose of the airplane (along the platform roll axis of the airplane), Z is perpendicular to X and toward the belly of the airplane (along the yaw axis of the aircraft), and Y is Z cross X (in the direction of the right wing and along the pitch axis of the airplane)”. The location of this aircraft can then be given as the spatial relationship of the origin of this reference frame to some external reference frame (e.g., Earth-Centered-Earth-Fixed XYZ or latitude-longitude-altitude). Likewise, the orientation of the aircraft can be specified as the angular relationship of the axes of its reference frame to the axes of some external reference frame (e.g., ECEF or North-East-Down).

 

Figure 16 — Models for SpatialFrame and PositionUnion

In this standard, position is defined as the combination of location and orientation. Location is the llinear displacement (translation) of the origin of the object’s spatial reference frame relative to the origin of some external reference frame (which must be designated). The orientation of an object is the angular relationship between the axes of the object’s reference axes to those of some external reference frame. The dynamic state of an object can include its time-tagged location, orientation, linear velocity, angular velocity, and higher-order derivatives when required (e.g., linear and angular acceleration, jerk, etc.).

An external reference frame can be another object’s reference frame (e.g., the reference frame of a ship) or a geographic reference frame (e.g., WGS84 latitude-longitude-altitude).

The PositionUnion class provides various means of specifying the location, position, or dynamic state of an object. These will be described in more detail in the appropriate JSON encoding section, but the following rules apply to the SensorML models.

Requirement 27
Identifier	/req/model/physicalComponent/byPointOrLocation
Included in	Requirements class 5: /req/model/physicalComponent
Statement	Specification of position “byPoint” or “byLocation” shall specify the location of the origin of the object’s reference frame relative to the origin of a well-defined and specified external reference frame.

Requirement 28
Identifier	/req/model/physicalComponent/byPosition
Included in	Requirements class 5: /req/model/physicalComponent
Statement	Specification of position “byPosition” shall specify, using a GeoPose or Relative Pose object, the location and orientation of the object’s reference frame relative to a well-defined and specified external reference frame.

Requirement 29
Identifier	/req/model/physicalComponent/byTrajectory
Included in	Requirements class 5: /req/model/physicalComponent
Statement	Specification of position “byTrajectory” shall specify, at a minimum, the time-tagged location of the object’s reference frame relative to a well-defined and specified external reference frame, but may also include its orientation and any number of derivatives of the location and orientation.

Requirement 30
Identifier	/req/model/physicalComponent/byProcess
Included in	Requirements class 5: /req/model/physicalComponent
Statement	Specification of position “byProcess” shall specify SensorML-modeled process whose output provides, at a minimum, the time-tagged location of the object’s reference frame relative to a well-defined and specified external reference frame, but may also include its orientation and any number of derivatives of the location and orientation.

8.5.1.4.  3D Pose

This section introduces data types for expressing 3D pose information within SensorML documents. It builds on the GeoPose Standard.

When a 3D Pose object is used as the value of the position property within a SensorML PhysicalComponent or PhysicalSystem instance, it defines the pose of the local reference frame attached to the component (intrinsic reference frame), relative to an external reference frame (extrinsic reference frame).

 

Figure 17 — Pose Data Types

8.5.1.4.1.  GeoPose

The GeoPose Basic classes are used to define a pose relative to a tangent reference frame associated to the WGS84 ellipsoid. The location of the local tangent plane (LTP) is provided using EPSG:4979 coordinates and orientation is provided as yaw/pitch/roll angles or quaternion in the local tangent frame.

SensorML uses the Basic-YPR and Basic-Quaternion classes defined in the GeoPose Standard.

These classes are used to define the pose of an object relatively to the earth ellipsoid.

8.5.1.4.2.  Relative Pose

The Relative Pose classes Relative_YPR and Relative_Quaternion are modeled on their GeoPose counterparts, but in this case, both position and orientation are provided relative to a cartesian reference frame.

These classes are used to define the pose of an object relatively to another object (e.g., a sensor relative to its platform).

8.5.2.  Physical Component Defined

Any processing device can be considered a physical component, if it provides a processing function with well-defined inputs and outputs, if there is no intent to further divide the device description into component sub-processes, and if knowledge of its physical location is useful. Such devices could include, but not be limited to, detectors, actuators, reflectors, electrical components (e.g transformers, capacitors, resistors), or perhaps even computational units (when knowing their location in a computational facility is helpful).

As shown in the models of Figure 15, the PhysicalComponent class is a concrete instantiation of an AbstractPhysicalProcess that adds the method property, which takes a ProcessMethod as its value. ProcessMethod was defined earlier in clause 7.3.2.

8.8.1.  Modes

Example

A configurable process can but is not required to contain two or more Modes. The modes property takes a list of Modes as its values, as shown in Figure 19. A mode list shall include two or more mode properties that take Mode as their value. In addition to metadata provided by the base DescribedObject class, Mode includes a configuration property that allows one to define a collection of settings for that mode.

Figure 19 — Model for Modes

The configuration property takes a Settings object, which will be described in more detail below.

8.8.2.  Settings

The configuration property and its Settings value can be utilized in two cases:

The Settings class is shown in Figure 20 with its possible property values shown in Figure 21. For all settings, the property in the configurable process is specified by the DataComponentPath reference.

Within the Settings class, one may: a) set particular values for parameters, b) set an array of values for a parameter — and only a parameter that takes a DataArray as its value, c) further constrain allowed values for parameters, d) set the operational mode, and e) enable or disable an input or output.

Figure 20 — Model for Configured Process Settings

Figure 21 — Model for Settings Elements

8.9.1.  Overview

8.9.2.  Deployment Class

The Deployment class is used to describe when, where, why and how physical or non-physical systems are being deployed. The class Deployment itself derives from the DescribedObject class and thus inherits a wide range of optional metadata supporting discovery, identification, and qualification and an option for domain and community-specific extensions.

In particular, the deployment metadata allows for the provision of:

The UML diagram of the Deployment class is shown on Figure 22 and Table 2 provides the description of the class properties:

Figure 22 — Deployment Class

Table 2 — Deployment Class Properties

8.9.3.  DeployedSystem Class

The DeployedSystem class is used to describe each system deployed as part of a deployment. It includes the following properties:

Table 3 — DeployedSystem Class Properties

8.10.1.  Overview

8.10.2.  DerivedProperty Class

The DerivedProperty class is used to define domain specific properties that are derived from general properties such as the ones provided by the QUDT Quantity Kinds ontology.

The UML diagram of the DerivedProperty class is shown on Figure 23 and Table 4 provides the description of the class properties:

Figure 23 — DerivedProperty Class

Table 4 — DerivedProperty Class Properties

9.1.1.  Overview

9.1.2.  Media Types

Type name: application

Subtype name: sml+json

Required parameters: n/a

Optional parameters: n/a

Encoding considerations: binary

Security considerations: n/a

Interoperability considerations: n/a

Published specification: this document

Applications that use this media type: No known applications currently use this media type.
   This media type is intended for applications currently using the "application/vnd.ogc.sml+json"
   media type, which include APIs for managing, publishing or processing sensor and system metadata.

Additional information:

  Magic number(s): n/a

  File extension(s): .json

  Macintosh file type code: TEXT

Person to contact for further information:

   1. Name: Scott Simmons
   2. Email: ssimmons@ogc.org

Intended usage: COMMON

  SensorML is an OGC Standard (OGC 23-000) that provides conceptual models and encodings for
  describing sensor systems including sensors, actuators and platforms. This media type applies to
  the JSON encoding of SensorML.

Restrictions on usage: n/a

Change controller: Open Geospatial Consortium (OGC)

9.1.3.  General Encoding Principles

9.1.4.  DescribedObject

The JSON schema DescribedObject.json is an implementation of the DescribedObject UML class defined in Clause 8.2.2. It is the base schema for the following JSON objects specified in this document:

It provides a set of metadata properties that are common to all these objects. Rather than repeating this type of metadata in all examples, the following snippets show examples of the various metadata options provided by the DescribedObject schema.

Randomly Generated UUID (version 4):
"uniqueId": "urn:uuid:e3c2ea01-ed37-4bb4-bf45-aff0ad84a331"

Global Individual Asset Identifier (GIAI):
"uniqueId": "urn:epc:id:giai:0614141.12345400"

Component/Part Identifier (CPI):
"uniqueId": "urn:epc:id:cpi:0614141.123ABC.123456789"

Serialised Global Trade Item Number (SGTIN):
"uniqueId": "urn:epc:id:sgtin:123456789012.0.4711"

Global Document Type Identifier (GDTI):
"uniqueId": "urn:epc:id:gdti:0614141.12345.006847"

Ship identifier in Maritime Resource Name (MRN) namespace
"uniqueId": "urn:mrn:itu:mmsi:538070999"

Navigation aid identifier in Maritime Resource Name (MRN) namespace
"uniqueId": "urn:mrn:iala:aton:us:1234.5"

"keywords": [
  "thermometer",
  "sensor",
  "outdoor"
]

"identifiers": [
  {
    "definition": "http://sensorml.com/ont/swe/property/ShortName",
    "label": "Short Name",
    "value": "Davis Vantage Pro2"
  },
  {
    "definition": "http://sensorml.com/ont/swe/property/Manufacturer",
    "label": "Manufacturer Name",
    "value": "Davis Instruments"
  },
  {
    "definition": "http://sensorml.com/ont/swe/property/ModelNumber",
    "label": "Model Number",
    "value": "Vantage Pro2"
  }
]

"classifiers": [
  {
    "definition": "http://sensorml.com/ont/swe/property/SensorType",
    "label": "Sensor Type",
    "value": "Motion Detector"
  },
  {
    "definition": "http://sensorml.com/ont/swe/property/PlatformType",
    "label": "Platform Type",
    "value": "Unmanned Aerial Vehicle"
  },
  {
    "definition": "http://sensorml.com/ont/swe/property/PlatformType",
    "codeSpace": "https://mmisw.org/ont/ioos/platform",
    "label": "Platform Type",
    "value": "subsurface_float"
  }
]

"securityConstraints": [
  {
    "type": "urn:us:gov:ic:ism:v2",
    "classification": "TS",
    "classifiedBy": "USCG",
    "ownerProducer": "USA"
  }
]

"validTime": [
  "2023-05-07T12:30:00Z",
  "2023-05-10T00:00:00Z"
]

"validTime": [
  "2023-05-07T12:30:00Z",
  "now"
]

"legalConstraints": [
  {
    "useLimitations": [
      "Disclaimer - While every effort has been made to ensure that the data from this sensor is accurate and reliable within the limits of the current state of the art, we cannot assume liability for any damages caused by any errors or omissions in the data, nor as a result of the failure of the data to function on a particular system. We make no warranty, expressed or implied, nor does the fact of distribution constitute such a warranty."
    ],
    "useConstraints": [
      {
        "codeSpace": "http://standards.iso.org/iso/19115/resources/Codelist/cat/codelists.xml#MD_RestrictionCode",
        "value": "licenceDistributor"
      }
    ]
  }
]

"capabilities": [
  {
    "definition": "http://www.w3.org/ns/ssn/systems/SystemCapability",
    "label": "System Capabilities (No Wind)",
    "conditions": [
      {
        "type": "Quantity",
        "name": "wind_speed",
        "definition": "http://mmisw.org/ont/cf/parameter/wind_speed",
        "label": "Wind Speed",
        "uom": { "code": "m/s" },
        "value": 0
      }
    ],
    "capabilities": [
      {
        "type": "Quantity",
        "name": "flight_range",
        "definition": "http://qudt.org/vocab/quantitykind/Distance",
        "label": "Max Travel Distance",
        "uom": { "code": "km" },
        "value": 13
      },
      {
        "type": "Quantity",
        "name": "max_speed",
        "definition": "http://qudt.org/vocab/quantitykind/Speed",
        "label": "Max Speed",
        "uom": { "code": "km/h" },
        "value": 65
      },
      {
        "type": "Quantity",
        "name": "flight_time",
        "definition": "http://www.w3.org/ns/ssn/systems/BatteryLifetime",
        "label": "Battery Lifetime",
        "description": "Maximum flight time in stationary flight",
        "uom": { "code": "min" },
        "value": 24
      }
    ]
  }
]

"characteristics": [
  {
    "label": "Battery Characteristics",
    "characteristics": [
      {
        "type": "Quantity",
        "name": "bat_cap",
        "definition": "http://sensorml.com/ont/swe/property/BatteryCapacity",
        "label": "Battery Capacity",
        "uom": {
          "code": "W.h"
        },
        "value": 43.6
      },
      {
        "type": "Quantity",
        "name": "bat_volt",
        "definition": "http://qudt.org/vocab/quantitykind/Voltage",
        "label": "Operating Voltage",
        "uom": {
          "code": "V"
        },
        "value": 11.4
      },
      {
        "type": "Category",
        "name": "type",
        "definition": "http://dbpedia.org/resource/Battery_types",
        "label": "Battery Type",
        "value": "LiPo 3S"
      }
    ]
  }
]

"contacts": [
  {
    "role": "http://sensorml.com/ont/swe/property/Manufacturer",
    "organisationName": "Davis Instruments Corp.",
    "contactInfo": {
      "website": "https://www.davisinstruments.com",
      "phone": {
        "voice": "+1 (510) 732-7814"
      },
      "address": {
        "deliveryPoint": "3465 Diablo Avenue",
        "city": "Hayward",
        "postalCode": "94545",
        "administrativeArea": "CA",
        "country": "USA",
        "electronicMailAddress": "support@davisinstruments.com"
      }
    }
  }
]

"documents": [
  {
    "role": "http://dbpedia.org/resource/Web_page",
    "name": "Product Web Site",
    "description": "Webpage with specs an other resources",
    "link": {
      "href": "https://www.davisinstruments.com/pages/vantage-pro2",
      "type": "text/html"
    }
  },
  {
    "role": "http://dbpedia.org/resource/Datasheet",
    "name": "Spec Sheet",
    "link": {
      "href": "https://cdn.shopify.com/s/files/1/0515/5992/3873/files/6152c_6162c_ss.pdf",
      "type": "application/pdf"
    }
  },
  {
    "role": "http://dbpedia.org/resource/Photograph",
    "name": "Photo",
    "link": {
      "href": "https://m.media-amazon.com/images/I/71rycLk7sFL.jpg",
      "type": "image/jpg"
    }
  }
]

"history": [
  {
    "label": "Scheduled Maintenance",
    "description": "Monthly maintenance of station hardware.\n-Checked electronics\n-Checked casing\nChecked power supply.\nEverything OK.",
    "time": [ "2002-03-01T10:00:00Z", "2002-03-01T11:00:00Z" ]
  },
  {
    "label": "Calibration",
    "description": "Recalibration of acquisition electronics using temperature reference",
    "time": "2002-03-01T18:00:00Z"
  }
]

9.1.5.  AbstractProcess

The AbstractProcess.json schema is the JSON schema implementation of the AbstractProcess UML class defined in Clause 8.2.9.

The AbstractProcess schema extends the DescribedObject schema and serves as the base class for all processes modelled and encoded in this specification. Thus, all process and system descriptions include the metadata described above plus the elements defined in this section.

"typeOf": {
  "href": "http://data.example.org/api/procedures/123",
  "uid": "urn:x-davis:station:vantagepro2",
  "title": "Davis Vantage Pro 2",
  "type": "application/sml+json"
}

"configuration": {
  "setValues": [{
    "ref": "parameters/gain",
    "value": 1.25
  }],
  "setModes": [{
    "ref": "modes/THREAT_LEVEL_MODE",
    "value": "lowThreat"
  }]
}

9.2.1.  Overview

9.2.2.  SimpleProcess

The SimpleProcess.json schema is the JSON schema implementation of the SimpleProcess UML class defined in Clause 8.3.

The SimpleProcess schema extends the AbstractProcess schema. Thus, it includes all elements described in Clause 9.1.5, AbstractProcess, plus the elements defined in this section.

The following snippet shows an example windchill computation process encoded in JSON:

{
  "type": "SimpleProcess",
  "uniqueId": "urn:x-org:process:windchill:001",
  "label": "Wind Chill Process",
  "description": "A simple process for taking temperature and wind speed and determining wind chill.",
  "inputs": [
    {
      "name": "temp",
      "type": "Quantity",
      "definition": "http://mmisw.org/ont/cf/parameter/air_temperature",
      "label": "Air Temperature",
      "uom": { "code": "Cel", "symbol": "°C" }
    },
    {
      "name": "wind",
      "type": "Quantity",
      "definition": "http://mmisw.org/ont/cf/parameter/wind_speed",
      "label": "Wind Speed",
      "uom": { "code": "km/h" }
    }
  ],
  "outputs": [
    {
      "name": "wind_chill",
      "type": "Quantity",
      "definition": "http://mmisw.org/ont/cf/parameter/wind_chill_of_air_temperature",
      "label": "Wind Chill Factor",
      "uom": { "code": "Cel", "symbol": "°C" }
    }
  ],
  "method": {
    "description": "The formula used to compute windchill is:\nTwc = 13.12 + 0.6215*Ta - 11.37*v^0.16 + 0.3965*Ta*v^0.16, where\nTwc is the wind chill index on the Celsius temperature scale;\nTa is the air temperature in degrees Celsius;\nv is the wind speed at 10 m AGL, in km/h"
  }
}

Listing

9.2.3.  Process Method

The process method provides a textual or algorithmic description of the method implemented by the process.

9.3.1.  Overview

9.3.2.  AggregateProcess

The AggregateProcess.json schema is the JSON schema implementation of the AggregateProcess UML class defined in Clause 8.4.

The snippet below shows a simple process chain example with 2 child processes and their connections.

{
  "type": "AggregateProcess",
  "uniqueId": "urn:x-ogc:process-chain:001",
  "label": "Simple Process Chain",
  "description": "A simple process chain that applies a linear transformation and clips the value to a threshold.",
  "inputs": [
    {
      "name": "valueIn",
      "type": "Quantity",
      "definition": "http://sensorml.com/ont/swe/property/DN",
      "label": "Input Value",
      "uom": { "href": "http://www.opengis.net/def/nil/OGC/0/unknown" }
    }
  ],
  "outputs": [
    {
      "name": "valueOut",
      "type": "Quantity",
      "definition": "http://sensorml.com/ont/swe/property/DN",
      "label": "Output Value",
      "uom": { "href": "http://www.opengis.net/def/nil/OGC/0/unknown" }
    }
  ],
  "components": [
    {
      "name": "scale",
      "type": "SimpleProcess",
      "label": "Linear Transform 01",
      "typeOf": {
        "href": "http://example.org/processlib/linearTransform.json",
        "uid": "urn:x-org:process:LinearTransform:v1.0",
        "title": "Linear Transform"
      },
      "configuration": {
        "setValues": [
          { "ref": "parameters/slope", "value": 2.3 },
          { "ref": "parameters/intercept", "value": 1.76 }
        ]
      }
    },
    {
      "name": "clip",
      "type": "SimpleProcess",
      "label": "Threshold Clipper 01",
      "typeOf": {
        "href": "http://example.org/processlib/thresholdClipper.json",
        "uid": "urn:x-org:process:ThresholdClipper:v1.0",
        "title": "Threshold Clip"
      },
      "configuration": {
        "setValues": [
          { "ref": "parameters/threshold", "value": 15.0 }
        ]
      }
    }
  ],
  "connections": [
    { "source": "inputs/valueIn", "destination": "components/scale/inputs/x" },
    { "source": "components/scale/outputs/y", "destination": "components/clip/inputs/valueIn" },
    { "source": "components/clip/outputs/passValue", "destination": "outputs/valueOut" }
  ]
}

Listing

9.3.3.  Components

The components property takes a ComponentList as its value, that is a list of nested AbstractProcess instances.

9.3.4.  Connections

The connections property takes a ConnectionList as its value, that is a list of nested Link instances that specify the source and destination of each connection.

9.4.1.  Overview

9.4.2.  AbstractPhysicalProcess

The schema for this abstract class is provided in AbstractPhysicalProcess.json.

It is imported by the schemas of derived classes and thus does not need to be used directly for validation.

Note that an AbstractPhysicalProcess is not a GeoJSON feature, because GeoJSON implementations do not deal well with complex nested structures, though the position of an AbstractPhysicalProcess may be encoded as GeoJSON point.

9.4.3.  PhysicalComponent

The PhysicalComponent.json schema is the JSON schema implementation of the PhysicalComponent UML class defined in Clause 8.5.

The following snippet illustrates how a simple sensor instance can be described as a physical component with a fixed geographic location encoded as a GeoJSON point as defined in IETF RFC 7946.

{
  "type": "PhysicalComponent",
  "definition": "http://www.w3.org/ns/sosa/Sensor",
  "uniqueId": "urn:x-org:systems:001",
  "label": "Outdoor Thermometer 001",
  "description": "Digital thermometer located on first floor window 1",
  "typeOf": {
    "href": "https://data.example.org/api/procedures/TP60S?f=sml",
    "title": "ThermoPro TP60S",
    "type" : "application/sml+json"
  },
  "position": {
    "type": "Point",
    "coordinates": [41.8781, -87.6298]
  }
}

Listing

9.4.4.  3D Pose

The position of a physical component can also be specified by a 3D pose object as specified by the JSON schema Pose.json.

{
  "type": "PhysicalComponent",
  "definition": "http://www.w3.org/ns/sosa/Sensor",
  "uniqueId": "urn:x-org:sensors:001",
  "label": "Sensor with GeoPose",
  "position": {
    "type": "GeoPose",
    "ltpReferenceFrame": "http://www.opengis.net/def/cs/OGC/0/NED",
    "position": {
      "lat": 47.7,
      "lon": -122.3,
      "h": 11.5
    },
    "angles": {
      "yaw": 5.946590591427664,
      "pitch": -0.4683537318018044,
      "roll": 0.0
    }
  }
}

Listing

9.5.1.  Overview

9.5.2.  PhysicalSystem

The PhysicalSystem.json schema is the JSON schema implementation of the PhysicalSystem UML class defined in Clause 8.6.

The following snippet illustrates how the specifications (datasheet) of a complete weather station can be described as a physical system. In this example, each component of the system represents one of the sensors connected to the base station:

{
  "type": "PhysicalSystem",
  "definition": "http://www.w3.org/ns/sosa/Sensor",
  "uniqueId": "urn:x-davis:station:vantagepro2",
  "label": "Davis Vantage Pro2 Weather Station",
  "description": "An industrial-grade weather station engineered to handle the harshest environments...",
  "identifiers": [ ... ],
  "classifiers": [ ... ],
  "characteristics": [ ... ],
  "capabilities": [ ... ],
  "contacts": [ ... ],
  "documents": [ ... ],
  "components": [
    {
      "type": "PhysicalComponent",
      "name": "temp_sensor",
      "definition": "http://www.w3.org/ns/sosa/Sensor",
      "label": "Temperature Sensor",
       ...
    },
    {
      "type": "PhysicalComponent",
      "name": "press_sensor",
      "definition": "http://www.w3.org/ns/sosa/Sensor",
      "label": "Pressure Sensor",
       ...
    },
    {
      "type": "PhysicalComponent",
      "name": "hum_sensor",
      "definition": "http://www.w3.org/ns/sosa/Sensor",
      "label": "Humidity Sensor",
       ...
    },
    {
      "type": "PhysicalComponent",
      "name": "wind_sensor",
      "definition": "http://www.w3.org/ns/sosa/Sensor",
      "label": "Wind Sensor",
       ...
    }
  }

Listing

Below is another example describing a specific instance of the weather station, with specifications provided above. The instance refers to the datasheet using the typeOf property, and also provides contact information for the operator, as well as a fixed location:

{
  "type": "PhysicalSystem",
  "definition": "http://www.w3.org/ns/sosa/Sensor",
  "uniqueId": "urn:x-meteofrance:stations:davis:WS00010",
  "label": "Meteo France Weather Station WS00010",
  "typeOf": {
    "href": "http://example.org/api/procedures/2ev1rrr8dkeuu",
    "uid": "urn:x-davis:station:vantagepro2",
    "type": "application/sml+json"
  },
  "contacts": [
    {
      "role": "http://sensorml.com/ont/swe/property/Operator",
      "organisationName": "Meteo France",
      "contactInfo": {
        "website": "https://www.meteo.fr",
        "phone": {
          "voice": "+33 5 61 07 80 80"
        },
        "address": {
          "deliveryPoint": "42 avenue Gaspard-Coriolis",
          "city": "TOULOUSE",
          "postalCode": "31057 Cedex 1",
          "country": "France"
        }
      }
    }
  ],
  "position": {
    "type": "Point",
    "coordinates": [
      1.35997,
      43.637788
    ]
  }
}

Listing

9.6.1.  Overview

9.6.2.  Deployment

The Deployment.json schema is the JSON schema implementation of the Deployment UML class defined in Clause 8.9.

The following snippet provides an example of a mission with three Saildrones deployed in an area encoded as a GeoJSON polygon as defined in IETF RFC 7946:

{
  "type": "Deployment",
  "definition": "http://www.w3.org/ns/ssn/Deployment",
  "uniqueId": "urn:x-saildrone:mission:2025",
  "label": "Saildrone - 2017 Arctic Mission",
  "description": "In July 2017, three saildrones were launched from Dutch Harbor, Alaska, in partnership with NOAA Research...",
  "contacts": [ ... ],
  "validTime": [
    "2017-07-17T00:00:00Z",
    "2017-09-29T00:00:00Z"
  ],
  "location": {
    "type": "Polygon",
    "coordinates": [[
      [-173.70, 53.76],
      [-173.70, 75.03],
      [-155.07, 75.03],
      [-155.07, 53.76],
      [-173.70, 53.76]
    ]]
  },
  "deployedSystems": [
    {
      "name": "SD1001",
      "system": {
        "href": "https://data.example.org/api/systems/27559?f=sml",
        "uid": "urn:x-saildrone:platforms:SD-1001",
        "title": "Saildrone SD-1001"
      }
    },
    {
      "name": "SD1002",
      "system": {
        "href": "https://data.example.org/api/systems/27560?f=sml",
        "uid": "urn:x-saildrone:platforms:SD-1002",
        "title": "Saildrone SD-1002"
      }
    },
    {
      "name": "SD1003",
      "system": {
        "href": "https://data.example.org/api/systems/27561?f=sml",
        "uid": "urn:x-saildrone:platforms:SD-1003",
        "title": "Saildrone SD-1003"
      }
    }
  ]
}

Listing

9.6.3.  DeployedSystem

The DeployedSystem schema is the JSON schema implementation of the DeployedSystem UML class defined in Clause 8.9, Requirements Class: Deployment.

The schema allows associating a configuration to a given deployed system or platform.

9.7.1.  Overview

9.7.2.  DerivedProperty

The DerivedProperty.json schema is the JSON schema implementation of the DerivedProperty UML class defined in Clause 8.10.

The following snippets provide examples of domain specific derived properties:

{
  "description": "Mechanical power produced by the engine",
  "baseProperty": "http://qudt.org/vocab/quantitykind/Power",
  "objectType": "http://dbpedia.org/resource/Engine"
}

{
  "description": "Hourly average of the CPU temperature",
  "baseProperty": "http://qudt.org/vocab/quantitykind/Temperature",
  "objectType": "http://dbpedia.org/resource/Central_processing_unit",
  "statistic": "http://sensorml.com/ont/x-stats/HourlyMean"
}

Listing