Linked Data Vocabulary For Describing Data Models
- A standard vocabulary for describing data models is needed to enable servers from different vendors or open source projects to interoperably instantiate scriptable objects for IoT services.
This work item will specify a data modelling vocabulary for describing things in terms of events, properties and actions, and links to domain models and protocol specific API descriptions. This work item will include provision for late bound data types, re-use of data type definitions, and labelled opaque data types for data to be handed on to entities that understand it. This vocabulary will be designed to supplement the RDF core datatypes, including enumerations and numeric ranges. To allow for implementation on constrained devices, a limited set of core data types will need to be selected.
Background
The starting point is the idea of scriptable objects as "things" standing for physical or abstract entities. The approach is based upon the fundamentals of Web architecture:
- URIs for identifying things
- A variety of protocols for accessing things, since no one protocol will be appropriate in all contexts
- Linked Data for describing things as a basis for interoperability and discovery, playing an analogous role to HTML for web pages
URIs can be used to access machine interpretable descriptions of things. These descriptions enable the automatic generation of scriptable objects whose events, properties and actions correspond to those of the thing the object stands for. An object on one server can act as a proxy for an object on another server. Web developers are shielded from the implementation details of how objects are coupled, allowing system designers to choose the transport protocols best suited to the given context. Servers can be provided at a wide range of scales from microcontrollers to cloud-based server farms.
The diagram shows a thing on server A that acts as a proxy for a thing on server B which is coupled to a sensor and actuator. The proxy on server A could be set up by a script on that server, or by a script on server B. The latter is useful when server A is on the public Internet and server B is behind a firewall, and you want to provide public access to the thing from server A.
Web page scripts can create local proxies for things on servers, subject to the protocols supported by Web browsers and the single origin security policy. There are many possible applications across a wide range of domains, e.g. homes, offices, lifecare, cities, electrical grids, retail and manufacturing.
See Also
Further information is available at: