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
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
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
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.
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