NGSI-LD and WoT: complementary open standards that may converge to bring a standard for digital twin data management�

Juanjo Hierro

​

Chairman, FIWARE Technical Steering Committee

juanjose.hierro@gmail.com

Digital Twins as basis for the architecture of smart vertical solutions, smart organizations and data spaces in multiple sectors

• Any architecture of a smart solution should gravitate around a “digital twin representation” of the real world (also referred as “context representation”) which is constantly keep up to date based on data from different sources and is constantly analyzed and processed in order to automate processes or bring support to smart decisions
• Creating a digital twin representation of the real world you can implement a “system of systems” approach to solve:
• How the architecture of smart vertical solutions (e.g., waste management for cities) is architected
• How systems within an organization (e.g., a city, a farm) can be integrated breaking the information silos
• How systems from different organizations may exchange information within data spaces they build

​

​

1

Digital Twins: an approach for integration at multiple levels following a system of systems approach

2

Digital Twin representation

Digital Twin representation

Architecting �Smart Solutions

Integrating systems and data within cities

Sharing Data across organizations�(data spaces)

3rd systems

sensors

Smart Solution

System 3

System 4

System 1

System 2

Smart City

Smart Building

Smart Logistics

Smart Grid

Digital Twin representation

What are we referring to as Digital Twin?

• Digital Twin = Digital “replica” of an asset (physical or not)
• Characterized by attributes which may change over time (or not)
• Properties
• Relationships 🡪 Linked Data
• Typically have a location (but it is not a must requirement)
• May respond to commands/actions
• (digital representation of) Context = Digital Twins Collection
• Cornerstone for the development of interoperable and �replicable (portable) Smart Solutions:
• Standard API for getting access to Digital Twin data (context)
• Common Data Models associated to Digital Twin classes
• FIWARE has driven standardization+adoption:
• NGSI: NGSIv2 ⇒ ETSI NGSI-LD API
• Smart Data Models initiative (900+ data models)
• W3C Web of Things (WoT) has addressed the definition of standards for managing things data

​

​

​

3

WoT:Things and NGSI-LD:Entities

• A Thing in the WoT may map well to an Entity in NGSI-LD - both would match the concept of digital twin
• However, it should be noted that an Entity in NGSI-LD may represent digital entities that do not map to physical objects - some examples:
• a claim ticket
• a task within a process
• In WoT specifications, it is stated that a Thing is an abstraction of a physical or virtual entity - we assume this matches the above concept of digital entity
• In any case, it should not be an issue to extend the definition of Things in the WoT to also cover such kind of “digital” entities - it may require to adapt some of the existing W3C specifications but it shouldn’t be a big deal

4

A Thing Model Description

5

{

"@context": "https://www.w3.org/2022/wot/td/v1.1",� "@type": "tm:ThingModel",

"title": "Coffee Machine",

…

"properties": {

"status": {

"description": "current status of the coffee machine (on|off)",� "type": "string",

},

"full": {

"description": "indicates whether container is full of capsules",� "type": "boolean"

"readonly": true

}

​

},

"actions": {

"self-clean": {� "description": "Activates self-cleaning program"

}

},

"events": {

"warning": {

"description": "Coffee Machines raises some warning",

"data": {"type": "string"},

}]

}

}

}

A Thing Description

6

{

"@context": "https://www.w3.org/2022/wot/td/v1.1",

"id": "urn:uuid:0804d572-cce8-422a-bb7c-4412fcd56f06",

"title": "MyCoffeeMachine",

…

"properties": {

"status": {

"description": "current status of the coffee machine (on|off)",� "type": "string",

"forms": [{"href": "https://myCoffeMachine.example.com/status"}]

},

…

},

"actions": {

"self-clean": {� "description": "Activates self-cleaning program"

"forms": [{"href": "https://myCoffeMachine.example.com/self-clean"}]

}

},

"events": {

"warning": {

"description": "Coffee Machines raises some warning",

"data": {"type": "string"},

"forms": [{

"href": "https://myCoffeeMachine.example.com/oh",

"subprotocol": "sse"

}]

}

}

}

URN identifying a particular Thing

URL with which issuing an HTTP GET will allow to get the value of the “status” property (can we assume that an HTTP POST would allow to modify it?)

indicates how to access to the value of the “status” property for the referred thing

indicates how to trigger the “toggle” action

indicates how to subscribe to “overheating” events through a longpoll protocol on the specified endpoint

Compatibility of NGSI-LD with Thing Models/Descriptions

• WoT may specify what would be the “default” Thing Description derived from a Thing Model
• This default Thing Description would make use of NGSI-LD as form to access properties, trigger actions or subscribe to events
• It just requires to come with a convention about how to determine or discover what will be the NGSI-LD endpoint serving instances (things) of a Thing Model
• Still, developers can overwrite the NGSI-LD default forms for the default Thing Description of a concrete Thing
• How to implement actions in NGSI-LD has to be specified - but that can be addressed in synergy with ongoing work item at ETSI ISG CIM
• Summary: WoT WG at W3C and ETSI CIM ISG can collaborate in both specifications:
• default TD derived from a Thing Model
• how to trigger actions in NGSI-LD

7

{

"@context": "https://www.w3.org/2022/wot/td/v1.1",

"id": "urn:uuid:0804d572-cce8-422a-bb7c-4412fcd56f06",

"title": "MyCoffeeMachine",

…

"properties": {

"status": {

"description": "current status of the coffee machine (on|off)",� "type": "string",

"forms": [{"href": <valid NGSI-LD form>}]

}

},

"actions": {

"self-clean": {� "description": "Activates self-cleaning program"

"forms": [{"href": <valid NGSI-LD form>}]

}

},

"events": {

"warning": {

"description": "Coffee Machines raises some warning",

"data": {"type": "string"},

"forms": [{

"href": "<valid NGSI-LD form>",

"subprotocol": "sse"

}]

}

}

}

Compatibility of NGSI-LD with Thing Descriptions: properties

• Default forms based on NGSI-LD operations can be specified for accessing properties
• There are different ways, but we may agree on one
• Only point that needs to be “solved” is where/how to specify the endpoint through which NGSI-LD operations on a given Thing will be served. Proposal:
• through an optional element that is part of the Thing Model template
• allow to overwrite it in any Thing Description through some new element of the description to be specified (e.g., “agent endpoint”)

8

