IoT and Schema.org: Getting Started

STATUS: Work in progress document targeting schema.org v3.2 release.

Editor: Dan Brickley <danbri@google.com>

Contributors (alphabetically): Yuvraj Agarwal, Laura Daniele, Joshua Gluck, R.V. Guha, Ted Hardie, Jason Koh, Ari Keränen, Michael Koster,Dave Raggett, Max Senges

This short document introduces a proposal for the schema.org community to begin work in the "Internet of Things" (IoT) area, building on schema.org's existing success to provide an approach to semantic interoperability that bridges IoT and non-IoT applications. It outlines some possible application areas where schema.org-oriented structured data vocabularies may be useful, gives some examples of related schemas and related standards efforts, before proposing some practical steps for collaborative work.

The case for IoT + Schema.org

The Internet of Things (henceforth, IoT) field covers a huge range of scenarios in which connected devices, sensors, beacons and other electronic components exchange various kinds of data using Internet, Web and other (e.g. Bluetooth) technology. Much of this structured data describes real world entities, their properties and relationships, in a manner that could benefit from the use of widely adopted, application independent, non-proprietary schemas such as those developed at schema.org for the Web. Adopting and improving schema.org's vocabularies for IoT can reduce needless duplication and focus attention on innovation rather than replication. Schema.org's approach is open, organic and community based, and is supported by a technical design that includes several extensibility mechanisms designed to support decentralization without encouraging fragmentation.

The view from schema.org

This section is oriented towards readers familiar with schema.org and its mechanisms.

Typical schema.org "extension proposals" usually suggest a handful of new types of things to add to schema.org's definitions, as well as properties typical of those kinds of objects. This proposal is quite different, it is simply to begin a collaboration in these areas. Instead of proposing a specific set of schema definitions, we propose a broader set of collaborations whose outcomes could include activities such as:

