<kaz> scribenick: Mizushima

Agenda

Sebastian: (goes through the agenda)
... in person TPAC is canceled

last minutes

<kaz> May-8

Sebastian: Last minutes is approved and will be published

TPAC 2020

Sebastian: W3C decided to cancel TPAC2020

Kaz: physical meeting is cancelled and will be an online meeting, but we still need to respond to the logistics questionnaire..
... ... so we must decide what important sessions (e.g., joint sessions) are.

<scribe> scribenick: kaz

Repo logistics - render script

Kaz: so we could handle the main text and the table part, which is automatically generated by the script.sh, for a while
... and could update the table later based on the HTML tags

Victor: yes

Issues

Issue 900

Daniel: suggestion to add an additional option of "description" field to identify what each link does

Web Linking (RFC8288)

Koster: there are many registered "relation-type" at IANA

<victor> https://www.iana.org/assignments/link-relations/link-relations.xhtml

Sebastian: "license" information would be ok
... but for human-readable purposes, what kind of information to be handled?

<Mizushima> kaz: Is there user case ?

<Mizushima> ... technically is ok, but use case is important

Kaz: could you elaborate a possible use case a bit?

example comparison for switch-enum-type.sdf.json

Daniel: shows an example TD

Sebastian: but I'm a bit confused
... is it enough to add "description"?

Daniel: maybe doesn't need to identify all the features
... so adding "description" seems to be valid to me

Sebastian: Victor, can you provide some example?

Victor: ok

<sebastian> https://github.com/w3c/wot-thing-description/issues/900

Issue 903

Sebastian: would like to talk about the OneDM example next
... related to the SDF example at: https://github.com/mjkoster/ODM-Examples/blob/master/test-definitions/switch-enum-type.sdf.json

Koster: application level semantics
... SDF is designed to capture the semantics for a lot of existing device definitions
... there is a spreadsheet including 13 definitions
... SDF as a common mechanism
... could do with schema.org for application schema
... we have ODM object corresponding to TD
... TD template can correspond to the object
... contain all the interaction affordance
... (looks into the example)
... odmProperty, odmAction, odmData
... SDF also has a feature to composition internally
... reusing the data type like "StateData"
... there are more examples there
... making the file smaller and linking to get the details
... would like to decouple the semantics from the concrete data type, e.g., enum

Daniel: trying to convert this to TDT
... but within the odmData area
... there are multiple definition for switch
... possible name collision there
... we don't have this level within TD
... action and property are the same level
... but why only "odmData" has yet anther nested level?

Koster: you can create a standalone definition of action/event/property for some particular function
... it allows you and the model to isolate individual functions
... and put all the affordance together
... we would like to convert this notation to iot.schema
... but there is also some problem
... probably you would convert "On" to "switchOn", etc.
... you could use "switchAction", etc., as well
... and could another layer for the conversion
... in the real world there are multiple levels

Daniel: I indeed named "On" as "switchOn"

Kaz: would like to suggest again that we continue the discussion based on some specific use case

<Zakim> dape, you wanted to odmObject with action/properties/events

Daniel: encountered two issues

[[
"odmData": {
  "StateData": {
    "odmEnum": {
      "On": {
        "type": "string",
        "const": "on",
        "description": "The on state"
      },
      "Off": {
        "type": "string",
        "const": "off",
        "description": "The off state"
      }
    }
  }
}
]]

Koster: good information to see you sort it out
... any other way to add type for enum?
... missing semantic anchor
... interesting question on how to handle it
... on/off could be 1/0 or true/false
... or anything non-zero
... that would have to go into the TD as well
... not a whole difference

Sebastian: one of the advantage is one-of is already standardized within json.schema

Victor: my main question is
... if you have a model for a specific instance for events
... what is the future of iotschema happen?
... still active?

