Meeting minutes
Quick Schedule
Ege: updates on the toolchain, and binding registry
… next week Wednesday will be cancelled the call, but Thursday it will take place
Minutes
<kaz> Jan-15
Ege: Is there any issue regarding the minutes?
Daniel: I spotted a typo, "summurize"
Ege: "enconded" should be fixed to "encoded"
Daniel: maybe we should use a spell checker on this document
kaz attempts to fix the typos
Minutes approved
Toolchain
Mahda: I checked the LinkML repo to see if there are any updates
… there was an update on the JSON-LD generator
… I used to do post processing for it
… with inline properties in linkml, jsonld generator was not generating correctly
… so a PR fixed this
… however I will focus on fixing the JSON LD context file. So not about the tooling.
… fixing the handwritten context file and contacting the JSON-LD group
… if you want to participate, just ping me and I can invite you
Ege: I would be interested
Mahda: anyone else?
Jan: I would be also interested
Ege: this shows that our post processing until it is not needed is a good idea
Binding Registry
https://
Ege: This contains all our requirements and process, we have some updates that I will show. We focus specifically on the inclusivity
… we should seperate the two points as mentioned by McMool
<kaz> Feedback from the main call on Jan 29
Ege: and Sebastian mentioned that we should accept everything, even if the binding cannot be reviewed
… ideally the technical discussion should happen in this call (TD TF)
<kaz> Cristiano's comments
Cristiano: I commented in the PR, we forgot about an important thing, interoperability. How much these choices will affect interoperability. Sccepting everything seems good, but what if some closed implementation creates an island and creates a specific dialect and create interoperability issue
Ege: do you mean two implementations that conflict with each other? Do you mean the real software?
Cristiano: yes, probably it all nails down to create a good specification, so that even if the binding is not provided you would still be able to interoperate, but depends on how the interface is implemented.
… at the end we do not know, they might create islands, and I don't know whether we want this. We need to write some text in the spec to address this
Ege: The problem is easier avoid with things that are public, but it can still happen, for instance different implementations of modbus
… I think it would reduce the quality of the bindings, my point of view is to stick to the reviewers being able to review the document, event if it is paid. I am guessing that is not a big deal
Cristiano: +1
Kaz: from my viewpoint, this discussion itself is a bit vague, the point is rather that we should as WoT TD task force clarify the basic requirements so that we can get the whole WG consensus. For that purpose we need to clarify what we mean by "everything" here, i.e., which part or which resource, and what to be marked royalty free.
Ege: maybe what we can do right now is to quickly copy the comments from the different places in GitHub into one place
Kaz: for example, if there are still 6 or 7 points to be clarified, those points should be discussed as seperate issues
Ege: The problem is that the numbering for the remaining questions could change when carried over
Kaz: maybe it makes sense to add some concise title to each part or put a subsection to each question so that we can refer to each question easily.
Ege: I will give some names to each section
Kaz: my suggestion is inline what you are thinking about, Ege
Ege: Yes, I think so
Daniel: I agree that we should be clear on what we mean, but it seems that there are different opinions and it's hard to later on change based on this or that, because we cannot foresee everything now, and we are running into loops. I think it is unlikely that we find a solution in a short amount of time that works for everyone
Ege: lets decide on this inclusiveness and will link a commit hash so that people can review it, and then we close the issue
… maybe we focus on points 6,7 and 8. The 7 is whether the reviewer can access it, and 8 is tied to 6, if the document cannot be public can we have at least a summary document that we can host and is public
Cristiano: do you have opinions about the final report being available?
Cristiano: I think we discussed earlier, that it should be easy for the reviewer, I would like to see it public, but it should at least be reviewable. I also agree with Michale McCool If something is not public, we should mark it somehow
Ege: What are others requirement on this question, should the binding documents be available without any payment or royalties?
(None)
Ege: I would formulate the decision
Ege: Writes the formulation
… the formulations should be checked to not cause any legal issues
<EgeKorkan> proposal: The binding entry DOES NOT have to be open to read, use, implement. However, the binding MUST be reviewable by the reviewers.
Kaz: that is basically fine, but it would be even nicer to clarify what binding entry is, binding document doesn't have to be free
<EgeKorkan> proposal: The binding document linked in the registry entry DOES NOT have to be open to read, use, implement. However, the binding MUST be reviewable by the reviewers.
RESOLUTION: The binding document linked in the registry entry DOES NOT have to be open to read, use, implement. However, the binding MUST be reviewable by the reviewers.
Ege: I will commit this document to keep all opinions
Ege: let's tackle point 8, it tackles whether there is a summary document that is hosted by the custodian. I would say that this kind of document will be stored to give people the idea of what it will contain. The vocabulary terms cannot be public, it's a point of discussion. We can follow Daniels point to discuss asynchronously.
… with this point 6,7 and 8 clarified, we can also resolve point 3, which is about what we expect about the initial document.
… are there any other opinions?
(None)
… Ege merges the existing ideas into one: initial entry must be a correct document, meaning that: mapping at least one WoT operation, URI scheme definition, example of each mapped operation, abstract and introduction
… is everybody fine with the suggested text?
Cristiano: please tell me if it is off topic, but what do we refer to when we call for implementation of the binding?
Cristiano: do we want to optionally, the context file where the definition goes, maybe we also want that
Ege: The first point we will discuss later, second point I forgot
Cristiano: if you want this to be the minimum should be fine
Ege: in point 10, what are the required sections/contents? Ege adds the text: there should be at least one
… the reviewer doesn't have to check if it makes sense for that protocol or whether it is implementable, of course they can.
… this review can also be done by a non-expert of the protocol
… are there any additional points for point 3
… lets go to point 10, what do we want as the content of the document? what are the required machine-readbale documents provided on the side?
… in case we go for a more stable version, we need test report or documentation of implementation experience
… some weeks ago, we had the opinions that all documents should have a similar order.
… my opinion was that there is an introduction, binding content, examples. Also having at leat one operation mapped to a protocol vocabulary term
Cristiano: I am ok with the section order, we have experience that this is working fine
… maybe the discussion if we want to add a section in between?
Ege: this should be possible and could happen that there is sections between the ones that are required
Kaz: i am ok with the direction itself, but if we already have some concrete expectation, like MQTT document, we can mention this content and that content are expected. At this moment, we are not really sure about the format, but we are at least expecting some concrete content. So we can mention those existing sections and content as an example
Ege: I will quickly formulate the points for number 10
Ege: I would say tomorrow we can have a final document and then we can work on it asynchronously. Tomorrow we will continue this and also the use case results
<kaz> [adjourned]