Payload pattern binding

[sebastiankb]

I know this is not a new issue, but I think it is a good time to address this challenge now:

In WoT we have a process to define bindings for protocols and data serialization. In the last TD call, we found that it would also be good to introduce a formal way in which we can define some kind of binding for payload patterns. This is useful if the payload messages constantly contain data elements in addition to the actual property, action, or event value. A simple example is, that a temperature property will have a temperature value and a timestamp. Other property definitions like humidity and wind speed will also always come with a timestamp. Of course, we could simple define this within the data schema each time, but this can be annoying when there is a couple more data elements than the timestamp.

How such a formal definition would look like when we would follow the payload pattern of SenML as example (@Citrullin, @JKRhb)? Would be this a kind of a new binding document, an official JSON Schema definition, or kind of a new specific WoT Profile? What do you think?

[Citrullin]

I read the SenML spec and there are some instances where the TD can improve some parts and reduce the data transmitted.

An SenML example

   [
     {"bn":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,
      "v":23.5},
     {"u":"Cel","t":1.276020091e+09,
      "v":23.6}
   ]

bn is the base name and can be omitted according to the spec "All base fields are optional. Regular fields can be included in any SenML. Record and apply only to that Record."
Therefore, it would make sense to use the wot TD id instead.

When it comes to regular fields, the unit is included in the record and could also get removed.
"Unit: Unit for a measurement value. Optional."
-> Define over TD -> InteractionAffordance -> forms -> additionalResponses -> schema -> unit

@relu91 had a good point. Additionally to the content-type, we could also add a value to subprotocol in order to make it more explicit. That or another mechanism, in order to indicate that the data have to be interpreted in a slightly different way.

I don't know what fits here the best when it comes to specification/document.

[egekorkan]

We can use schemaDefinitons, define an object for the common terms. Then in each affordance, this schema is referenced and then extended with affordance specific terms. Other options of going towards new subprotocols raise interoperability concerns for me.

[sebastiankb]

subprotocol would always work, however, should be kind of standardized to improve interoperability.

schemaDefinitons is a good option as well and I would propose this should be enabled in the spec. So far it is only limited for AdditionalExpectedResponse definitions. A disadvantage would be the reusability. Each Thing that like to rely on SenML have to define schemaDefinitons again. Maybe we should allow to import such definitions by external JSON Schema files?

[sebastiankb]

From today's TD meeting:

{
  "@context": "https://www.w3.org/2019/wot/td/v1",
  "title": "ediTDor Thing",
  "id" : "urn:dev:ow:10e2073a01080063",
  "securityDefinitions": {
    "nosec_sc": {
      "scheme": "nosec"
    }
  },
  "security": "nosec_sc",
  "properties": {
    "temperature_indirect_SenML": {
      "title": "temperature",
      "unit": "Cel",
      "type": "object",
      "properties" : {
          "t" : {"type": "number"},
          "v" : {"type": "number"}
      },
      "forms": [
        {
          "href": "/",
          "contentType": "application/senml+cbor"
        }
      ]
    },
    "temperature_direct_SenML": {
      "title": "temperature2",
      "type": "object",
      "properties" : {
          "b" : {"type": "string", "const": "urn:dev:ow:10e2073a01080063"},
          "u" : {"type": "string", "const": "Cel"},
          "t" : {"type": "number"},
          "v" : {"type": "number"}
      }
    }
  }
}

We decided to have some implementation experience during the next PlugFest and revisit this issue again. Maybe @mjkoster can share some TDs that uses SenML.

[lu-zero]

It is a good use-case for a DataMapping that maps information outside the affordance data schema (the Thing::id is mapped to the b field).