Meeting minutes
Minutes
<kaz> Mar-1
Ege: the minutes look good
Kaz: Jan needs to provide his points for one part. So let's revisit the review next week after getting clarification from Jan.
Charter Related Topics
Versioning
Ege: css has an interesting mechanism about feature dependencies
TF Lead
Ege: there was discussion about WG Chairs during the Charter discussion
… and McCool and Sebastian mentioned it would make sense to think about TF leaders as well
… are there any opinions
Kaz: as mentioned during the Charter meeting, we should separately talk about this, because TF leads can be assigned by the TFs themselves.
Daniel: discussion on Chairs is done during the main call today
… maybe it would be make sense to have discussion about TF leads in general now
<Mizushima> +1 kaz
Kaz: yes, we can have discussion during this call ourselves as part of the TF agenda :)
… but we don't need to and should not bind this topic with Charter discussion
… my only suggestion is you talk with Koster about the Binding part
Koster: If this call continues as a combined activity, I'm also interested to be a (co) TF leader
Ege: if anybody else is also interested, please let us know
Versioning - revisited
Ege: we'll keep adding features
… so the question is how to deal with the combination of related specs
… and looked at CSS versioning policy
… (refers to the section of "LEVELS 1, 2, 3 AND ABOVE")
Kaz: note that this is not an issue on "the WG Charter" but an important issue about the W3C WoT spec family. Having discussion during this call itself is fine, though.
Ege: right
Daniel: we should have our own policy in any case
… if there is breaking changes from the compatibility viewpoint, we should use major version up for the new version, e.g., 2.0
Ege: implies there could be some changes without compatibility for the major version up
Daniel: right
Kaz: note that there are two related but different issues here
… 1. TD version itself, e.g., TD 1.0, 1.1, 2.0
… 2. version for compatible WoT specs at some point
Ege: right
Kaz: we could start with putting those two issues as the starting point
Ege: agree this issue should not be tied with the Charter discussion
Koster: want to verify we would be asking people who refers to the registry of binding about major revisions but should not bother about the minor revisions
Kaz: would be good to record those points as "initial viewpoints"
Ege: ok
… (records the points)
<Ege> w3c/
Minutes review - revisited
Ege: would like clarification from you for the previous minutes
Jan: can send concrete text to fill the "@@@" part
Kaz: ok
… assuming that clarification, we can approved the minutes
(minutes approved)
Binding Templates
PR 246
<Ege> PR 246 - Generate CoAP vocabulary from RDF
Jan: some progress here
… JSON-LD context
… also some semantic updates
Ege: Klaus, any opinions?
Klaus: may I share my screen?
Ege: sure
… (shows the CoAP Binding ED on the left side; the file changed on the right side)
… bunch of new files coming in
CoAP Binding Template ED - 4.1 Form terms
Jan: related to general question on the conversion mechanism
Kaz: what's the mechanism you used to generate the HTML from the TTL file?
Jan: edited the coap.ttl file by hand
… then using the template.sparql to map the terms from coap.ttl to index.html
… followed the mechanism used for MQTT and HTTP
Ege: adopted to the mechanism which is used for TD
Kaz: similar or exactly same?
Ege: not exactly same
… but added necessary configuration changes
… btw, it would be better not to define the ontology ourselves
… would like Klaus to look into the detail
Klaus: this TTL file should include the vocabulary for the binding mechanism itself
… not bigger or less than that
Jan: can remove extra part
… for actual binding purposes
Ege: once an ontology is published, the developers can understand what is necessary
Klaus: let's make it simple
Koster: we have overlapping of two knowledge domains
… IETF has terminology definition about CoAP
… we could create a familiar knowledge layer, though
… binding should simply refer to the CoAP vocabulary
Klaus: we originally had a vocabulary document for HTTP in RDF
… we need to describe the expectation on the other side on a device
Koster: would agree with the approach
… we're creating a best practice on how to refer to the CoAP vocabulary. right?
… ASHRAE provides BACnet vocabulary. right?
Kaz: we should remember our basic policy that we should refer to the existing vocabulary defined by the original SDOs, e.g., IETF and ASHRAE.
… the question is what if the original SDO is not available any more
Koster: right
Klaus: (goes through the "Files changed" for coap.html)
Klaus: we don't really handle the RDF vocabulary used by the original SDO's standard like BACnet
Ege: we just need smaller part of the original vocabulary
… but we need to define some additional terms too
Klaus: maybe we need to look into concrete cases
<Ege> https://
Kaz: btw, we're out of time technically
<Ege> https://
Kaz: would like to suggest we merge this PR 246 itself for further discussion
Klaus: would prefer not merging this now
Kaz: in that case, I'm OK not merging this PR now
… but probably it would be better to continue the discussion next week
Klaus: will not be available next week...
Ege: March 22 instead?
Klaus: ok
Ege: would think about the vocabulary creation guide as well
Issue 216 - Instructions on how to create a vocabulary and publish should be provided
Issue 232
Ege: (goes through the check list)
Issue 255
Issue 255 - A diagram to help understand what is happening in operation mappings.
Ege: would be better to have a diagram on the operations for Binding
… generated an initial description
… and got comments from Daniel
Koster: would like to look into it
… can be improved based on this direction
Kaz: agree
… starting with a TD excerpt is good
… we could describe the interaction sequence based on this
… when the Consumer gets what from the Device side
… and when the Device respond to the Consumer based on the request from the Consumer how, etc.
Ege: ok
<Mizushima> +1 kaz
Issue 238
Issue 238 - Clarifying Binding Mechanism
Ege: As Kaz mentioned, it's a bit difficult for readers to understand the whole binding mechanism
… so trying to clarify related information within related specs
… like TD and Architecture
Koster: TD spec describes how to describe the Thing Description (and forms element within it)
… we could refer back to the existing descriptions
Ege: yeah
… TD defines kind of detailed mechanism
… we can refer back to the Architecture as well
Koster: we can say this section from this spec describes this and that
… TD's Binding Templates section also can refer back to the Architecture document
… regarding the mechanism around Binding
Ege: yeah
… it would be better to improve the whole document structure so that people can understand the mechanism easily
AOB
Ege: any other topic for today?
(none)
[adjourned]