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).

C1 requirements:

R1: Context can be managed through the Web

R2: Information from all sources should use the same concepts, so called data information models

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

C2 requirements:

R3: The web based API shall support retrieval of current data

R4: The web based API should support retrieval of historical data when applicable

R5: The web based API should support geospatial querying when applicable

R6: The web based API should support subscription to changes when applicable

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

C3 requirements:

R7: Relevant data sources to any required context (such as location and/or time period) should be discoverable and retrievable according to their context

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

C4 requirements:

R8: Specific subsets of data relevant to the context should be retrievable from within larger data sets and size limits can be set

Mechanisms

  1. ETSI NGSI-LD

Requirements

Mechanism NGSI-LD

R1: Context can be managed through the Web

NGSI-LD API is a uniform context management API that is provided by different context broker applications. It allows management of Context through a REST API.

R2: Information from all sources should use the same concepts, so called data information models

This is provided through the common NGSI-LD information model, which is the meta model on which the API is based. The (NGSI-LD) world consists of Entities that can have Properties, Relationships etc.

R3: The web based API should support retrieval of latest data

From an NGSI-LD terminology perspective you would retrieve one or more Entities with their Attributes. You can restrict the Attributes to be returned as part of the Entity to those provided in “attrs”, which is a URI parameter. You can discover all Entities based on their characteristics by specifying their type.

The API call to use is GET /entities

R4: The web based API should support retrieval of historical data

Historical data is stored in the Context Broker and accessible in a similar way as the latest data can be retrieved.

The API call to use is GET /entities/temporal

R5: The web based API should support geospatial querying

Entities and Context Sources have location properties in GeoJSON. Entities and Context Sources can be geoqueried by specifying a georel relation such as near, within,...

The API call to use is GET /entities or GET /CSourceRegistrations

R6: The web based API should support subscription to changes

This can be done by posting a Subscription object. The API call to use is: POST /subscriptions/

R7: Relevant data sources to any required context (at least location and time period) should be discoverable and retrievable according to their context

This can be done using a type-query The API call to use is GET /CSourceRegistrations

R8: Specific subsets of data relevant to the context should be retrievable from within larger data sets and with default limits and page sizes

NGSI-LD is agnostic to specific pagination mechanisms but requires NGSI-LD Systems to support and define default limits and page sizes

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.

Provider

Name

Link

FIWARE

Orion Context Broker

https://github.com/FIWARE/context.Orion-LD

NEC

Scorpio Broker

https://github.com/ScorpioBroker/ScorpioBroker

Sensinov

Djane.io

https://github.com/sensinov/djane

EGM

Stellio Broker

https://github.com/stellio-hub/stellio-context-broker

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.

Requirements

Mechanism SensorThings API

R1: Context can be managed through the Web

The SensorThings API provides an ODATA RESTful API that provides all access (Create Read Update Delete - CRUD) to the observations and all context elements.

R2: Information from all sources should use the same concepts, so called data information models

SensorThings API is implementation of the Abstract ISO 19156 OMS model. OMS defines all concepts and assures they are consistent.

R3: The web based API should support retrieval of latest data

The API provides access (read) to the latest (current) information of all entities in the context. Example GET /v1.0/Observations

GET /v1.0/Things GET /v1.0/Sensors GET /v1.0/Datastreams(1)/Observations ...

R4: The web based API should support retrieval of historical data

Multiple elements in the context have timestamps (all can be used to retrieve historical information): HistoricalLocations of the Thing, and Observations (PhenomenonTime, ResultTime and ValidTime) Example: GET /v1.0/Observations?$filter=phenomenonTime lt '2016-11-24T14:37:01.000Z' GET /Things?$expand=Datastreams/Observations/FeatureOfInterest&$filter=Datastreams/Observations/FeatureOfInterest/name eq 'Rue du Luxembourg 19-21 1000 Brussels' and Datastreams/Observations/phenomenonTime ge 2017-01-01T00:00:00.000Z and Datastreams/Observations/phenomenonTime le 2017-03-01T00:00:00.000Z GET /v1.0/HistoricalLocations?$filter=time lt '2016-11-24T14:37:01.000Z'

R5: The web based API should support geospatial querying

Geospatial querying in SensorThings API defines nine geospatial functions based on the spatial relationship between two geometry objects. The spatial relationship functions are defined in the ISO19125 Simple Feature Access specification. Example:

GET /v1.0/Locations?$filter=st_equals(location,geography'POINT(4.3679 50.84)')

R6: The web based API should support subscription to changes

SensorThings API provides publish and subscribe capabilities using MQTT. Example: Subscribe to v1.1/Datastreams(1)/Observations

R7: Relevant data sources to any required context (at least location and time period) should be discoverable and retrievable according to their context

Context information (incl external data models) (provided by eg RDF links in the Sensor information) can be found and retrieved using semantic inferencing.

R8: Specific subsets of data relevant to the context should be retrievable from within larger data sets

SensorThings query options can be categorized to two different groups. The first group specifies the properties to be returned by the request. $expand and $select are query options of this group. The second group is limiting, filtering, or re-ordering the request results. This group contains $orderby, $top, $skip, $count, and $filter. Example: /v1.0/Datastreams(id)?$expand=Observations,ObservedProperty /v1.0/Observations?$top=3&$orderby=phenomenonTime desc

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.

Provider

Name

Link

Fraunhofer OSB

FROST

https://github.com/FraunhoferIOSB/FROST-Server

OGC SensorThings API Open Source Implementations

Provider

Name

Link

Geodan

GOST

https://github.com/gost/server

52North

SensorWeb-Server-Sta

https://github.com/52North/sensorweb-server-sta

OGC SensorThings API Implementations

Provider

Name

Link

SensorUp

SensorUp SensorThings API v1.0

https://www.sensorup.com

  1. LDES

Requirements

Mechanism LDES

R1: Context can be managed through the Web

The Linked Data Event Streams (LDES — https://w3id.org/ldes/specification) specification uses HTTP and RDF as its web based interface for the re-use of domain models, the definition of the schema (SHACL), API interface descriptions (TREE hypermedia — https://w3id.org/tree/specification), context and instance data. A server that publishes LDESes can be managed in several ways. Flanders makes a reference implementation available. The documentation can be found here: https://informatievlaanderen.github.io/VSDS-Tech-Docs/introduction/LDES_server.

R2: Information from all sources should use the same concepts, so called data information models

Each LDES contains information on how to the member objects are structured based on well-defined SHACL shapes. Across the Web, it promotes the re-use of Linked Data vocabularies.

R3: The web based API should support retrieval of latest data

An LDES is an append-only log of members, and thus by-default a server keeps the full history. On top of a view, it may document a retention policy in which the server indicates data will be removed from the server after a certain period of time, or amount of members. Third parties should read retention policies to understand what subset of the data is retrievable. They may decide based on them to archive these members. The default view that should be available on top of an LDES is the Event Source. The Event Source allows all user agents interested in this dataset to replicate the history, but also to stay in-sync. LDES positions that the “latest data” is relative to the view you want to create. E.g., if you are interested in creating an overview of cancelled trains, then you will process an event source differently. LDES supports multiple data governance strategies, such as using version objects (can be indicate using the ldes:versionOfPath) or by describing an event log re-using e.g., ActivityStreams2.0

R4: The web based API should support retrieval of historical data

See R3: LDES provides historical and live data in the same interface.

R5: The web based API should support geospatial querying

Geospatial functionality can be achieved in two ways:

  1. Either you use a LDES to Service pipeline in which you replicate the full dataset into a geospatial software of choice.

  2. You publish a geospatially fragmented Linked Data Event Streams (see https://informatievlaanderen.github.io/VSDS-LDESServer4J/configuration/fragmentations/geospatial)

In 2, by publishing a geospatial fragmentation you allow a query agent to select the right fragments just in time.

R6: The web based API should support subscription to changes

The LDES event source is a specialized view for replication and synchronization in the same interface as R4 and R5. Using an LDES client, an agent can stay up to date with the latest changes.

R7: Relevant data sources to any required context (at least location and time period) should be discoverable and retrievable according to their context

Data discovery works via DCAT-AP data portals that indicate that their dcat:Dataset is also an ldes:EventStream, and that their dcat:DataService is also a tree:ViewDescription. On an ldes:EventStream, there will be a SHACL shape defined that shows what properties are being used within the members. Using that, you can select the properties of interest and use that dataset in other contexts as well. The ldes:EventStream also has two properties:

  • ldes:timestampPath points at a property in the member that will cater for the chronological order (e.g., dcterms:modified)

  • ldes:versionOfPath will point at the property that is used to indicate what this member is a version of (e.g., dcterms:isVersionOf). This allows you to also create a latest state if your dataset consists of version objects

On top of a tree:ViewDescription a retention policy can be described, or can contain hints for query agents whether these views are specialized towards a certain use case.

R8: Specific subsets of data relevant to the context should be retrievable from within larger data sets

LDES is built on top of the TREE hypermedia specification that allows to fragment event streams in search trees. Such search trees then allow client to specifically stay in-sync, or replicate the full history, of a subset. It is up to the server to decide what granularity and type of fragmentations to publish.

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

NextNotes