AW: Thing Description and thingschema

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




Von: Michael Koster [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


which is also mapped to 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",
 "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> _:b1 .
_:b0 <http://www.w3.org/2000/01/rdf-schema#label> "light" .
_:b1 <http://thingschema.org/name> "light" .
_:b1 <http://thingschema.org/schema#hasCapability> _:b2 .
_:b1 <http://thingschema.org/schema#hasCapability> _:b7 .
_:b1 <http://thingschema.org/schema#hasCapability> _:b9 .
_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://thingschema.org/light> .
_:b10 <http://thingschema.org/name> "change" .
_:b10 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://thingschema.org/change> .
_:b11 <http://thingschema.org/name> "move" .
_:b11 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://thingschema.org/move> .
_:b12 <http://thingschema.org/name> "step" .
_:b12 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://thingschema.org/step> .
_:b13 <http://thingschema.org/name> "currentBrightness" .
_:b13 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://thingschema.org/currentbrightness> .
_:b14 <http://thingschema.org/name> "targetBrightness" .
_:b14 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://thingschema.org/targetbrightness> .
_:b15 <http://thingschema.org/name> "moveBrightness" .
_:b15 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://thingschema.org/movebrightness> .
_:b16 <http://thingschema.org/name> "stepBrightness" .
_:b16 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://thingschema.org/stepbrightness> .
_:b17 <http://thingschema.org/name> "transitionTime" .
_:b17 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://thingschema.org/transitiontime> .
_:b2 <http://thingschema.org/name> "onOff" .
_:b2 <http://thingschema.org/schema#hasAction> _:b3 .
_:b2 <http://thingschema.org/schema#hasProperty> _:b4 .
_:b2 <http://thingschema.org/schema#hasProperty> _:b5 .
_:b2 <http://thingschema.org/schema#hasProperty> _:b6 .
_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://thingschema.org/onoff> .
_:b3 <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/


Context:
http://thingschema.org/context.jsonld



WoT Schema:
http://thingschema.org/wot.jsonld



Domain Schema for light:
http://thingschema.org/light.jsonld



Model for light:
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.