W3C home > Mailing lists > Public > public-wot-ig@w3.org > January 2016

Re: Thing Description and thingschema

From: Michael Koster <michael.koster@smartthings.com>
Date: Tue, 26 Jan 2016 05:28:28 +0700
Cc: "Charpenay, Victor (ext)" <victor.charpenay@siemens.com>, Darko Anicic <darko.anicic@siemens.com>, "Kovatsch, Matthias" <matthias.kovatsch@siemens.com>, public-web-of-things <public-web-of-things@w3.org>, Public Web of Things IG <public-wot-ig@w3.org>
Message-Id: <711D7DD2-0FDA-4538-AA4C-C9751B471DC5@smartthings.com>
To: Sebastian Kaebisch <sebastian.kaebisch@siemens.com>
Hi Sebastian,

On further thought, I think it would be appropriate to indicete the data type in the resource type attribute, which can have an array of values e.g. 


So a client could use the hypermedia control to find the data type of an item. As I mentioned, complex types would need a little schema as the type representation, which could also refer to xsd types or whatever for it’s element types.

For device management, I would make resource types for management objects and control elements, like I did for the lighting controls, and map the types to collections and resources. For example, there could be a firmware update object which is a collection with one item containing or pointing to the new firmware, and another item to initiate the reflash. A third item could indicate status of the flash operation, and another could deal with restart of the device on update if needed, etc.

A location object would read out the current GPS coordinates or other location format as needed.

etc. for radio management, power supply, environmental monitor...

This is how it is done in OMA LWM2M management. In fact, the well known LWM2M management objects could simply be made collections in this system.

Best regards,


