<kaz> scribenick: Victor

(Waiting a few minutes more...)

Logistics

Sebastian_(SK): let's start. Goal here: discuss TD structure more in details. First of a series of telcos until next PlugFest (February)

SK: more precisely: around 5 telcos, then time for implementation until February.

<kaz> TD Restructuring proposal

Problem statements

SK: Motivation to restructure TD: feedback provided during PlugFests, on Github and by external organizations (OCF, BIG IoT)

<kaz> TD Restructuring proposal (revisited)

1. when to use properties/acton/event?

see https://github.com/w3c/wot/issues/247

not only related to TD.

2. properties/actions/events are not self-contained

<mlefranc> https://github.com/w3c/wot/issues/251

example: URI resolution if relative / different protocols or encodings at the interaction level (vs. thing level)

<Zakim> dsr, you wanted to comment on a process question

Maxime_(ML): question: RDFS range for "encodings" defined? If not, one can defined it as Thing or Property/Action/Event.

SK: should be possible.

<mlefranc> Dave: encourages the TD subgroup to adopt a more formal process

<mlefranc> use cases, requirements, .. prepare a solid ground for the WG

<mlefranc> part of this work has been started at the beginning of the IG

Dave_(DR): we should adopt a more formal approach here: update use case & requirements if we are about to change the TD. Example: many encodings and protocols across platforms, which ones are we addressing?

<mlefranc> +1 for Dave's proposal

SK: volunteers to work on that?

Kaz: we can do the following in parallel: 1. asking for volunteers to update the use case document itself and 2. providing proposals for TD Restructuring (during calls and on emails) along with concrete use cases

<mlefranc> Dave: this should be done in parallel

SK: idea of the PlugFests was to have quick iterations

<mlefranc> ... what is important is to be able to refer back to a decision to justify a feature

DR: this should be done in parallel

Daniel_(DP): should be possible to keep track of changes/proposals with concrete use cases and example notations.

Kaz: Wiki page to gather all propsals?

Matthias_(MK): having Github issues is maybe enough

<dsr> Dave thinks very few members of the IG look at the github issues, so that in practice results in only very limited scrutiny.

<kaz> Kaz: GitHub issues is ok and people are encouraged to add concrete usecases and examples

SK: what about regularly compiling the issues in a "changelog"?

Back to the queue. Darko?

<dsr> Dave thinks that it is important to keep requirements distinct, as JSON is just one possible way to represent metadata

Darko_(DA): previous point: relative URIs might be a limitation but they also have benefits, such as "templating" (only the base URI is changing between things)

<mlefranc> +1 for Dave's comment

SK: next in the queue

DR: we should really separate requirements from proposals. Should engage a discussion in the mailing-list

<DarkoAnicic> ACTION: Darko to create an issue: properties, actions, events can be saved in the TD repository separately as templates. A TD can be created based on a concrete set of them and instantiate with a concrete URI. In this settings, the current proposal with href makes sense. [recorded in http://www.w3.org/2016/10/05-wot-td-minutes.html#action01]

<trackbot> Created ACTION-77 - Create an issue: properties, actions, events can be saved in the td repository separately as templates. a td can be created based on a concrete set of them and instantiate with a concrete uri. in this settings, the current proposal with href makes sense. [on Anicic Darko - due 2016-10-12].

SK: Matthias proposed having first issues and then a summary document allows commenting on each topic

DR: one should be able to comment on the documents as well.

<kaz> kaz: thinking about how to record those two topics separately would make sense

Problem statements 2

SK: explicit vs. implicit knowledge

MK: OCF is using other methods than WoT for the same operations, we should be able to specifiy methods in the TD as well.

SK: second point, we should also refine spec. of encodings (define them at the interaction level, use media types)

ML: methodology? Who resolves the issues, who takes action?

SK: first proposal in a separate folder, then discussion during the calls until we reach agreement

ML: what about using PRs?

MK: precisions about our process: 1. proposal, 2. discussion -> consensus?, 3 integrated in the current practices doc (PR?)

ML: deadline on issues (like 1 month)?

MK: not sure it is a good idea: some issues have taken longer in the past (e.g. charters)

DP: precisions needed: from 1 issue, 2 were created during the discussion -> 3 issues now open that relate to the same one.

MK: one can reference issues from other issues. We should use similar labels (tags?). Common sense needed.

the person who opened the issue is supposed to track what happens and close it when required

Taki_(TK): possible to notify the mailing-list when an issue is open?

SK: you can also "watch" the repository (see Github)

Kaz: we encourage all to subscribe the "WoT" repository

<kaz> WoT repository subscription

SK: we should send an e-mail to the group pointing that out

MK: only summaries and clean reports should be sent to the mailing-list

more technical discussions should happen on Github

ML: from the experience of the Spatial Data on the Web WG (that duplicates every issue), the WoT process seems a bit better

MK: should be raised in our general call today

Classification

SK: for all issues mentioned here: restructuring/renaming/new vocabulary needed?

slides to be found in the proposal folder (Github)

First TD Restructuring Ideas

<kaz> Today's Basic TD Structure

<lmedini> Should we plan to provide mappings with other vocabularies, such as Hydra?

<kaz> Proposed Basic TD Structure

SK: maybe go back to the original TD structure? With key "interactions" instead of "properties","actions","events"

+ "encodings" and "url" defined for each interaction

<inserted> scribenick: kaz

lmedini: mappings with other vocabularies, e.g., Hydra?

sk: some discussion on Hydra during TPAC

-> https://www.w3.org/2016/09/22-wot-td-minutes.html#item02 Hydra breakout during TPAC

<kaz> scribenick: Victor

Victor_(VC): there is an action item pending regarding Hydra (I have to take). A separate discussion will take place soon

VC: I'll create an issue and add a proposal.

SK: (shows an example with the new structure)

<lmedini> Yes, thanks victor

key "endpoint" is added. interactions: [ "name", "endpoint": { "urls", "encoding" } ]

DA: how to provide kind of templates then?

<dsr> We should feel free to go beyond JSON-LD provided we give a means to map to RDF

<mlefranc> +1 for each of us

MK: it actually depends on the serialization (here JSON-LD). We should maybe focus on the "abstract" model instead

<lmedini> +1 for abstract model.

SK: then, how to continue? Which tools should we use to work on an abstract model?

ML: Protégé is a tool the Semantic Web community uses.

MK: one point: with using JSON-LD we had the hope to attract Web developers.

DA: at the beginning, we created an (OWL) ontology. But it got outdated quickly because of too many changes in the JSON-LD version.

<kaz> maxime: can help Victor for that purpose

Antoine_(AZ): what we should agree on is a rough structure for the TD. We could use Turtle for that purpose within the group. To the world, we should present JSON-LD examples

<DarkoAnicic> Darko: I am also willing to contribute on the Turtle model for TD

SK: agreement on working at a more abstract level?

Combining Turtle (internally) and JSON-LD (externally)?

action items to turn into issues on Github!

<kaz> [ adjourned ]