Testing

Sebastian: Kaz is concerned about testing, Taki do you know more?

Taki: kaz was asking if testing is a topic today.

McCool: I can give an update on testing
... we met yesterday (McCool, Taki, Ege, Mizushima-san, Dave and Kaz)
... there were a lot of ambiguities in the assertions
... will create a PR with improved assertions
... planned to have an update next week
... testing stuff is updated to use Victor's framework
... will provide another update next week

Sebastian: would appreciate support from people that have experience with testing (kaz, mc, etc)

McCool: Dec 4th Kaz will have a meeting with W3C folks to clarify testing requirements - after that it will be clearer
... will clarify the language

Sebastian: Taki, can you also participate in the testing call and sync the TD spec to clarify unclear definitions?

Taki: yes, will continue to participate

Update on TD spec

Sebastian: Victor created new diagrams, directly generated from ontology and validation files

<McCool> I should mention a clean-up change I made was to add the .dot files to .gitignore but the .svg to the checkin list (even though they are generated, so is index.html, and the .svg files are needed to render the page, so...)

Sebastian: the layout could be better, but we can manually improve once the ontology is stable
... diagrams give us another way to validate the ontology
... question: cardinality of the terms is not part of the diagram, we do not see if things are mandatory - do we need a different representation?

Victor: I want to be as close as possible to UML - there's no cardinality on attributes, so I removed the numbers inside the classes

Sebastian: what about mandatory annotation in the table?

Victor: also not part of UML

<McCool> what I meant is that the current diagram is consistent with the tables since the tables also do not have cardinalities

Sebastian: I found a bug: id field is missing

<McCool> but use array, mandatory, etc.

<McCool> so I think this is better

Lagally: victor, how is this diagram created

Victor: from shaql shapes

Maxime: there may be some differences, e.g. singular vs. plural
... better generate diagrams from ontology or directly from JSON schema

Victor: singular should not be aproblem, have not seen a structural difference

Maxime: there may be problem with id

Victor: it is just an alias for @id
... for types it is the same thing, would be just an alias

Sebastian: diagrams are used to illustrate the relationship of terms for the reader, details are in the subsections

Maxime: it would be better to be generated from the JSON-schema, since it is part of the document
... are the shapes online?

Victor: yes, in the folder validation

McCool: I like the new figures, less confusing. JSON schema in appendix needs to be in sync with the ontologies, autogenerate is feasible?
... need an issue for that

Sebastian: will ask Ege for that

Victor: depends on capabilities of the framework

McCool: autogeneration would be safer
... we write some JSON schemas for validations, not sure Ege can work on that.

Victor: mc, you also changed the templates wrt to assertions

McCool: yes
... perhaps somebody with experience with shapes can help

Victor: Dave Raggett?

<McCool> (someone needs to go on mute; the issue is echo)

Lagally: diagrams are a big improvement, we need to make sure that the JSON schema in the annex is correct. Autogeneration is preferred to avoid errors

Matthias: +1 on diagrams, if we generate JSON schema it gives us another way to validate as an additional path for validations and check it against the shapes, we have a better chance that it is correct
... suggest to keep the JSON schema as an alternative path, but have some automatic check to validate the JSON schema against the shapes
... if we have two paths we would spot mistakes (such as the id field)

Sebastian: unclear why id filed does not show up
... perhaps not in sync
... thanks Victor for providing the diagrams

Closed issues

Sebastian: was hoping to get responses on issues under review, please review issues with label "Needs review" and give feedback.
... there are some quite old issues
... please review and give feedback
... some recent changes:
... response field with response content type

Matthias: I just spotted a bug in the example, it still has MediaType

Victor: response corresponds to a request form, can we change the name?

Maxime: in Swagger they use request body and responses, responses is an array

Victor: I'm fine with the filed name response, but the class name could be changed

Matthias: +1: keep response in the TD but call it "expected response" in the class name

Victor: Maxim mentioned Swagger, perhaps rename form to request form
... just rename the class name