> On Jan 25, 2016, at 9:22 PM, Michael Koster <michael.koster@smartthings.com> wrote:
> Hi Sebastian,
> The data type in my demo is indicated in the SenML entity tag, and consists of very simple types of string, number, and boolean. Data type could also be described as a link attribute or form attribute in the case of actions. Data type can also be indicated in the media type for some types. For complex types there could be a JSON or JSON template with semantically defined names as keys.
> The general information for product ID, manufacturer, device management, etc. would be collections of management items with actions, events, and properties just like the data. I could make a simple example. 
> Best regards,
> Michael
>> On Jan 25, 2016, at 6:17 PM, Kaebisch, Sebastian <sebastian.kaebisch@siemens.com <mailto:sebastian.kaebisch@siemens.com>> wrote:
>> Hi Michael,
>> thank you for your mail. Indeed, we have a lot in common. Regarding to your question: An explanation of that definitions can be found here [1]. However, this was a working assumption around the Sapporo meeting last year and was not further pursued. However, there will be hopefully an update about this topic during the f2f meeting.
>> Regarding to your approach I have also 2 questions:
>> 1)      How do you define the data types of resources (especially complex types)? To initiate a T2T, it should be important to know what kind of data with its content has to be expected.
>> 2)      Where do you would define generic information which are, however, quite specific for a individual Thing such as location, product id, version etc.? This would be very valuable to get such information also direct from the Thing.
>> Best wishes
>> Sebastian
>> [1] https://github.com/w3c/wot/blob/master/plugfest/binding_coap.md <https://github.com/w3c/wot/blob/master/plugfest/binding_coap.md>
>> Von: Michael Koster [mailto:michael.koster@smartthings.com <mailto:michael.koster@smartthings.com>] 
>> Gesendet: Donnerstag, 21. Januar 2016 05:42
>> An: Kaebisch, Sebastian
>> Cc: Charpenay, Victor (ext); Anicic, Darko; Kovatsch, Matthias; public-web-of-things; Public Web of Things IG
>> Betreff: Thing Description and thingschema 
>> Hi Sebastian,
>> Thanks for the pointers to the TD resources. 
>> It looks like we have a lot in common around the JSON-LD schema and model work.
>> I have some questions about the thing description like where to find the definitions 
>> of terms like “links”, “actionStatus”, “createdTime”, etc. that appear in the 
>> examples. Also whether there are hyperlinks pointing to resources like
>> /ledlamp/colorTemperature/value <http://www.example.com:5683/ledlamp/colorTemperature/value>
>> As part of my demo, I’ve put up a public resource at thingschema.org <http://thingschema.org/> with the 
>> context, schemas and models I’m using which bear a lot of similarity to some 
>> of the TD language constructs. 
>> This definition in the TD context follows the same pattern I’m using for events,
>> actions, and properties.
>> "interactions": {
>>   "@id": "td:hasInteraction",
>>   "@type": "@id",
>>   "@container": "@set”
>> },
>> This leads into a good illustration of creation of semantic triples from JSON models.
>> Here is part of the context at http://thingschema.org/context.jsonld <http://thingschema.org/context.jsonld>
>> which is also mapped to http://thingschema.org/ <http://thingschema.org/>
>> "capabilities”: {
>>  "@id": "ts:hasCapability”, 
>>  "@type": "@id”
>> },
>> "events": {
>>  "@id": "ts:hasEvent”, 
>>  "@type": "@id”
>> },
>> "actions": {
>>  "@id": "ts:hasAction”, 
>>  "@type": "@id"},
>> "properties": {
>>  "@id": "ts:hasProperty”, 
>>  "@type": "@id”}
>> I found that I needed a way to define components of things so I defined “capabilities”. 
>> For example the on/off control of a light is one capability and brightness control is 
>> another. So in the model I can define “actions” for a thing (or a capability of a thing), 
>> and “properties” and “events” of a thing in terms of the domain schema.
>> Here is a sample from the JSON-LD model for the light, which starts as plain JSON and
>> which, with the addition of the @context definition at thingschema.org <http://thingschema.org/>, can be used to 
>> generate an RDF model.
>> {
>>  "@context": "http://thingschema.org <http://thingschema.org/>",
>>  "label": "light",
>>  "resource": [
>>     {
>>       "type": “light",
>>       "name": "light",
>>       "capabilities": [
>>         {
>>           "type": "onoff",
>>           "name": "onOff",
>>           "actions": [
>>             {
>>               "type": "change",
>>               "name": "change"
>>             }
>>           ],
>>           "properties": [
>>             {
>>               "type": "currentstate",
>>               "name": "currentState"
>> Which produces the following machine-comprehensible RDF model:
>> _:b0 <http://www.w3.org/2000/01/rdf-schema#Resource <http://www.w3.org/2000/01/rdf-schema#Resource>> _:b1 .
>> _:b0 <http://www.w3.org/2000/01/rdf-schema#label <http://www.w3.org/2000/01/rdf-schema#label>> "light" .
>> _:b1 <http://thingschema.org/name <http://thingschema.org/name>> "light" .
>> _:b1 <http://thingschema.org/schema#hasCapability <http://thingschema.org/schema#hasCapability>> _:b2 .
>> _:b1 <http://thingschema.org/schema#hasCapability <http://thingschema.org/schema#hasCapability>> _:b7 .
>> _:b1 <http://thingschema.org/schema#hasCapability <http://thingschema.org/schema#hasCapability>> _:b9 .
>> _:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://thingschema.org/light <http://thingschema.org/light>> .
>> _:b10 <http://thingschema.org/name <http://thingschema.org/name>> "change" .
>> _:b10 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://thingschema.org/change <http://thingschema.org/change>> .
>> _:b11 <http://thingschema.org/name <http://thingschema.org/name>> "move" .
>> _:b11 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://thingschema.org/move <http://thingschema.org/move>> .
>> _:b12 <http://thingschema.org/name <http://thingschema.org/name>> "step" .
>> _:b12 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://thingschema.org/step <http://thingschema.org/step>> .
>> _:b13 <http://thingschema.org/name <http://thingschema.org/name>> "currentBrightness" .
>> _:b13 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://thingschema.org/currentbrightness <http://thingschema.org/currentbrightness>> .
>> _:b14 <http://thingschema.org/name <http://thingschema.org/name>> "targetBrightness" .
>> _:b14 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://thingschema.org/targetbrightness <http://thingschema.org/targetbrightness>> .
>> _:b15 <http://thingschema.org/name <http://thingschema.org/name>> "moveBrightness" .
>> _:b15 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://thingschema.org/movebrightness <http://thingschema.org/movebrightness>> .
>> _:b16 <http://thingschema.org/name <http://thingschema.org/name>> "stepBrightness" .
>> _:b16 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://thingschema.org/stepbrightness <http://thingschema.org/stepbrightness>> .
>> _:b17 <http://thingschema.org/name <http://thingschema.org/name>> "transitionTime" .
>> _:b17 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://thingschema.org/transitiontime <http://thingschema.org/transitiontime>> .
>> _:b2 <http://thingschema.org/name <http://thingschema.org/name>> "onOff" .
>> _:b2 <http://thingschema.org/schema#hasAction <http://thingschema.org/schema#hasAction>> _:b3 .
>> _:b2 <http://thingschema.org/schema#hasProperty <http://thingschema.org/schema#hasProperty>> _:b4 .
>> _:b2 <http://thingschema.org/schema#hasProperty <http://thingschema.org/schema#hasProperty>> _:b5 .
>> _:b2 <http://thingschema.org/schema#hasProperty <http://thingschema.org/schema#hasProperty>> _:b6 .
>> _:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>> <http://thingschema.org/onoff <http://thingschema.org/onoff>> .
>> _:b3 <http://thingschema.org/name <http://thingschema.org/name>> "change” .
>> (etc.)
>> You can play with the schemas and full model using the JSON-LD playground:
>> http://json-ld.org/playground/ <http://json-ld.org/playground/>
>> Context:
>> http://thingschema.org/context.jsonld <http://thingschema.org/context.jsonld>
>> WoT Schema:
>> http://thingschema.org/wot.jsonld <http://thingschema.org/wot.jsonld>
>> Domain Schema for light:
>> http://thingschema.org/light.jsonld <http://thingschema.org/light.jsonld>
>> Model for light:
>> http://thingschema.org/lightmodel.jsonld <http://thingschema.org/lightmodel.jsonld>
>> In my demo, the model is used to construct the hypermedia controls for the resources 
>> the server exposes which implement Events, Actions, Properties, and Capabilities. 
>> The client only needs the hypermedia controls, but may use the schema if needed to 
>> help identify terms and relationships in the hypermedia controls.
>> The developer only needs to know JSON and the keywords in the context and schema like 
>> “actions” to define models, and the application script developer can use terms from 
>> the schema to drive discovery.
>> The schemas are actually ontologies with simple typed links “mayHave" and “usedBy”
>> but could of course be enriched with additional relation types.
>> This is one of a few topics I will be demonstrating next week.
>> Best regards,
>> Michael.

Received on Monday, 25 January 2016 22:29:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:54 UTC