IoT & Schema.org: "Pupose" extensions
David Janes
This will be a little long winded, sorry. If you want to get to the concrete proposals skip down to where it says "Kitchen Temperature Sensor".
Important reference documents:
- https://www.w3.org/Submission/wot-model/ - W3C WoT Models
- https://iotdb.org/pub/iot-purpose.html - IOTDB "Purposes"
In WOT terminology, there's (at least) three different aspects that could be semantically described:
- the Model
- the Properties
- the Actions
Just briefly touching on Model, the W3C's idea is querying /model will return a schema:Product description (see Section 6.5). Although there's a lot of territory to explore here, I'll skip this here except to note that if one goes down the schema:LightThing route you're likely to end up in pain.
Properties and Actions are somewhat analogous in terms of semantic description, one's dealing with sensor data coming in and one with actuator commands going out, but there's a clear correspondence between the light is on and turn the light on.
So just to simplify, I'll just mostly with Properties and their semantic meaning here.
In section, "6.4.4.1 Retrieve a list of properties" we see a number of values that could be vastly improved by semantic markup, e.g.
"temp": 22
"x": 22
"y": 22.56
"z": 1.4
"theta": 2
"rho": -0.1
"timestamp": "2015-06-14T14:30:00.000Z"
Now, one option would be just to standardize the magic word, e.g. "temp" means "temperature in celsius". However, if you explore this route you hit a wall: you might want to measure in Kelvin, or in Fahrenheit, or to specify a precision specifically for this value, or a min max range that can be applied to etc.. There's just too many variants of the way things work to enumerate all the possibilities.
So what IOTDB attempts to do is provide a vocabulary for making these description, and it's what I'm bringing forward here. Likely some tweaking will have to be done, as things are named the same way as schema.org, but the concepts are "atomic" and mostly worked out from "real-thing" experience.
So specifically, let's look at "temp" and see how it could be improved.
Here's the WoT description
{
"id":"temperature",
"name":"Kitchen Temperature Sensor",
"values":{
"temp":22,
"timestamp":"2015-06-14T14:30:00.000Z"
}
}
Here's a "model" for schema.org's version, i.e. an explanation of all the terms used.
This is JSON-LDish, but not JSON-LD.
{
"@type": "schema:Sensor",
"id": (is a url),
"name": (means schema:name)
"values": (means schema:value),
"temp": {
"@type": "schema:SensorValue",
"schema:purpose": "schema:purpose/temperature",
"schema:minValue": 15,
"schema:maxValue": 25,
"schema:unitCode": "unit:DegreeCelsius", (from qudt:)
},
"timestamp": {
(something)
},
}
(Note here that I'm not making a recommendation for changes to W3C's WoT or EVRYTHNG's model, this is for illustrative purposes / a jumping off point for discussion).
Here's what's new here, two classes that I'm just tossing out here:
- schema:Sensor
- schema:SensorValue
And then:
- schema:purpose
- schema:purpose/temperature
This is what IOTDB's vocabulary could bring to schema.org: the concept of purpose, of what is this sensor (or actuator) telling us.
Here's where you can see the list of purposes: https://iotdb.org/pub/iot-purpose.html. It's all the things with @type iot:Purpose which basically the first section of the document. Just for fun, here's the purposes that IOTDB has currently defined:
actuator alarm alcohol altitude angle band battery brightness brightness.delta brightness.down brightness.up channel channel.delta channel.down channel.return channel.up chemical cold color color.cie.x color.cie.y color.cie.z color.hsb.brightness color.hsb.hue color.hsb.saturation color.hsl.hue color.hsl.lightness color.hsl.saturation color.rgb.b color.rgb.g color.rgb.r color.temperature command connected contact current cursor.down cursor.enter cursor.leave cursor.left cursor.right cursor.up duration energy energy.expended fire flag flag.false flag.toggle flag.true frequency heart-rate heat humidity intensity latitude light longitude manual media-control message.html message.text message.title moisture motion mute mute.false mute.toggle mute.true on on.false on.toggle on.true open open.false open.toggle open.true particulates plane plane.azimuth plane.elevation plane.pitch plane.roll plane.x plane.y plane.yaw plane.z power.pause shuttle.play shuttle.previous shuttle.stop smoke sound temperature tray.close tray.open tray.toggle uptime uptime.day uptime.hour uptime.month uptime.year value voltage volume volume-delta when when.end when.start
Regards,
D.
Richard Wallis
- Product ‘could’ be currently used to describe a sensor, however I think a specific Type, as you suggest, schema:Sensor would probably be more appropriate. I suggest that it is made a subtype of Product, in the same way Vehicle is, to capture the small number of sensor specific properties needed.
- A schema:Sensor description would probably need to describe where it is and what it is part of, so location could have it’s range extended to include Sensor (or potentially it’s Product super type). A question to be asked being, is isRelatedTo sufficient to describe that a sensor is part of a vehicle / bridge / oven etc. or would a more specific property be needed.
- schema:SensorValue is an ideal candidate for being a subtype of StructuredValue, along the lines of QuantitativeValue, which would handle most of the properties from your example. It could include a dateCreated property, a validThrough property, and something to indicate the purpose, which would probably be the URI of an externally managed set of authoritative values (e.g.. https://iotdb.org/pub/iot-purpose#temperature) - the management of large sets of enumerated values is not well handled within Schema.org.
- I would suggest that a schema:Sensor would not have task specific properties such as ‘temp’ which could rapidly become unmanageable. A single property value would suffice as it would reference one or more instances of schema:SensorValue each of which wold describe the type of measurement and its measured value.
- I suggest timestamp be handled within each instance of schema:SensorValue (as createdDate) as against being part of the Sensor description.
{"@context": "http://schema.org","@type": "Sensor","@id": "http://example.com/buildingsensor/23b","name": "Empire State Building Sensor Pack 23b","location":{"@type": "Place","geo": {"@type": "GeoCoordinates","latitude": "40.75","longitude": "73.98"},"name": "Empire State Building Top Floor"},"value": [{"@type": "SensorValue","schema:purpose": "https://iotdb.org/pub/iot-purpose#temperature","minValue": "-20","maxValue": "45","value": "18","schema:unitCode": "https://iotdb.org/pub/iot-unit#temperature.si.celsius","dateCreated": "2016-10-12",},{"@type": "SensorValue","schema:purpose": "Wind Speed","minValue": "0","maxValue": "150","value": "10","schema:unitCode": "https://iotdb.org/pub/iot-unit#speed.imperial.mile-per-hour","dateCreated": "2016-10-12",}]}
--
You received this message because you are subscribed to the Google Groups "sdo-iot-sync" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sdo-iot-sync+unsubscribe@googlegroups.com.
To post to this group, send email to sdo-io...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sdo-iot-sync/CACp1KyO0LbXuLw_bDOP_Jbs6xqV0_1m7Y-OPj6sAs1kHLkMUrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
David Janes
Hi David,Taking a quick look at this, and particularly your jumping off point example, I make the following suggestions on how it could not only be used with Schema.org, but also with the current patterns used within Schema:
- A schema:Sensor description would probably need to describe where it is and what it is part of, so location could have it’s range extended to include Sensor (or potentially it’s Product super type). A question to be asked being, is isRelatedTo sufficient to describe that a sensor is part of a vehicle / bridge / oven etc. or would a more specific property be needed.
- it can be on or off
- it can be turned on or off
- it has a product description
- you want a somewhat authoritative place to go get the schema:Product info
- the Model data doesn't change often, and is of a different "flavour" than the sensor data
- and because - e.g. the WeMo - we generally have schema:Sensor and schema:Actuator mixed together within the same thing, but are accessed through different URIs.
- /model is described by schema:Product
- /properties/... are described by schema:Sensor, a subtype of schema:Thing; individual sensor values are described by schema:SensorValue, a subtype of schema:StructuredValue
- /actions/... are described by schema:Actuator, a subtype of schema:Thing; the individual data points sent to control actuation are described by schema:ActuatorValue
- schema:SensorValue is an ideal candidate for being a subtype of StructuredValue, along the lines of QuantitativeValue, which would handle most of the properties from your example. It could include a dateCreated property, a validThrough property, and something to indicate the purpose, which would probably be the URI of an externally managed set of authoritative values (e.g.. https://iotdb.org/pub/iot-purpose#temperature) - the management of large sets of enumerated values is not well handled within Schema.org.
I agree, noting that I'd like to move the iot:purpose ontology into the schema: namespace.
- I would suggest that a schema:Sensor would not have task specific properties such as ‘temp’ which could rapidly become unmanageable. A single property value would suffice as it would reference one or more instances of schema:SensorValue each of which wold describe the type of measurement and its measured value.
Richard Wallis
So should schema:Sensor be a subtype of schema:Product…. My feeling is no. In particular:
- you want a somewhat authoritative place to go get the schema:Product info
- The documentation/info is separate from the object itself - that would probably be a WebPage, which references the product, with different creators, dateCreated, etc. to the Sensor (Product) itself .
- the Model data doesn’t change often, and is of a different “flavour" than the sensor data
- You would not expect it to. The Sensor Data (or values as I suggest above) is emanating from a Sensor-Product of a particular type/model which if in the data will set those values in context.
- and because - e.g. the WeMo - we generally have schema:Sensor and schema:Actuator mixed together within the same thing, but are accessed through different URIs.
Hi Richard,
Most of my response will be inline, but not just to make sure we're on the same page, I'm explicitly _not_ making any suggestions / proposals / whatever how W3C WoT should be rewritten; instead, I'm trying to illustrate particular juicy issues within the problem space should how Schema.org could be used to semanticize what they've already developed.
In the previous e-mail I was following the JSON-LD model that "here's the data" and "here's the model for the data" as two separate concepts.
David Janes
- the Thing itself, e.g. a WeMo Socket
- the actions a Thing can do, e.g. be turned and on off
- the values a Thing reports, e.g. whether it is on or off; how much power it is consuming
- how a Thing is composed into other Things, e.g. a Stove has four burners, an oven, an oven light, a fan, and so forth
- IoTProduct
- a subtype of Product or ProductModel, specifically for IoT products
- related to IoTAction by potentialAction
- related to IoTProperty by ???
- e.g. a WeMo Socket
- IoTAction
- a subtype of Action
- includes "purpose", as per the title of this email thread
- may include things like minValue, maxValue, units of measurement, etc.
- e.g. turn WeMo Socket on or off
- IoTProperty
- a subtype of Property
- includes "purpose", as per the title of this email thread
- may include things like minValue, maxValue, units of measurement, etc.
- some sort of relationship on IoTProduct, e.g. subthing?
To view this discussion on the web, visit https://groups.google.com/d/msgid/sdo-iot-sync/CAD47Kz5fxt%2BMcxQ34YPuhAhbjb7JP_329K-VNSpb1dfYYRW8JQ%40mail.gmail.com.
Richard Wallis
- IoTProduct
Apart from how you would relate it to to some measured values, there is no difference to a Product. - IoTAction
I believe that there is potential for a small collection of action subtypes here, such as OnOffAction, StateChangeAction (to a value, or increase/decrease by a value, etc.) - IoTProperty
Are these what I what I was referring to as schema:SensorValue? - Although very relevant to IoT issues, this is a feature that needs addressing more broadly in the area of Schema:Product. In the CreativeWork area of Schema this is handled by hasPart & isPartOf properties which may have some relevance here.
David Janes
Yes it would be good to get others to chime in on our so far 1-2-1 disussion.Addressing the elements of your 50,000ft view:
- IoTProduct
Apart from how you would relate it to to some measured values, there is no difference to a Product.
- IoTAction
I believe that there is potential for a small collection of action subtypes here, such as OnOffAction, StateChangeAction (to a value, or increase/decrease by a value, etc.)
- IoTProperty
- Are these what I what I was referring to as schema:SensorValue?
- Although very relevant to IoT issues, this is a feature that needs addressing more broadly in the area of Schema:Product. In the CreativeWork area of Schema this is handled by hasPart & isPartOf properties which may have some relevance here.
Although helpful in early discussions such as these, I would suggest not prefacing each term with IoT. As for Product above, there may be no need to create special types for these items, a minor tweak to what already exists may be sufficient. Also in a very short period, the new concepts and features we are grappling with today may become standard for most things. The difference between a refrigerator and a IoTrefrigerator may just become semantics and our compartmentalisation irrelevant and confusing in the future.