MIM1 - Context Information

OASC MIM1: Context Information

Description

Context Information is the information that is necessary for systems to be more adaptable to different contexts within the real world.

  • Examples:

    • Traffic Management: MIM 1 can aggregate and standardise data from various sensors (traffic cameras, weather stations, vehicle GPS systems) into a unified format. This enables traffic management systems to automatically adjust signal timings and offer route recommendations to drivers based on real-time traffic conditions, weather, and events, thus reducing congestion and enhancing traffic flow.

    • Energy Management: MIM 1 can facilitate the integration of sensor data across public buildings to dynamically adjust heating, cooling, and lighting based on occupancy and weather conditions, significantly reducing energy waste and operational costs.

    • Public Safety: By integrating and standardising data from multiple sources, including CCTV and emergency alerts, MIM 1 enhances real-time response capabilities, enabling faster deployment of emergency services during critical events, thus improving public safety and resilience.

  • Literature:

    • Dey et al. (2001) define Context as "any information that can be used to characterize the situation of an entity."

    • Rocha et al. (2012) defines Context management a dynamic computer process that uses 'subjects' of data in one application, to point to data resident in a separate application also containing the same subject.

Objectives

  • To enable context information from different systems within or across organisations, such as cities or communities, originating from heterogeneous sources, to be brought together using a Web based API.

  • To enable comprehensive and integrated use, reuse and sharing of data as well as management of context information

  • To turn data into a strategic resource

Capabilities and Requirements

C1: Applications are able to access data from different sources (such as cities, communities and vertical solutions).

C2: Applications are able to use both current and historical data, use geospatial querying and be automatically updated when the source data changes.

C3: Applications can discover and retrieve data relevant to their context from a variety of sources

C4: Applications can retreive a subset of data from a larger data set

Mechanisms

  1. ETSI NGSI-LD

ETSI NGSI-LD Reference Implementations

The below table lists reference implementations of the NGSI standard known to OASC. If you are aware of other reference implementations please share them in the comments section.

Please note that this list purely serves an informational purpose. OASC does not guarantee that the listed reference implementations are operational with local technical environments and OASC cannot be held responsible for the listed implementations.

We are updating this list

  1. ISO 19156 Observations, Measurements, and Samples

This Mechanism needs further refinement

The Observations, Measurements, and Samples standard (OMS), jointly prepared and published by the Open Geospatial Consortium and ISO/TC 211 as OGC Abstract Specification Topic 20 (OGC 20-082r4) and ISO 19156:2023, defines a conceptual schema for observations, for features involved in the observation process, and for features involved in sampling when making observations. Models support the exchange of information describing observation acts and their results, both within and between different scientific and technical communities. The OGC SensorThings API Standard is a ODATA RESTful API implementation of the OMS Abstract Specification (ISO 19156-2023).

SensorThings API (OGC 18-088 (v1.1) and ITU-T REC Y-4473) uses the IoT Reference Model adapted from [ITU-T Y.2060] and follows the ITU-T definition: “an object of the physical world (physical things) or the information world (virtual things) that is capable of being identified and integrated into communication networks”. OGC seeks to align with other initiatives likes the W3C Web of Things.

Development of the standards takes place on GitHub.

OGC SensorThings API Reference Implementations

The below table lists (reference) implementations of the SensorThings API standard known to OASC. If you are aware of other reference implementations please share them in the comments section.

Please note that this list purely serves an informational purpose. OASC does not guarantee that the listed (reference) implementations are operational with local technical environments and OASC cannot be held responsible for the listed implementations.

OGC SensorThings API Open Source Implementations

OGC SensorThings API Implementations

  1. LDES

Compliance and Conformance

  1. ETSI NGSI-LD ETSI organized a Testing Task Force (TTF) to create a Testing toolkit to validate context brokers towards the NGSI-LD specification. EGM, Ubiwhere and OASC collaborated on this task force to create this toolkit. The result was a set of clear defined test descriptions, test purposes and executable robot scripts. All this information can be found on the ETSI CIM Website https://www.etsi.org/comittee/cim.

  2. SensorThings API The SensorThings API Specification includes conformance classes as part of the specification, that are used as part of the Test Suite. (Example: https://docs.ogc.org/is/18-088/18-088.html#datastream) The OGC Provides a Conformance Test Suite that verifies conformance with SensorThings API (STA) 1.0. https://cite.opengeospatial.org/teamengine/about/sta10/1.0/site/ and https://github.com/opengeospatial/ets-sta10

  3. LDES Flanders re-used the Joinup Interoperability Testbed (ITB) to create compliance tests for LDES Server instances. It defined multiple compliance tests which can be used by organisations that create their own LDES Server implementation to check compliancy against the LDES spec. Code can be found here: https://github.com/Informatievlaanderen/VSDS-Testbed