Development of mappings between diverse application-oriented, platform-oriented, and schema.org schemas, via a shared datamodel.
Evolution and documentation of a common data-model (triples/graphs e.g. RDF) that can capture diverse schemas.
Distributed publication of "external extension" schemas that build on the schema.org core and a shared datamodel (e.g. see http://gs1.org/voc/).
Hosted Extensions - published as part of the schema.org site using subdomains, for example see http://auto.schema.org/ or http://health-lifesci.schema.org/
Additions and changes to core schema.org terms (e.g. hypothetical addition of a basic type like "Device", or improvements around measurements, actions and events)
Collaboration on improved examples, documentation, sample code etc. relating to IoT.

For simplicity we will refer to all of these collaboration possibilities as "IoT + schema.org" or "iot.schema.org", and suggest the establishment of a "hosted schema.org extension" website at that subdomain following the existing pattern (i.e. alongside bib.schema.org, auto.schema.org, health-lifesci.schema.org, etc.). Given the nature of IoT, we expect iot.schema.org to serve as an entry point to a diverse set of activities, as well as providing a home for any IoT-specific vocabulary that emerges from collaborations. We expect that many IoT-related schema.org scenarios will draw upon vocabulary that may be more appropriate for the schema.org core, or for domain-oriented areas such as health-lifesci.schema.org.

The view from IoT

This section is oriented towards readers unfamiliar with schema.org and its mechanisms.

Readers unfamiliar with schema.org are encouraged to read the recent ACM Magazine overview (http://queue.acm.org/detail.cfm?id=2857276) for a more detailed overview of the project. We provide here a very brief overview.

Schema.org started 5 years ago by providing a vendor-neutral community developed vocabulary for structured data on the Web. Today, Schema.org markup is very widely used, with tens of millions of mainstream Web sites routinely including schema.org markup within page content. Schema.org has proved extremely beneficial to Web publishers because it improves the presentation of their content within search engines (or their mail messages within e.g. google now / gmail, Cortana etc).

Schema.org can extend its vocabulary to IoT devices and services in the same vendor-neutral, community-developed fashion. Bringing schema.org to the IoT environment raises a number of considerations beyond simple modeling tasks. We begin with a recap of the motivations for using schema.org with IoT. Some of the benefits of IoT applications using schema.org vocabulary for connected devices and services are that they build on a large existing base, that they do not draw an unsustainable distinction between "IoT" and "non-IoT" scenarios/applications, and that they help decouple data structures from the tools, products and applications that use the data.

Use cases and Scenarios

We do not here provide an exhaustive survey of indicative IoT scenarios for which schema.org may be relevant. Instead we give a short selection of situations where the schema.org project could contribute in an IoT context.

User data portability
- E.g. sensor-based data from consumer devices such as smart scales. Schema.org has existing vocabulary ("Dataset" and nearby) for describing the general characteristics of datasets, and ongoing collaboration (e.g. health-lifesci.schema.org) for fine-grained schema detail in specific domains. These should help improve discovery and use of data regardless of the specific hardware or branded product that generated the data. For example, personal healthcare applications should not need to care which weighing scales a user has. Using vendor-independent schemas (such as schema.org's) can help decouple these concerns.
Beacons and the description of the physical environment
- Initiatives such as physical-web.org are increasingly being used to attach unique identifiers, often Web URIs, to real world objects such as local businesses, bus stops, museum artifacts etc. Schema.org already contains a lot of relevant and widely used vocabulary, e.g. for describing a local business, its opening hours etc., as well as restaurants, menus, food preferences. Similarly, for various aspects of travel notions such as https://schema.org/BusStop are available. For example, PhysicalWeb beacons are already being deployed on London bus stops. Schema.org is already discussing extensions for documenting the physical accessibility of such places, e.g. wheelchair ramps or availability of braille menus. Many of these applications areas might be encountered in a "smart cities" context.
"Smart Assistants"
- The recent industry trend towards voice-activated smart/intelligent personalized "assistants" such as Microsoft Cortana, Apple's Siri, Amazon Alexa, Google Now / Google Home etc. is a development that bridges Web search scenarios with various IoT and transaction-oriented situations, moving beyond information access towards systems that mediate change e.g. various kinds of remote control. For example both Google Now and Cortana already use schema.org data extracted from email to provide assistance and user interfaces around activities such as travel e.g. flights (see: gmail docs, cortana docs). Such considerations already motivated the design of schema.org's "Action" mechanism and provides a foundation for handling various transaction-oriented situations within schema.org. Schema.org already has substantial terminology in this area and could naturally be extended for in-the-home actions for devices such as lighting and indoor environmental control. The combination of information from the physical world, using IoT, and the virtual world, such as email, can help the development of more capable Smart Assistants.
On-device content.
- Schema.org has extensive existing vocabulary that covers broadcast and archived television, radio and music content. These schemas have been developed in collaboration with BBC, European Broadcasting Union (EBU), MusicBrainz and others. Many smart home devices will contain content such as personal or purchased media, or metadata relating to files, events, streams and cloud services (e.g. streaming music providers). Schema.org's descriptive vocabulary covers much of this already.
Sensors and the description of the physical environment.
- Schema.org already contains basic and sometimes quite detailed vocabulary for describing properties and relationships of places, including businesses, events and other associated entities. It does not yet, however, have much support for the kind of data coming from IoT sensors - e.g. date/time stamped temperature measurements. It is likely that patterns based largely on existing vocabulary could be agreed relatively easily, and there is scope for an extension aligned with other work such as that at W3C. There is also related work on physical accessibility of places, e.g. navigation to support vision impaired users, documentation of wheelchair ramps, availability of assistive technologies, braille menus, and related considerations.
Energy Efficiency:

Users can offer flexibility to the Smart Grid to manage their smart home devices by means of a Customer Energy Manager (CEM). The CEM is a logical function for optimizing energy consumption and/or production that can reside either in the home gateway or in the cloud. The interoperability of a device with other devices and with the CEM should be guaranteed regardless of their brand/manufacturer, because the user wants to be able to buy any washing machine they want and still have it communicate with the other devices that are already in their home. Some examples scenarios include the scheduling of appliances in certain modes and preferred times using power profiles to optimize energy efficiency and accommodate the user's preferences. For example, the user might want the washing done by 5:00 p.m. with least electrical power costs, or prefer to limit their own energy consumption up to a defined limit. Such scenarios suggest that there would be value in developing common schemas that can express control preferences and policies relating to energy efficiency.

Current Landscape

We will not attempt here any kind of survey of the larger IoT industry universe and its numerous standardization efforts. Appendix A provides examples from a few related projects that share schema.org general approach (definitions of types/properties for a triples/graphs data model in the broader W3C RDF family).

In addition to other schema creation efforts (the focus of Appendix A) that are expressible in a schema.org-like datamodel, there are other efforts in the Web standards community with which it would be natural to coordinate and collaborate. In particular there are two efforts around W3C:

Web platform API efforts, such as Battery Status API, Sensor API, TV remote controls.
Ongoing and proposed W3C "Web of Things" efforts. W3C has an active Interest Group already exploring and prototyping in this area. There is also a very large (but relatively inactive) Community Group, and a proposal under development for a more formal Working Group.

It should also be noted that there is also considerable interest around IoT happening in an Internet rather than Web standards setting. Any schema.org initiative in this area will need to take care to engage with efforts around both W3C and IETF. For example see the IoT Semantic Interoperability Workshop 2016 and the Internet of Things Software Update Workshop (IoTSU). An ideal outcome would be for all schema.org's schemas to be usable (directly or via mappings) by a variety of platforms and standards in the IoT/WoT ecosystem.

Governance and related Considerations

At the time of writing, there is not yet any precedent for schema.org schemas being cited normatively by W3C "Recommendation-track" Working Groups, although there is no in-principle reason why this shouldn't happen so long as W3C's Normative References considerations are addressed to the satisfaction of the W3C Director. Schema.org has recently introduced more explicit documentation of its workflow as part of discussions about whether it meets governmental needs (e.g. job adverts).

Practical Considerations - "How it might work"

Schema.org is run as an independent project, but given the overlap in technologies, expert communities and close ties to the evolution of supporting technology like JSON-LD, RDFa, HTML5, it has primarily been developed on W3C-hosted public discussion lists. Since 2015 this has been based on W3C's Community Group mechanism, see https://www.w3.org/community/ but it is important to understand that Schema.org is an independent initiative and that it is not governed by the official W3C Process. The schema.org "How we work" provides more details, but for this document's purposes it is important also to understand that there are several layers to schema.org.

The most basic piece of schema.org is the core datamodel. Roughly this corresponds to W3C RDF, in that it uses a graph datamodel and relies on a dictionary of type and property definitions. Secondly, there is the core of schema.org: a collection of such definitions. Currently 500+ types, 800+ properties, and 100+ property values. Beyond the core, the project overlays several so-called "hosted" extensions, such as "auto", "bib", "health-lifesci". These add further terms, or refined definitions, on top of the core. And beyond these, in the wider Web, there are other domain-specific or dataset-specific "external extensions", the most notable of which is GS1's work at http://gs1.org/voc/.

This combination of mechanisms provides several integration points for IoT-inspired vocabulary. Firstly, other non-schema.org vocabularies can be directly used alongside schema.org, thanks to the extensibility of the underlying formats (JSON-LD, RDFa, Microdata etc.). Secondly, there is scope for the core schema.org vocabularies to be evolved to address IoT scenarios more deeply, e.g. tweaks to definitions, clarifications or addition of modest amounts of new vocabulary. Thirdly, hosted (e.g. at iot.schema.org) schema extensions could go into more detail, and fourthly, GS1-like external schemas can also be integrated. These options are not mutually exclusive, and it is likely that "IoT + Schema.org" efforts will explore improvements and deployment using a combination of these options.

To elaborate on the distinction between schema.org's hosted versus external extensions, an excerpt from the schema.org site:

As schema.org has grown, we have developed mechanisms for community extension as a way of adding more detailed descriptive vocabulary that builds on the schema.org core.
Hosted extensions are managed and published as part of the schema.org project, with their design often led by one of more dedicated community groups.
External extensions live elsewhere in the Web, typically managed by other organizations with their own processes and collaboration mechanisms. Please consult external documentation for full details of their vocabulary, versioning system and release history.

Advantages of this combination of approaches (core + hosted + external …) include:

Can build on a large and widely used base vocabulary giving definitions for basic things like Person, Event, Place, LocalBusiness, Product etc.
Integration between IoT-oriented and non-IoT environments - e.g. a TV set top box can be thought of as a device, but typically contains a database about TV shows, channels, actors and other non-IoT entities.
Decoupling of data formats from expected use of the data; e.g. a personal healthcare application that manages information about someone's weight, blood pressure etc. shouldn't have to care about which IoT ecosystem the user's devices belong to.
Can build upon existing community-based collaborations using public fora (Github/W3C).
Aligned with 'knowledge graph'-style of structured data (triples/graphs) as used widely in products from Google and other companies, as well as with the Wikidata work at Wikipedia.

Proposed Next Steps for IoT + Schema.org

We propose a phased exploration of the topics outlined above.

Phase 1: identify public mailing lists for topical discussion. This could be a combination of (1.) the existing W3C Community Group for "Web of Things" (link) (if its chair i.e. Dave Raggett agreed) and (2.) a dedicated high level list for information sharing hosted directly at schema.org or elsewhere (update: Dan Brickley has created sdo-iot-sync@googlegroups.com to serve this purpose - link).
This combination would simultaneously avoid fragmenting further the existing fora at W3C, while also providing a non-W3C public channel for more IETF-oriented participants who have expressed wariness regarding a 100% W3C-hosted approach. During this phase, we would encourage collection of existing works including literature reviews, mappings, collaborative prototyping and use-case driven sketching of possible designs, but we would not anticipate substantive additions to schema.org's core or creation of hosted extensions. An entry point for all these materials and discussions should be created at iot.schema.org.
Phase 2: exploration of existing or newly proposed schemas as extensions to schema.org, using the "External Extension" mechanism, along the lines of GS1's existing work at http://gs1.org/voc/ - this phase would encompass conversion/mapping/transformation from original data formats into something compatible with schema.org's datamodel and a liberal interpretation of W3C RDF.
Phase 3: based on phase 2 modeling and prototyping explorations and dialogue with relevant standards efforts such as W3C WoT, we could expect more substantive additions to schema.org core and/or population of term definitions at iot.schema.org.

A rough timeline would be that phase 1 commences immediately (summer 2016), phase 2 later in 2016, and phase 3 primarily during 2017. All of this should not be an obstacle to making simple, small and pragmatic IoT-inspired improvements across schema.org at any time, wherever there is general community consensus.

As of 1st August 2016, such collaboration has been proposed as an activity within schema.org's GitHub repository, and a new mailing list established for ongoing discussion. The proposal is that an iot.schema.org site be established immediately as an entry point to these collaborations, and that initial discussions take place on the sdo-iot-sync mailing list. Please sign up and join in!

Appendix A: Schema Survey: Related Works

It is impossible to provide a comprehensive overview of all schema-oriented standardization efforts relating to IoT. A few are collected here. We acknowledge that this is only a small sampling of relevant work and that a deeper survey (including e.g. rapidly evolving efforts like FIWARE) would be needed as part of any ongoing collaborative schema design.

We have left in some fairly large examples of actual markup using their existing schema.org-compatible syntaxes, to give a more detailed view of the kind of schemas that are already being explored and deployed. A natural next step would be to move these materials out into a dedicated compare-and-contrast document that examines them in more detail.

Before looking at these specific IoT-related schemas it may be useful to take a higher level view of relevant standardization activities at both the IETF and at W3C.

IETF

The IETF work on the Internet of Things crosses a number of different IETF Areas, and is coordinated by a recently constituted directorate. The work includes a variety of application, security, routing, and addressing elements; related working groups include ACE, ROLL, 6lo, homenet, lwig, 6TiSCH and CoRE. Because the work draws on existing IETF specifications and experience, it is also common for constrained device considerations to be present in other groups, even if it is not their main focus. The general thrust of IETF work is to ensure that constrained devices participate as fully in the Internet as is practical and to identify responses to those constraints that work well in the overall environment. See the recent overview document, "Internet of Things: Standards and Guidance from the IETF" for more details.

In addition to the work on standards specification, there is related work in the Internet Research Task Force, primarily concentrated in the Thing-to-Thing Research Group (T2TRG). Working in close collaboration with the W3C's Web of Things group, the T2TRG focuses on longer term research issues on IoT, with current work centering around RESTful design / hypermedia-driven applications and security. The IRTF work is coordinated by the Internet Architecture Board, which has also held a number of workshops related to the Internet of Things. Two recent workshops focused on Semantic Interoperability and Software Update practices for IoT.

W3C

W3C has a few specifications that cover IoT-related considerations relating to the Web platform, as well as an initiative exploring "Web of Things":

Devices and Sensors WG - https://www.w3.org/2009/dap/
- "the mission of the Device and Sensors Working Group is to create client-side APIs that enable the development of Web Applications and Web Widgets that interact with devices hardware, sensors, services and applications such as the camera, microphone, proximity sensors, native address books, calendars and native messaging applications."
- Generic Sensor API - https://www.w3.org/TR/generic-sensor/
  - "defines a framework for exposing sensor data to the Open Web Platform in a consistent way. It does so by defining a blueprint for writing specifications of concrete sensors along with an abstract Sensor interface that can be extended to accommodate different sensor types."
- Vibration API - https://www.w3.org/TR/2016/PER-vibration-20160818/
  - "This specification defines an API that provides access to the vibration mechanism of the hosting device. Vibration is a form of tactile feedback."
"Web of Things" (WoT) - https://www.w3.org/WoT/
This sets out to address the fragmentation of the IoT into incompatible platforms and data silos. The aim is to simplify application development and improve interoperability across different platforms through metadata that describes the interaction model exposed to applications (properties, actions and events), security and communication details for accessing platforms, and semantic models and constraints for search, validation and composition of services. The approach is based upon the core architecture of the Web with URIs as addresses for thing descriptions, declarative formats for these descriptions, and protocols for accessing things and their descriptions.
- Interest Group - https://www.w3.org/WoT/IG/ (active with frequent plugfests)
- Community Group - https://www.w3.org/community/wot/ (somewhat active)
- Business Group, Working Group - proposals for these are planned.
Spatial Data on the Web WG
- Semantic Sensor Network Ontology - https://www.w3.org/TR/vocab-ssn/
  - The Semantic Sensor Network Ontology (commonly known as "SSN" or sometimes "SSNO") is an OWL-2 DL ontology for describing sensors and the observations they make of the physical world. SSN is published in a modular architecture that supports the judicious use of "just enough" ontology for diverse applications, including satellite imagery, large scale scientific monitoring, industrial and household infrastructure, citizen observers, and Web of Things. SSN is described and examples of its use are given.
  - Classes:

Other Initiatives

SmartThings (via Michael Koster)

For SmartThings background, see See SmartThings Capability Model documentation.
Affordances typically provided by the set of (5) device types mentioned map to SmartThings capabilities. See also: SmartThings Capabilities for Basic Device Types. Mapping of these capabilities and some representative devices to the current W3C Thing Description model (events, actions, properties): https://github.com/connectIOT/iotivity-servient/tree/master/td. Note that the "st" expansion in these examples should resolve to references to iot.schema.org resources.
See documents for details. In summary, the device types + capabilities listed are:

Light (switch, switchLevel, colorControl, colorTemperature)
Motion Sensor (motionSensor, temperatureMeasurement, battery)
Water Sensor (waterSensor, temperatureMeasurement, battery)
Switch (button, battery)
Door Sensor (contactSensor, temperatureMeasurement, battery)
Smart Plug (switch, energyMeter).

Capabilities in turn have attributes, which may have commands (that may take parameters).

SmartThings Capability Model <-> schema.org mapping

Via: Michael Koster

A very rough prototype mapping of the SmartThings Capability Model to schema.org-like constructs. This is a rough exploration, giving an idea of the basic structures and formats. This uses the schema.org definitions for Type and Property, and define some base types and a starting set of structural relation properties (hasAttribute...) to define a consistent model. All capability type instances derive from the base types.

The base model is at: http://thingschema.org/smartthings/stCapabilityModel.jsonld

Example set of types for modeling lights are at:
http://thingschema.org/smartthings/examples/light-example.jsonld (copied below)
-
The above files are collections of types and properties that are split out to individual files at the URI reference endpoints, e.g.
http://thingschema.org/smartthings/Attribute.jsonld, http://thingschema.org/smartthings/Command.jsonld, etc.

The base model directory at http://thingschema.org/smartthings/ is populated but I haven't populated the application capabilities instances at http://thingschema.org/smartthings/capabilities/ yet; only the first examples.

These validate on http://json-ld.org/playground/ you can just plug in the .jsonld URLs above to view them as triples in various formats.

It should be possible to convert these to OWL or other graph formats, or use them for constructors or validators.

Command Instances: these track instantiation of an action over time, e.g. slowly turning on lights over time. In schema.org these would all be Action, and the matter handled via URIs for Action identity.

{ "@context": { "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", "rdfs": "http://www.w3.org/2000/01/rdf-schema#", "sch": "https://schema.org/", "st": "http://thingschema.org/smartthings/", "stc": "http://thingschema.org/smartthings/capabilities/", "type": { "@id":"rdf:type", "@type": "@id"}, "id": { "@id":"rdf:ID", "@type": "@id"}, "subClassOf": {"@id": "rdfs:subClassOf", "@type": "@id"}, "range": {"@id": "rdfs:range", "@type": "@id"}, "domain": {"@id": "rdfs:domain", "@type": "@id"}, "items": "st:hasItem", "hasCapability": { "@id": "st:hasCapability", "@type": "@id"}, "hasAttribute": { "@id": "st:hasAttribute", "@type": "@id"}, "hasCommand": { "@id": "st:hasCommand", "@type": "@id"}, "hasMethod": { "@id": "st:hasMethod", "@type": "@id"}, "hasParameter": { "@id": "st:hasParameter", "@type": "@id"}, "hasAttribute": { "@id": "st:hasAttribute", "@type": "@id"}, "hasRepresentationFormat": { "@id": "st:hasRepresentationFormat", "@type": "@id"} }, "items": [ { "type": "sch:Type", "id": "stc:light", "subClassOf": "st:Thing", "hasCapability": ["stc:switch", "stc:switchlevel", "stc:colortemperature", "stc:colorcontrol"] }, { "type": "sch:Type", "id": "stc:switch", "subClassOf": "st:Capability", "hasAttribute": "stc:onoff", "hasCommand": ["stc:on", "stc:off"] }, { "type": "sch:Type", "id": "stc:switchlevel", "subClassOf": "st:Capability", "hasAttribute": ["stc:level"], "hasCommand": ["stc:setLevel"] }, { "type": "sch:Type", "id": "stc:colortemperature", "subClassOf": "st:Capability", "hasAttribute": "stc:colortemperature", "hasCommand": "stc:setcolortemperature" }, { "type": "sch:Type", "id": "stc:colorcontrol", "subClassOf": "st:Capability", "hasAttribute": ["stc:hue", "stc:saturation", "stc:color"], "hasCommand": ["stc:sethue", "stc:setsaturation", "stc:setcolor"] }, { "type": "sch:Type", "id": "stc:onoff", "subClassOf": ["st:Attribute", "st:Parameter"], "hasRepresentationFormat": "sch:string" }, { "type": "sch:Type", "id": "stc:level", "subClassOf": ["st:Attribute", "st:Parameter"], "hasRepresentationFormat": "sch:number" }, { "type": "sch:Type", "id": "stc:transitiontime", "subClassOf": "st:Parameter", "hasRepresentationFormat": "sch:number" }, { "type": "sch:Type", "id": "stc:colortemperature", "subClassOf": ["st:Attribute", "st:Parameter"], "hasRepresentationFormat": "sch:number" }, { "type": "sch:Type", "id": "stc:hue", "subClassOf": ["st:Attribute", "st:Parameter"], "hasRepresentationFormat": "sch:number" }, { "type": "sch:Type", "id": "stc:saturation", "subClassOf": ["st:Attribute", "st:Parameter"], "hasRepresentationFormat": "sch:number" }, { "type": "sch:Type", "id": "stc:hex", "subClassOf": ["st:Attribute", "st:Parameter"], "hasRepresentationFormat": "sch:string" }, { "type": "sch:Type", "id": "stc:color", "subClassOf": "st:Attribute", "hasParameter": ["stc:hue", "stc:saturation", "stc:level", "stc:onoff", "stc:hex"], "hasRepresentationFormat": "stc:colorformat" }, { "type": "sch:Type", "id": "stc:on", "subClassOf": "st:Command", "hasRepresentationFormat": "sch:string" }, { "type": "sch:Type", "id": "stc:off", "subClassOf": "st:Command", "hasRepresentationFormat": "sch:string" }, { "type": "sch:Type", "id": "stc:setlevel", "subClassOf": "st:Command", "hasParameter": ["stc:level", "stc:transitiontime"] }, { "type": "sch:Type", "id": "stc:setcolortemperature", "subClassOf": "st:Command", "hasParameter": ["stc:colortemperature"] }, { "type": "sch:Type", "id": "stc:setcolor", "subClassOf": "st:Command", "hasParameter": ["stc:hue", "stc:saturation", "stc:level", "stc:onoff", "stc:hex"], "hasRepresentationFormat": "stc:colorformat" } ] }

Architectural discussions

From Michael Koster:

Regarding the mapping of abstract Events, Actions, and Properties to a REST + Notifications API. Here is a description of an API mapping and processing workflow for this purpose.
https://github.com/connectIOT/iotivity-servient/blob/master/docs/abstract-transfer.pdf

Also some slides on RESTful Actuation methods:
https://github.com/connectIOT/iotivity-servient/blob/master/docs/RESTful%20Actuation.pdf

SAREF - Smart Appliances REFerence ontology

The Smart Appliance REFerence ontology (SAREF) is a shared model of consensus developed in close interaction with the industry and with the support of the European Commission. It is published as a technical specification by ETSI and provides an important contribution to achieve semantic interoperability for smart appliances.

SAREF focuses on the concept of "device", which is a tangible object designed to accomplish a particular task in households, common public buildings or offices. In order to accomplish this task, a device performs one or more "functions". For example, a washing machine is designed to wash (task) and to accomplish this task it performs, among others, a start and stop function. When connected to a network, a device offers a "service", which is a representation of a function to a network that makes the function discoverable, registerable and remotely controllable by other devices in the network. A device is also characterized by an "energy profile" and a "power profile" that can be used to optimize the energy efficiency in a home or office that are part of the building. SAREF is expressed in OWL-DL and contains 110 classes and 42 properties.

SAREF HTML documentation is available at http://w3id.org/saref. SAREF human readable documentation with explanatory diagrams is also available. More details on the methodology, principles, modelling choices and lessons learned can be found in FOMI2015 and OWLED2015. SAREF can be downloaded in different formats at http://ontology.tno.nl/saref.ttl (TURTLE version) or http://ontology.tno.nl/saref.owl (RDF/XML version). The server does not currently support content negotiation, so format-specific URLs are needed (saref.ttl etc.).

SAREF4EE is the extension of SAREF for EEBus and Energy@Home, the major Germany- and Italy-based industry associations that include, among others, BSH Bosch/Siemens, Miele, Intel, Deutsche Telekom, Electrolux, Enel, Indesit, Whirlpool and Telecom Italia. SAREF4EE enables the interoperability between EEBus and E@H devices in demand response use cases. In these use cases, customers can offer flexibility to the Smart Grid to manage their smart home devices by means of a Customer Energy Manager (CEM). SAREF4EE HTML documentation is available at http://w3id.org/saref4ee. SAREF4EE human readable documentation with explanatory diagrams and some example instances is also available.

From the human-readable SAREF overview:

SAREF is based on the following main concepts (in alphabetical order):

Building Object (Door, Window).
Building Space.
Command (e.g. OnCommand, OffCommand, PauseCommand, GetCommand, NotifyCommand, SetLEvelCommand).
Commodity (e.g. Electricity, Gas, Water).
Device (e.g. Switch, Meter, Sensor, Washing Machine).
Device Category.
Duration Description.
Function (Actuating Function, EventFunction, Metering Function, Sensing Function).
Function Category.
Profile.
Property (Energy, Humidity, Light, Motion, Occupancy, Power, Pressure, Price, Smoke, Temperature, Time).
Service.
State.
Task (e.g. Cleaning, Safety, Entertainment).
Temporal Entity.
UnitOfMeasure (e.g. Currency, EnergyUnit, Power Unit, Temperature Unit).

SAREF's analysis of existing conceptualizations identified 3 clusters (focuses, or trends):

devices, sensors and their specification in terms of functions, states and services
energy consumption/production information and profiles to optimize energy efficiency;
building related semantic models.

Excerpting,

"In SAREF these trends are called, function-related, energy-related and building-related, respectively. SAREF includes not only the necessary concepts and relationships to characterize these trends individually, but also to link these trends to each other. For example, the concept of building space links function-related assets to building-related assets, since a device designed to accomplish a certain function is located in a specific room of the home or office in a building. Another example is the concept of profile that links function-related assets to energy-related assets, since a device designed to accomplish a certain function can be associated with a certain energy/power profile that can be used for energy optimization purposes."

Turtle Samples (via Laura Daniele)

A saref:Device must accomplish at least one function, and can be used for the purpose of i) offering a commodity, such as saref:Water or saref:Gas; ii) sensing, measuring and notifying a property, such as saref:Temperature, saref:Energy or saref:Smoke, or iii) controlling a building object, such as a saref:Door or a saref:Window. Moreover, a device may consist of other devices (saref:consistsOf property). For example,