Koster: iotschema is still active and will have a meeting next week
... create this vocabulary to annotate descriptions like TD
... collaboration just happening with ODM
... want to converge all the possible models including zigbee and bluetooth
... the project should happen including all the stakeholders
... bringing it back to iotschema, we still need to handle extension for schema.org
... still need some engineering

Kaz: really would like to repeat we continue the discussion based on a concrete use case with some concrete device/app setting so that we can clarify what to be done on the ODM side and what to be done on the TD side

Sebastian: wondering about who is leading the discussion on the ODM side

Koster: ODM is not an organization but a liaison
... some resources are on the playground site

ODM Playground

Koster: we don't have any namespaces within the playground yet

Kaz: that's why the attribute names themselves say "odmSomething"

Koster: yeah, so it's a bit confusing
... should be based on the SDF model instead of ODM

Sebastian: this is the first shot to see the similarity and difference
... btw, there will be a WISHI workshop meeting today
... would be useful to let them as well know about this survey

Daniel's survey (revisited)

Daniel: for example, we don't have features for "odmData"

Sebastian: possible to describe using SHACL?
... expressing multiple occurrence

<inserted> Sebastian shows Issue 898

Victor: yes

Sebastian: good to start this discussion
... though we need some concrete use case description as Kaz suggested

Hypermedia control

<sebastian> https://github.com/w3c/wot-thing-description/tree/master/proposals/hypermedia-control

Issue 899

Victor: the main problem is
... illustrated here in the "Use Case Example" section
... (explain the data transfer sequence)
... there is no concrete feature for this behavior
... my proposal is very much inline is some proposal at IETF
... hypermedia control between the agend and the consumer
... (hoes the example TD code)
... several formats there
... Proposal: Piecewise Consumption of TD

[[
[
  {
    "href": "/fade/1",
    "htv:methodName": "GET"
  },
  {
    "href": "/fade/1",
    "htv:methodName": "PUT"
  },
  {
    "href": "/fade/1",
    "htv:methodName": "DELETE"
  }
]
]]

Victor: "/fade/1" could be used for GET, PUT and DELETE
... the idea is a TD possible consumed more than once
... there should be some protocol for negotiation
... but the essential idea is that a TD possible could be consumed more than once
... it's up to the consumer to make decision

Ege: in the action and level of "fade" within the TD, could we specify that?

Sebastian: this is about the runtime behavior?

Victor: yes

Koster: generate indication of the document is handled?

Victor: it's really the same as the standard hypermedia control
... this is something well-known
... would like to apply that mechanism to TD

Koster: a fragment of TD can be handled?

Victor: yes, that's possible
... as long as the proxy exposes a full TD

Koster: if more than action is exposed

Victor: yes, that would be OK

Sebastian: what kind of new definition to be added to TD?

Victor: we can do without any changes
... if consumers can handle this example

[[
[
  {
    "href": "/fade/1",
    "htv:methodName": "GET"
  },
  {
    "href": "/fade/1",
    "htv:methodName": "PUT"
  },
  {
    "href": "/fade/1",
    "htv:methodName": "DELETE"
  }
]
]]

Sebastian: but how to handle using TD?

Victor: to me it doesn't have to be known
... no need to mention at the beginning

Kaz: it would be helpful to explain the background the expected use cases

Sebastian: this is a kind of old issue and derived from the proposal from Ben on WebThings using the Oracle cloud

Kaz: in that case, it would be easier to understand we mention the fact and think about this proposal based on that

Sebastian: it seems this proposal requires an addition of "fade" to the "actions" feature

Victor: (goes back to the example TD)

[[
{
  "@context": "https://www.w3.org/2019/wot/td/v1",
  "id": "urn:ex:thing",
  "actions": {
    "fade": {
      "input": {
        "type": "number",
        "description": "duration (in ms)"
      },
]]

Sebastian: would suggest everybody read this proposal again
... also revisit the background and the use case
... then let's continue the discussion next week
... aob for today?

(none)

[adjourned]