IoT and Schema.org: Getting Started

STATUS: Work in progress document targetting 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:

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.

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:

  1. Web platform API efforts, such as Battery Status API, Sensor API, TV remote controls.
  2. 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:

Proposed Next Steps for IoT + Schema.org

We propose a phased exploration of the topics outlined above.

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":

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:

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": "http://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):

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

  1. devices, sensors and their specification in terms of functions, states and services
  2. energy consumption/production information and profiles to optimize energy efficiency;
  3. 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 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

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.