<kaz> scribenick: McCool

Logistics

next week no TD call

as noted in agenda

next TD call will be Friday 21 April

repo reorg

<scribe> new repo only for TD

suggest all issues related to TD should go in new repo

w3c/wot-thing-description

<kaz> from: https://github.com/w3c/wot/issues to: https://github.com/w3c/wot-thing-description

existing TD issues moved, eg binary description

<kaz> https://github.com/w3c/wot/issues/307

issue with not very clear description of data types

type definitions seem to be overly complicated... there is alternative proposed

however, existing format allows for semantic tagging

Sebastian points to discussion on github for details... JSON Schema interactions

have contact with JSON schema group

should like to add new item to JSON Schema definition to add semantic annotations

<kaz> issue-290

maybe makes sense to initiate proposal with JSON Schema group

would like to have concrete proposal for Osaka F2F, so we can make a decision

first step: ask for volunteers to work on a proposal

in past had a subgroup to work on data type definitions...

Daniel: proposing different approach

feel they are the experts, so...

perhaps start the discussion first in an issue

can still do a proposal, but first we should see their stand

then we can determine best way to move forward

sebastian: most important thing is to start discussion (with IETF group?)

perhaps we make a small example and start the discussion this way

andrew already has a good understanding of what we would like to have

we are not experts, but we should work together with them on this

still makes sense to pick a subgroup

Taki and Daniel ok?

Taki: so where should we start?

andrew aware of us at Santa Clara mtg, but nothing has happened so far

Sebastian: github issue would be a more formal way to move this forward (rather than the mailing list)

kaz: which group?

<dape> https://github.com/json-schema-org/json-schema-spec

can andrew simply join *this* group

Sebastian: thought we would create issue in JSON schema group

we are asking them to modify JSON, so it makes sense to make the proposal/issue on their group

kaz: we should decide what core issue is

then we should enter it on their system, then track it with an issue here that refers to the issue on the JSON Schema group

kaz; we should come up with a specific use case

that needs these issues

Sebastian: can refer also to current practices document, issues on TD

example is that we would like to integrate semantics into the data type definition itself

in addition, would be useful to have Victor in the loop

he may have some suggestions on how to do this integration

Sebastian: this is just a starting point to the discussion

Daniel: so this path means we will not change this before the Osaka meeting...

what version of TD should we use for Osaka mtg

Sebastian: realistically, no time to make change to data type definitions

only have about 4-5 weeks left before F2F

need stable version 2-3 weeks before

so we need to nail down version for Osaka by end of April: 24 or 25

only about 2 weeks left for any new implementation

and... no meeting next week

probably no change in data types for Osaka meeting... but afterwards, if we can coordinate with JSON Schema group, can come up with concrete proposal for next F2F in Germany

Sebastian: for Osaka, want concrete and stable TD model

comments? Group agrees

sebastian: want clear model written up by time of F2F

TD model discussion

some points of discussion in agenda, Maria's model

(brings up Maria's model in slide)

however... want to modify a few things

first thing, Sebastian wants to remove relative Endpoint

href can already be a relative path

other things already listed in the agenda

next point: default value definition, remove

it has impact on the data type definition, should be defined there (eg in JSON Schema)

no need to do it at the property level, can be done at the data type level

also, suggest removing the differentiation between physical and virtual thing

but causes problems with Things that have aspects of both

next, ask to change how communication metadata is defined... protocol bindings, how does this apply here?

Sebastian has asked Matthias for input here

next, Sebastian would like to change data format class to just data type; make note that we are relying on JSON Schema definition

also need to define namespaces; Maria used her own, we need a more official namespace from the W3C

we need our own namespace that is unique to TD... need to decide how to do

and we should look for things we can reuse, eg href

from other namespaces

or rdf:label for names

need a clear list what is really "new" for WoT

Sebastian: Darko, would you be willing to look in to this?

Darko: yes, willing to work with Maria on these issues
... few more comments
... what about communication patterns and security data here
... other thing is Data Format... Sebastian says there is already a CR

Sebastian wants to point to schema, so would just change this, and rely on JSON Schema

Sebastian: reiterates that it would be good to identify namespaces that are unique to WoT
... for other stuff, should indicate what other namespaces should be used; make a table or something

Dave already looked into this

Darko: yes, we need to talk to Dave about this

McCool: security aspects can be handled similarily to protocols

let's just add a placeholder for now

McCool: second point, adding semantics to JSON Schema useful for other applications, eg OpenAPI

Sebastian: please queue up any additional issues on the new repo

Also, want to generate new diagram to discuss in the next meeting...

then will take this model to the Osaka meeting

Sebastian: this is the plan; ok with people? Silence... taken as assent.
... see you all in two weeks!

<kaz> [ adjourned ]