a temperature sensor is a device that consists of a sensor, has category saref:Sensor, performs the saref:SensingFunction and is used for the purpose of sensing a property of type saref:Temperature;
a smoke sensor is a device that consists of a sensor, has category saref:Sensor, performs the saref:SensingFunction and saref:EventFunction, and is used for the purpose of sensing a property of type saref:Smoke and notifying that a certain threshold has been exceeded;
a door switch is a device that consists of a switch, has category saref:Actuator, performs the saref:OpenCloseFunction and is used for the purpose of controlling a building object of type saref:Door;
an energy meter is a device that consists of a meter, has category saref:Meter, performs the saref:MeteringFunction and is used for the purpose of measuring the saref:Energy property.
a washing machine is a device that has category saref:Appliance, accomplishes the task saref:Washing and performs an actuating function of type saref:StartPauseFunction. From an energy related perspective, a washing machine also belongs to the category saref:Load;

A function is represented with the saref:Function and is defined as "the functionality necessary to accomplish the task for which a device is designed". It must have at least one command (saref:hasCommand min 1 saref:Command). Examples of functions are

the saref:ActuatingFunction which allows to "transmit data to actuators, such as level settings (e.g., temperature) or binary switching (e.g., open/close, on/off)",
The saref:SensingFunction which allows to "transmit data from sensors, such as measurement values (e.g., temperature) or sensing data (e.g., occupancy)",
The saref:MeteringFunction which allows to "get data from a meter, such as current meter reading or instantaneous demand", and
The saref: EventFunction which allows to "notify another device that a certain threshold value has been exceeded".