{

"@context": "https://www.w3.org/2022/wot/td/v1.1",

"id": "urn:uuid:0804d572-cce8-422a-bb7c-4412fcd56f06",

"title": "MyCoffeeMachine",

…

"properties": {

"status": {

"description": "current status of the coffee machine (on|off)",� "type": "string",

"forms": [{"href": “https://MyContext.com/ngsi-ld/v1/entities/� urn:uuid:0804d572-cce8-422a-bb7c-4412fcd56f06/� attrs/status”}]

},

"full": {

"description": "indicates whether container is full of capsules",� "type": "boolean"

"readonly": true

"forms": [{"href": “https://MyContext.com/ngsi-ld/v1/entities/� urn:uuid:0804d572-cce8-422a-bb7c-4412fcd56f06/� attrs/full”}]

}

​

},�}

​

endpoint where NGSI-LD requests would be served may be connected to the specific Thing or configured for all instances of several Thing Models (recommended)

Default Thing Description derived from Thing Model: properties

• The “server endpoint” element could be useful even for scenarios where the Thing Description overwrittes the default one based on NGSI-LD.

9

{

"@context": "https://www.w3.org/2022/wot/td/v1.1",� "@type": "tm:ThingModel",

"title": "Coffee Machine",� “server endpoint”: “MyContext.com”

…

"properties": {

"status": {

"description": "current status (on|off)”)",� "type": "string",

},

"full": {

"description": "true if full of capsules",� "type": "boolean"

"readonly": true

}

…

​

}

{

"@context": "https://www.w3.org/2022/wot/td/v1.1",

"id": "urn:uuid:0804d572-cce8-422a-bb7c-4412fcd56f06",

"title": "MyCoffeeMachine",

…

"properties": {

"status": {

"description": "current status of the coffee machine (on|off)",� "type": "string",

"forms": [{"href": “https://MyContext.com/ngsi-ld/v1/entities/� urn:uuid:0804d572-cce8-422a-bb7c-4412fcd56f06/� attrs/status”}]

},

"full": {

"description": "indicates whether container is full of capsules",� "type": "boolean"

"readonly": true

"forms": [{"href": “https://MyContext.com/ngsi-ld/v1/entities/� urn:uuid:0804d572-cce8-422a-bb7c-4412fcd56f06/� attrs/full”}]

}

​

},�}

​

Compatibility of NGSI-LD with Thing Descriptions: events

​

• Regarding events, it would be important to clarify how events linked to changes on properties or conditions on properties, at the time we don’t see how you may define these kind of events (for which there may no need to specify the “data” field since the type of the events would match the type of the given property or the entire entity
• For events that are not related to properties, we may need to come with a solution - one approach may consist in that those kind of events are considered like if there exist a NGSI-LD property whose type is that defined in the “data” field and a subscription exists on changes of that property
• In any case, we don’t see this as something for which a solution cannot be found

10

{

"@context": "https://www.w3.org/2022/wot/td/v1.1",

"id": "urn:uuid:0804d572-cce8-422a-bb7c-4412fcd56f06",

"title": "MyCoffeeMachine",

…

“events": {

"warning": {

"description": "Coffee Machines raises some warning",

"data": {"type": "string"},

"forms": [{

"href": "<valid NGSI-LD form>",

"subprotocol": "sse"

}]

}

}

}

Default Thing Description derived from Thing Model: events

11

{

"@context": "https://www.w3.org/2022/wot/td/v1.1",� "@type": "tm:ThingModel",

"title": "Coffee Machine",� “server endpoint”: “MyContext.com”

…� "properties": {

"status": {

"description": "current status(on|off)",� "type": "string",

},

"full": {

"description": "true if full of capsules",� "type": "boolean"

"readonly": true

}

​

​

"events": {

"warning": {

"description": "Coffee Machines raises some warning",

"data": {"type": "string"}

}� "full event": {

"description": "Sends an event when full of capsules",� “property”: “full”

}

}

}

“warning” would map into a property of type “string” and users would be able to subscribe to the “MyContext.com” endpoint to subscribe to updates on that property

I can subscribe to updates on properties if the “data” element is not specified in the Thing Model but a “property” is designed instead. Here, the “full event” is triggered when an update occurs in property “full”

Compatibility of NGSI-LD with Thing Descriptions

• One advantage of adopting NGSI-LD as default “form” to bring access to things that are instances of Thing Model templates is that WoT may specify the means how to perform very powerful operations that affect multiple things. As an example:
• how to query the value of one attribute shared by multiple things
• how to subscribe to events notified on changes of attributes by things of the same “class” (i.e., instances of the same Thing Model)
• …

12

Summary

• WoT and NGSI-LD models look compatible → this brings an opportunity to specify how they can work together
• NGSI-LD can be adopted as default “form” how to interact with Things (access properties, trigger actions, subscribe to events) whose description of actions, properties, events have been specified using the Things Model language:
• We just need to specify how those default forms for NGSI-LD would look like
• Still implementors may overwrite (or add to) this default form alternative forms
• Specifying how NGSI-LD will work in a system where Things/Entities are defined using Things Models would bring additional value since it brings the opportunity to operate on collections of things.
• Compatibility is feasible also at the level of scripting API

13

Next steps

• FIWARE team involved in TC Data will work on coming with first ideas how NGSI-LD could be extended to support invocation of actions on entities - target goal: come with draft proposal by end of September
• In parallel, work towards definition of default forms based on NGSI-LD that would apply for things descriptions that would derive from Things Model language - starting with properties, then events first
• Try to develop PoC towards event in WoT Plugfest in November 9-11 in Japan
• Challenge: availability of resources to work on PoC regarding FIWARE team

14

Sounds nice? - Contact us!

http://fiware.org

Follow @FIWARE on Twitter

RESTful API: ETSI NGSI-LD

• NGSI-LD is a simple yet powerful REST API
• Simple: simple operations are rather simple, what you would expect in a RESTful API
• Entity types, entities, attributes have a path
• You perform standard GET, POST, PUT, PATCH, DELETE operations
• Yet powerful: powerful operations supported
• Geo-queries
• Subscription / Notification
• Pull/Push styles for gathering data
• Multiple data ”renderings” (key value, normalized, GeoJSON)
• Temporal operations
• Federation mechanisms

16

Smart Home

• location
• address
• installed PV
• energy consumption

NGSI-LD

Summary

• A system of systems approach based on digital twins is rather suitable for addressing challenges of integration at different levels:
• design of the architecture of vertical smart solutions
• integration of systems within a smart organization
• integration of systems and exchange of data within data spaces
• Vision and design principles are important but we need a concrete open industry standard specification
• We shall not re-invent the wheel: leverage relevant open industry standards, ideally backed with open source implementations

​

​

17