<McCool> (I'm not convinced making the class names different from the names in the TD is a good idea; I would personally just stay with "Response")

Sebastian: form can also be used for responses

Matthias: form is not describing responses entirely
... fields in the form also provide values for the response, but the form is not describing response but request

Sebastian: what do we conclude?

Matthias: suggest to keep the issue open and give people some time to comment

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

next issue:

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

Sebastian: null schema was introduced in spec, please review

issue: 310

<trackbot> Created ISSUE-4 - 310. Please complete additional details at .

next issue: URI type

dape: was not aware of the URI type, am not convinced, will provide a comment

Sebastian: please review these "Needs review"

Lagally: please merge my PR on thing templates

Victor: ok

Semantics

Victor: it is about what information should be in TD document and what should be externalized
... I worked with Maxim and Maria, Maxim, can you present what you did on our branch of the TD document

Maxime: we forked TD into wot-td-ontology about 2 weeks ago, when were asked for a draft of a group note
... removed all JSON-LD 1.1 and RDF. refernces and externalized it to an external group note

<mlefranc> https://wot-td-ontology.github.io/wot-thing-description/

Maxime: left only JSON as serialisation format, removed various complicated sections and just referenced the group note
... document is based on semantic networks document, will look similar to that
... we started work but document needs additional effort, there'S a lot of editors notes
... maybe we have to define subproperties for observable vs non observable
... there are some terms that might be defined to link RDF terms like properties to things outside the namespace
... we had 2 different group meetings with Maria Victor and sometimes Lyonel
... Victor should describe section 3

<mlefranc> https://wot-td-ontology.github.io/wot-thing-description/ontology

<mlefranc> repository is here: https://github.com/wot-td-ontology/wot-thing-description/

Victor: I started drafting an algorithm to transform a JSON object to JSON-LD in chapter 3.1
... main goal is to generate @id and @type for every object in the TD

Maxime: there is no global JSON-LD context that models the entire ?. We would not need a reference to JSON-LD 1.1.
... If someone receives a document, he could apply the algortihm for JSON LD 1.0

Sebastian: thanks for creating the document, but I'm concerned, since we want a TD spec that includes the semantics. We agreed to move away from JSON-LD 1.0, since it is not very Web-like.
... TD spec is right now very close to JSON-LD 1.1. Standardisation of JSON-LD 1.1. has some issues
... we want to be at least compatible with JSON-LD 1.0, so we need a conversion to JSON-LD 1.0
... we also want to use terms from json-schema.org
... integrate with the @context mechanism
... we are currently not compatible with JSON-LD, want to have a note how to generate JSON-LD 1.0
... I'm concerned if we remove all wrt to semantic annotations out of TD spec

Maxime: external document describes the semantic annotations
... we have a natural TD in JSON, plus extensible JSON-LD 1.0 serialisation

Sebastian: serialisation looks completely different, array definition style, which is not liked by Web developers

Maxime: you don'T need to use arrays, don't understand the concers

Matthias: this is just a processing step. Assumption was to feed document into JSON-LD 1.1 processor
... we can only reference other existing recommendations
... we can used JSON-LD 1.0 processors, people can still used JSON-LD 1.1. processors if they know what the are doing

Victor: annotations should also be in the JSON TD to make sure they are available for the generated document

Maxime: we still have discussions of how the annotations are handled, that would be embedded in the TD document. There is a preprocessing step needed anyway, perhaps JSON-LD 1.1 will help to avoid that
... at this point a JSON document is more natural

Lagally: what is the timeline of this document? same as TD spec?

Maxime: we are not a recommendation, just a group note, that can be published based on a vote, not the publications steps of a recommendation

Lagally: there's a reason for the W3C validation process of a recommendation, the quality of this document might be different
... is this document binding for a TD implementer

Maxime: it is not, the TD spec can be implemented without using this document, other ways for semantic annotations can be also used

Lagally: thanks for claifications

Sebastian: proposal to change TD spec: keep the JSON-LD key terms (@id, ...) in the document and permit new terms that are defined anywhere else.
... we can't be compatible with JSON-LD 1.1., so we just point out that we have a TD format with keys form JSON-LD 1.1 and an implementation node, to describe how to make a TD compatible with JSON-LD 1.0
... we call it our own TD format with similar features from JSON-LD

Victor: how to deal with protocol bindings? these are modelled as semantic annotations.
... we could define them as exceptions

Sebastian: points to HTTP group notes

Matthias: Kaz confirmed that we can point to this kind of documents

Sebastian: binding terms can be defined in separate documents

Maxime: binding documents can describe annotations for actual protocols
... we will simplify TD spec to remove RDF and JSON-LD and just mention external documents

Sebastian: why not keep @context in TD spec

Maxime: how do I know that I have to do a preprocessing step

Sebastian: implementation note

Maxime: a human receives a document with a content type, knows that he has to do a preprocessing step

Sebastian: preprocessing is always done, when there is semantic info
... we need an implementation note for JSON-LD 1.0
... hope is that when JSON-LD 1.1 is available we will be compatible
... there should be an implementation note with examples with semantic annotations
... point out that we define our own format
... need to review the branch provided by Maxim et al

Matthias: extension mechanism for TD should be part of the TD spec - branch deleted too much
... take the branch as a guideline, but do alignment in the master branch
... extension mechanism needs to be defined in the TD spec, Maxim, do you agree

Maxime: yes
... walk over all changes and determine what to apply to the master branch

Matthias: algorithms should be added to section 6
... description of JSON-LD 1.0 transformation, also a note about experimental 1.1 serialisation

Maxime: we can just refer to JSON-LD, without a number (1.0/1.1)

Matthias: we should clarify the algorithm for both
... extension vocabulary must be published as JSON-LD context

Lagally: do you have to declare all additional vocabulary in an @context

Matthias: yes

Lagally: so every manufacturer, who wants to introduce vendor specific metadata keys needs to create an additional context file?

Victor: you could also embed the vocabulary in the TD
... an external file would be unneccessary overhead

<mlefranc> semantic annotations SHOULD be inserted using additional keys and values whose semantics is specified in a JSON-LD Context that is exposed on the web, whose URL is added to the general '@context' of the JSON-TD document

Lagally: so this can be interpreted as "semantic annotations MAY be inserted without specifying them in a JSON-LD context, but could be also be directly included in the TD"

Matthias: you would have to go via iot-schema.org
... let's discuss offline.

Lagally: there's an issue for that

Sebastian: I will review Maxim's branch

Victor: we can create a PR and you can review

Sebastian: when?

Victor: now

Sebastian: you removed too much, we already discussed changes, please update your PR
... include the outcome of today's discussion

Maxime: I can work on that but need more time.

Additional issues

Sebastian: please review the other issues from today's agenda
... will not moderate next week's call due to a business trip. Taki, can you take over?

Taki: yes

Sebastian: please also look into the testing topic
... we made big progress today, meeting is adjourned