Examples of Actuating Functions are the saref:OnOffFunction (allows to "switch on and off an actuator", and has the commands saref:OnCommand, saref:OffCommand and saref:ToggleCommand), and the saref:LevelControlFunction (allows to "do level adjustments of an actuator in a certain range (e.g., 0 %-100 %), such as dimming a light or set the speed of an electric motor"). Depending on the function(s) it performs, a device can be found in a corresponding saref:State. For example, a switch can be found in the saref:OnOffState, which is characterized by the values "ON" or "OFF". A device also offers a service (the saref:Service class), which is a representation of a function to a network that makes this function discoverable, registerable and remotely controllable by other devices in the network. A service must specify the device(s) offering the service, the function(s) to be represented, and the input and output parameters necessary to operate the service. For example, a light switch can offer the service of remotely switching the lights in a home through mobile phone devices that are connected to the local network. This remote switching service represents the saref:OnOffFunction, it must have a saref:State as input parameter, e.g., with value "ON", and it must have a saref:State has output parameter, namely with value "OFF" in this example since the input state value was "ON".

Representative samples of SAREF, describing a light switch, door switch, temperature sensor, smoke sensor, energy meter and washing machine.

See ontology.tno.nl for detailed data.

Here we show just the example of a specific light switch, alongside supporting definitions:

# baseURI: http://ontology.tno.nl/saref/lightswitch # imports: https://w3id.org/saref @prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix saref: <https://w3id.org/saref#> . @prefix saref-ls: <http://ontology.tno.nl/saref/lightswitch#> . @prefix time: <http://www.w3.org/2006/time#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . <http://ontology.tno.nl/saref/lightswitch> rdf:type owl:Ontology ; owl:imports <https://w3id.org/saref> ; . saref-ls:BuildingSpace_OfficeHall rdf:type saref:BuildingSpace ; rdfs:label "Office Hall"^^xsd:string ; geo:lat "52.0821"^^xsd:string ; geo:long "4.3251"^^xsd:string ; saref:hasSpaceType "Office hall"^^xsd:string ; . saref-ls:Light rdf:type saref:Light ; rdfs:label "Light "^^xsd:string ; saref:hasValue "not applicable"^^xsd:string ; saref:isMeasuredIn <http://www.wurvoc.org/vocabularies/om-1.8/lux> ; . saref-ls:LightSwitch_LS1001 rdf:type saref:LightSwitch ; rdfs:label "Light switch LS1001"^^xsd:string ; saref:IsUsedFor saref-ls:Light ; saref:accomplishes saref-ls:Lighting ; saref:consistsOf saref:Switch ; saref:hasCategory saref:Actuator ; saref:hasDescription "Light switch LS1001 is an example of how to instantiate a light switch using SAREF"^^xsd:string ; saref:hasFunction saref-ls:OnOffFunction ; saref:hasManufacturer "manufacturer-abc"^^xsd:string ; saref:hasModel "890-09w"^^xsd:string ; saref:hasState saref-ls:OffState ; saref:hasState saref-ls:OnState ; saref:isLocatedIn saref-ls:BuildingSpace_OfficeHall ; saref:offers saref-ls:SwitchOnService ; . saref-ls:Lighting rdf:type saref:Task ; rdfs:label "Lighting"^^xsd:string ; saref:isAccomplishedBy saref-ls:LightSwitch_LS1001 ; . saref-ls:OffCommand rdf:type saref:OffCommand ; rdfs:label "OFF command "^^xsd:string ; saref:actsUpon saref-ls:OnState ; . saref-ls:OffState rdf:type saref:OffState ; rdfs:label "OFF state"^^xsd:string ; . saref-ls:OnCommand rdf:type saref:OnCommand ; rdfs:label "ON command"^^xsd:string ; saref:actsUpon saref-ls:OffState ; . saref-ls:OnOffFunction rdf:type saref:OnOffFunction ; rdfs:label "ON OFF function "^^xsd:string ; saref:hasCommand saref-ls:OffCommand ; saref:hasCommand saref-ls:OnCommand ; . saref-ls:OnState rdf:type saref:OnState ; rdfs:label "ON state"^^xsd:string ; . saref-ls:SwitchOnService rdf:type saref:SwitchOnService ; rdfs:label "Switch ON service "^^xsd:string ; saref:hasInputParameter saref-ls:OffState ; saref:hasOutputParameter saref-ls:OnState ; saref:isOfferedBy saref-ls:LightSwitch_LS1001 ; saref:represents saref-ls:OnOffFunction ; .

BuildSys Building Schema (BRICK)

Via Jason Koh.

Many applications have been developed for commercial buildings for energy-saving, better human interactions, system maintenance, etc. Those applications however have not been widely deployed due to the lack of common understanding of building resource representation. Recent movements for buildings such as Project Haystack, Industrial Foundation Classes (IFC), and SAREF provide their own schemata but do not capture all the terminologies and relationships that modern building applications require [1]. Brick is a uniform schema presenting metadata in buildings. Research community from multiple organizations put this forward actively. Base schema, actual building instances, and querying examples for applications are public through a repository. Further details can be found in the original paper [2].
(repository: https://github.com/BuildSysUniformMetadata/GroundTruth)

We normalized terminologies and relationships of sensors and actuators existing in 5 different Building Management Systems (BMS) needed for modern applications mostly listed in [Bhattacharya et al. 2015] into Brick. One of our observation was that a terminology consists of multiple words, and each of them represent a meaning. We define each terminology to represent equipment, sensors, etc. as a Tagset. Basic taxonomy of Tagsets are described in Fig. 1.
The words that constitute Tagsets are called Tags. For example, "Room Temperature Sensor" is under "Sensor" category in Fig.1. and is broken down into Tags as "Room", "Temperature" and "Sensor". In this simple way, we can achieve both ease of use and expressiveness. Building managers not familiar with the entire schema may annotate a resource such as equipment or a sensor by Tags easily. As each tag represents a meaning, meaning of a collection of tags can be inferred to the most similar Tagset. At the same time, managers or developers who have full knowledge about the schema can represent resources by Tagsets with exact meanings. Managers can define utilize predefined properties to express relationships among Tagsets as presented in Table 1. For example, we can express that a "Space Heater" "hasPoint" "Room Temperature Sensor".

List 1 shows how Tagsets are defined in a formal way using Turtle syntax. "HVAC_Zone" is a Tagset, which is a subclass of "Location" and consists of Tags as "HVAC" and "Zone". The relationships between a Tagset and Tags are explicitly defined to infer the meaning of a collection of Tags easily as explained before. Usable Tags are also defined in a similar way as in List 2 with a similar taxonomy as Tagset's. We represent an example building with these subsets of the schema in List 3. From this information, we know that example_building is a Building, zone_1 is a HVAC_Zone located in the building. The zone has a vav_1, which is a Variable Air Volume Box (a type of terminal units to provide controlled air to a HVAC zone such as a room) where a one Temperature Sensor functions for both the HVAC Zone and the VAV.

Actual instances of Brick for five buildings validate its completeness. Brick captures 98 % of 15,700 BMS data points and 615,000 sq-ft of floor space. Illustrative but representative queries are also successfully tested to show the coverage of relationships we need for eight canonical applications. These actual examples are available via the repository.

Fig. 1 A Subset of Brick Tagset Taxonomy

Relationship	Definition
A contains B	A physically encapsulates B
A controls B	A determines or affects the internal state of B
A hasPart B	A has some component or part B
A hasPoint B	A is measured by or is otherwise represented by point B
A feeds B	A flows or is connected to B

Table 1. Relationships of Tagsets in Brick.

### Tagsets
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix brickframe: <http://buildsys.org/ontologies/BrickFrame#> .
@prefix tag: <http://buildsys.org/ontologies/BrickTag#> .
@prefix : <http://buildsys.org/ontologies/Brick#> .
:Location rdfs:subClassOf brickframe:TagSet ;
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Location ].

:HVAC_Zone rdfs:subClassOf :Location;
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:HVAC ];
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Zone ].

:Point rdfs:subClassOf brickframe:TagSet ;
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Point ].

:Sensor rdfs:subClassOf :Point ;
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Sensor ].

:Temperature_Sensor rdfs:subClassOf :Sensor ;
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Temperature ];
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Sensor ].

:Zone_Temperature_Sensor rdfs:subClassOf :Temperature_Sensor ;
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Zone ];
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Temperature ];
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Sensor ].
:Equipment rdfs:subClassOf brickframe:TagSet ;
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Equipment ].

:VAV rdfs:subClassOf :Terminal_Unit ;
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:VAV ].
:HVAC rdfs:subClassOf :Equipment ;
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:HVAC ].

:Terminal_Unit rdfs:subClassOf :HVAC;
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Terminal ];
rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :hasTag ; owl:someValuesFrom tag:Unit ].

List 1: Brick.ttl

### Tags
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix brickframe: <http://buildsys.org/ontologies/BrickFrame#> .
@prefix : <http://buildsys.org/ontologies/BrickTag#> .
:Location rdfs:subClassOf brickframe:Tag .
:Building rdfs:subClassOf :Location .
:Zone rdfs:subClassOf :Location .
:MeasurementProperty rdfs:subClassOf brickframe:Tag .
:MeasurementProperty_PhysicalProperties rdfs:subClassOf :MeasurementProperty .
:Temperature rdfs:subClassOf :MeasurementProperty_PhysicalProperties .
:Equipment rdfs:subClassOf brickframe:Tag .
:HVAC rdfs:subClassOf :Equipment .
:VAV rdfs:subClassOf :HVAC .
:Point rdfs:subClassOf brickframe:Tag .
:Sensor rdfs:subClassOf :Point .

List 2: BrickTag.ttl

### Example Building
@prefix brick: <http://buildsys.org/ontologies/Brick#> .
@prefix brickframe: <http://buildsys.org/ontologies/BrickFrame#> .
@prefix ex: <http://ucsd.edu/building/ontology/example_building#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
ex:example_building a brick:Building .
ex:zt_sensor_1 a brick:Zone_Temperature_Sensor;
brickframe:isPointOf ex:zone_1, ex:vav_1 .

ex:zone_1 a brick:HVAC_Zone;
brickframe.isLocatedIn ex:example_building
.

ex:vav_1 a brick:VAV;
brickframe:basPoint ex:zt_sensor_1;
brickframe:feeds ex:zone_1.

List 3 An Example Building Instance

References
[1] Bhattacharya, Arka, Joern Ploennigs, and David Culler. "Short Paper: Analyzing Metadata Schemas for Buildings: The Good, the Bad, and the Ugly." In Proceedings of the 2nd ACM International Conference on Embedded Systems for Energy-Efficient Built Environments, pp. 33-34. ACM, 2015.
[2] Bharathan Balaji, Arka Bhattacharya, Gabe Fierro, Jingkun Gao, Joshua Gluck, Dezhi Hong, Aslak Johansen, Jason Koh, Yuvraj Agarwal, Mario Berges, David Culler, Rajesh Gupta, Mikkel Baun Kjærgaard, Joern Ploennigs and Kamin Whitehouse, "Brick v1.0 - Towards a Unified Metadata Schema For Buildings", In Proceedings of the 3rd ACM International Conference on Embedded Systems for Energy-Efficient Built Environments, 2016 (accepted, provisional pdf).

Nest Weave (Google/Alphabet)

Documentation of the file format still Nest-internal.

Primitive components in Nest Weave are called Traits, which are small units of composable functionality, comprising Properties, Commands, and Events. Message format is protobuf, and is intended to be highly readable, but does not imply any particular binary format.

Assistant-related Home Automation functions (Google)

Home Automation Execution Functional Schemata

N.B. This is a work in progress; please feel free to propose changes or sketch out new functions.

Function ID	onOff
Status	proposed
Parameter	Name	state
	Type	string
	Values	'on' 'off'
	Units	-
	R/W	Both
Devices	lights, wall plugs, anything with an on/off switch
Equates to Weave Schema	onOff
Notes	This is the base case of a 'semantic function' -- not much to do with on and off other than set the state and query the state. [Note that devices with more state would have a separate function -- such as reading the Smartthings power draw]

Function ID	powerCycle
Status	proposed
Parameter	Name	delay
	Type	int (optional)
	Values	0-?
	Units	seconds
	R/W?	W
Devices	lights, wall plugs, anything with an on/off switch
Equates to Weave Schema	onOff + choreography
Notes	A higher level function with choreography -- set onOff to off, wait n seconds, set onOff to on.

Function ID	brightness
Status	proposed
Parameter	Name	brightness
	Type	float
	Values	[0.0, 1.0]
	Units	-
	R/W?	Both
Devices	lights
Equates to Weave Schema	brightness
Notes	Using the weave trait range 0.0-1.0.

Function ID	brightness
Status	proposed
Parameter	Name	brightnessRelative
	Type	string
	Values	UP, DOWN
	Units	-
	R/W?	W
Parameter	Name	brightnessRelativeWeight (opt)
	Type	int
	Values	[1,5]
	Units	-
	R/W?	W
Devices
Equates to Weave Schema
Notes	This parameter would be used for ambiguous brightness queries, such as "dim the lights" Optionally support weighting of commands with brightnessRelativeWeight -- 'dim the lights a lot' -> 'DOWN, 5', 'dim the lights a little' -> 'DOWN, 1'.

Function ID	setColor
Status	proposed
Parameter	Name	colorTarget
	Type	string
	Values	6 character hex value
	Units	000000-FFFFFF
	R/W?	R/W
Devices	lights, other color-mutable items
Equates to Weave Schema	colorXy (see below)
Notes	We set color by RGB value; backends translate this into the appropriate emittable color based on hardware capabilities.

Function ID	setColor
Status	proposed
Parameter	Name	colorRelative
	Type	string
	Values	6 character hex value
	Units	000000-FFFFFF
	R/W?	W
Devices	lights, other color-mutable items
Equates to Weave Schema	colorXy (see below)
Notes	As above, but relative, for functionality like 'make the lights more blue'. The result is to move the current light setting along the 3d line towards the new target.