You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A generic use case for semantic interoperability is enabling smart applications to adapt to the variations in capabilities and APIs for devices produced by different vendors, or even to different models of devices produced by the same vendor. This issue provides a use case for this.
In the Web of things, the device vendor or perhaps a third party can provide a server application that can be installed on an application server/IoT gateway to provide a thing or things on behalf of the device for use by client applications. Following core Web architecture, each thing is identified by a URI, metadata formats like JSON-LD can be used to describe things, and Web protocols can be used for access to thing descriptions and for interacting with things.
Consider a smart application that acts as a client for remotely controlling a broad category of devices, e.g. lights, washing machines, air conditioners and other smart home devices. The thing description describes things as objects with properties, actions and events. The object API could vary across devices, and we can't assume that devices from different vendors implement the same capability using the same object model, and moreover different devices may present variations in their capabilities. How does a mobile or web application adapt its user interface and logic to this?
The answer is for the application to browse the semantic models for the capabilities. One thing for a light could offer a boolean property named "power" for simple on/off control, whilst another could offer numeric properties for setting brightness, saturation and hue, and a third thing could support control via red, green and blue properties. These can be related at the semantic level. The thing description might just describe the interaction model, i.e. the properties, actions and events, with links to the semantic model that applications will need to follow. The interaction model could be represented as JSON, whilst the semantic models are represented as Linked Data in the Turtle format. The application would use a library to download and manipulate Linked Data Graphs.
Life is easy if vendors use the same vocabulary for their semantic descriptions. However, for vocabularies developed by different communities, this will often not be the case. These raises the question of how to reason across different vocabularies. One approach is to define an upper ontology as a more fundamental (i.e. abstract) description, and to then define how specific vocabularies are related to that. This is complicated especially in respect to the kinds of reasoning that applications need to carry out. Another approach is to define mappings between vocabularies at the same level of abstraction. Here concepts in different vocabularies may be treated as equivalent only in certain contexts, thus requiring conditional mapping rules.
If people are interested, the above could be extended into concrete examples.
The text was updated successfully, but these errors were encountered:
A generic use case for semantic interoperability is enabling smart applications to adapt to the variations in capabilities and APIs for devices produced by different vendors, or even to different models of devices produced by the same vendor. This issue provides a use case for this.
In the Web of things, the device vendor or perhaps a third party can provide a server application that can be installed on an application server/IoT gateway to provide a thing or things on behalf of the device for use by client applications. Following core Web architecture, each thing is identified by a URI, metadata formats like JSON-LD can be used to describe things, and Web protocols can be used for access to thing descriptions and for interacting with things.
Consider a smart application that acts as a client for remotely controlling a broad category of devices, e.g. lights, washing machines, air conditioners and other smart home devices. The thing description describes things as objects with properties, actions and events. The object API could vary across devices, and we can't assume that devices from different vendors implement the same capability using the same object model, and moreover different devices may present variations in their capabilities. How does a mobile or web application adapt its user interface and logic to this?
The answer is for the application to browse the semantic models for the capabilities. One thing for a light could offer a boolean property named "power" for simple on/off control, whilst another could offer numeric properties for setting brightness, saturation and hue, and a third thing could support control via red, green and blue properties. These can be related at the semantic level. The thing description might just describe the interaction model, i.e. the properties, actions and events, with links to the semantic model that applications will need to follow. The interaction model could be represented as JSON, whilst the semantic models are represented as Linked Data in the Turtle format. The application would use a library to download and manipulate Linked Data Graphs.
Life is easy if vendors use the same vocabulary for their semantic descriptions. However, for vocabularies developed by different communities, this will often not be the case. These raises the question of how to reason across different vocabularies. One approach is to define an upper ontology as a more fundamental (i.e. abstract) description, and to then define how specific vocabularies are related to that. This is complicated especially in respect to the kinds of reasoning that applications need to carry out. Another approach is to define mappings between vocabularies at the same level of abstraction. Here concepts in different vocabularies may be treated as equivalent only in certain contexts, thus requiring conditional mapping rules.
If people are interested, the above could be extended into concrete examples.
The text was updated successfully, but these errors were encountered: