Meeting minutes
Agenda - Opening session
McCool: introducing agenda
<kaz> Opening slides
Thing Description
Sebastian: we have several parts to discuss
… roundtripping, TD 1.1, ThingModel,
… TM overwriting limitations
… TM composition
… TD Validation
… Sync vs async actions
TD RDF Roundtripping
Victor: Activity on GitHub ... e.g., issue 1168
… submitted PRs
… keeping security definitions in RDF
… another PR#1169 about indexing
… a easy fix was submitted
<victor> https://
<victor> https://
Victor: thanks to those fixes I closed a number of issues
… the changes are only in JSON-LD context
… roundtripping should be possible now
… i will write test-cases in near future to check whether everything is covered
Sebastian: Great news
… I suggest we should go ahead merging
McCool: does it also solve rendering issues with security?
Victor: I think this is a different topic
McCool: Agree with merging
… move forward from here
<kaz> s/^https/-> https/
<kaz> s/^https/-> https/
McCool: PR#1168 has IPR issues
Kaz: is it just a bug fix?
Victor: Yes, would say so
… not sure if company logilab providing fix is W3C member?
McCool: It seems more than a typo fix
… does invited experts status help?
Victor: the change is very simple.. one line
Sebastian: one liner should not be an issue
… the rest is auto-generated .. so I don't see any issue
Kaz: Okay, makes sense
… marked the PR as non substantial
… PR can be merged now
<kaz> but again, please make sure non-participants should not create a PR other than editorial changes :)
Victor: Great, thanks --> PR 1168 has been merged
… merging PR#1077 also
Victor: Michael, can you point me to the issues that still need to be fixed
McCool: will check and let you know
Victor: Some minor JSON-LD issues are still open
McCool: Issue#915 solved also?
<kaz> Issue 915 - Vocabulary term "scheme" not defined when used inside securityDefinitions
Victor: Right, not sure if everything is fixed
… have to do a proper review
Sebastian: Great, thanks VC
… helps a lot
McCool: helps for discovery also ...
… e.g., relaxing requirements
Victor: Thanks goes to LogiLab
Whats new in TD 1.1
<victor> I'll have to leave now, sorry for not staying longer.
Sebastian: Please check FPWD 1.1. released in June
… some more aspects:
… TD Canonicalization
… work done by McCool
… we also have a first command line tool to do canonicalization
<kaz> latest WD of TD 1.1
<sebastian> https://
Sebastian: some parts might still be missing
Kaz: w.r.t. to working draft.. it is June .. not March
Sebastian: other news
… links container has a new member "sizes"
… e.g., for icons
Sebastian: new also: ThingModel namespace
… at the moment still intermediary namespace
… tm:required is available in TD instances
McCool: TM context defined?
Sebastian: Yes, in in TD context
McCool: Not sure about the correctness of other namespaces .. like security
… misses prefixes?
Sebastian: Yes, MMC please check
Cristiano: What does it take to make these links referencable?
… real links are easier to handle
McCool: related issue for validation
… we should start doing this correctly
<McCool> mm: in particular, for validation, would use useful if ns URLs can be used to fetch ontology and also validation files (
McCool: can we direct them to actual servers?
<McCool> ... eg JSON Schema, SHACL
Sebastian: Questions goes to Kaz... I think
… could also use raw github link
McCool: TTL file could be default
… use content negotiation for others?
Sebastian: Simple forward could be done, right?
McCool: Yes
… but still handle different files.. e.g. for SHACL
Kaz: I mentioned in the past that we could add another redirection
… should be careful about the scheme
McCool: maybe use a convention
… also used for extensions
Cristiano: we could even use GitHub URIs
Sebastian: not sure about the benefits
Cristiano: shorter URL than raw github link
McCool: I have the concern about GitHub URIs...
Cristiano: +1 for creating issue to discuss further
… github pages is just a static webserver
… can also use W3C server.. both works fine for me
<McCool> Issue 1181 - Validation of extensions and fetching from context URLs
Sebastian: Those should be it for *new* features
Thing Models
Sebastian: should talk about overwriting existing definitions
… e.g., property dim typed as integer
… we can refer to this dim definition ... overriding integer type ..e.g. change maximum from 100 to 120
… i think this should not be allowed
… what about changing type integer to number
… also not Okay
… what about extending by limiting the integer range
… this is OKay
… we need to be clear in the specification what is allowed
… proof could be done by validation.. validating against both definitions
… I plan to work on this aspect
Lagally: Basic question: what are the boxes in the slides? UML inheritance ?
Sebastian: it is just an example how to use TMs
… by using ref
… examples are still TMs
Lagally: This leads to multiple inheritance, right?
Sebastian: We only allow one super-class
… ref can point to multiple other TMs
Lagally: What about naming conflicts?
Sebastian: does not happen
… we point to a dedicated url
Lagally: I see
Sebastian: tm:ref helps to reduce redundancy
McCool: Do we allow multiple references ?
… self-reference?
… open up problems and opportunities
Sebastian: We do not tackle this yet in the spec
McCool: Maybe we should currently limit it to full URL
Sebastian: Yes, should talk about it
Daniel: reminds me to the issue in TD... pointing to global definitions
Sebastian: Yes, we should think about the topics
… original question: shall we forbid the first 2 examples as sketched in the very beginning?
… SDF has the same restrictions
… I guess Vorto also
Lagally: I suggest we keep in mind versioning
… it could happen that the initial type/range is changed
… pointer to keep in mind
Sebastian: solved by the URL?
… updating content of *same* URL could cause this problem
McCool: informative note .. about changing base classes
Lagally: +1
McCool: Url should have version in it
… provide some best practices
Sebastian: Would like to move on to TM composition
… how to model things that consist of other things
… e.g., traffic light .. composed of 3 lights (red, yellow, green)
… see issue#1177
<kaz> Issue 1177 - Using composition in favor of inheritance in Thing Models?
Sebastian: proposal is to use links container
… using "rel" like "subthing"
… do you think relation type works?
McCool: semantically compatible with SDF?
… should make sure this is the case
… sdfObject
… transforming from SDF should be possible
Sebastian: Will study it
… alignment makes sense
Lagally: Suggestion by McCool with sub-components is useful
… terminology ... "subthing" seems not very useful
… what about "component"
Sebastian: This was just a proposal
… we should check IANA
… "collection" or "item" could be used
Lagally: Makes sense to align with IANA rel types
Cristiano: I like the link approach
… I am a bit puzzled about the expectations
… what are we looking at?
Sebastian: Had a similar question.. how would the TD look like
… I would expect a selfContained TD
… but this is the next step
… no answer yet
Cristiano: I see the same options
… everything or other smaller TDs
<sebastian> https://
Sebastian: please also follow the issue
TD Validation
<McCool> https://
<kaz> Issue 1181 - Validation of extensions and fetching from context URLs
McCool: created issue about validation extensions
… no formal way to validate extensions
… 2 approches
… contentType
… using suffix following convention
McCool: should look at SHACL and how it is done there
Cristiano: Tried to use schema for binding ...schema including TD schema?
… in JSON schema this is not that easy
McCool: we could also have multiple extensions
… schemas for extensions should be simple
… we have to study this problem
… extension validation will be optional
WoT Action Model
McCool: where should it go?
… profile spec?
Lagally: First we need to discuss the need
McCool: Status of action
… cancelling action
Lagally: I would need some more time to discuss this... I have 10 slides
McCool: Okay... let's use the time now
Lagally: Action is similar to RPC
… input .. wait time ... response
… execution states of an action: received > dispatched > success/expired/failed/unknown
McCool: what about "blocked" ?
Lagally: could have that from received...
Lagally: Action status may contain these like "RECEIVED", "DISPATCHED", ...
… we know whether action is completed
Lagally: long running actions
… first confirms .. no result yet
… at some point in time there is a result
… how to cancel action
… RPC cannot be cancelled
… a generic cancel mechanism would introduce complex actions semantics
… on the other hand one can simply introduce cancel operation
… what about result
… polling?
… causes network traffic... processing overhead
… what about timeouts?
… motivates timeout parameter
… how to get result without polling
… SSE, LongPoll, WebHook, .. can we agree on a standard?
… question about actions quees:
… typically FIFO sequence
… what about emergency stop ...
… beyond scope of WoT?
McCool: I guess we need more time to discuss this topic
… Friday?
Lagally: immediate feedback would be very much welcome
… Ege is not available on Friday
McCool: Quick feedback is reasonable
… we extend actions to support status
… references
… status url
Lagally: defining status payload content?
… profile could use this work from TD
McCool: could be informative in TD
… could sort out details
Kaz: I agree with the direction
… clarify what is missing for TD and binding templates
… and also implementation guideline on how to use those spec for actual applications, e.g., HTTP binding, could be given in profile work
<Zakim> kaz, you wanted to ask about what "long" means here
Kaz: original question: what does "long" mean?
… should clarify criteria
Lagally: timeout parameter could be used
Sebastian: this is a big topic.. there is not *one* solution in the market yet
… should start but keep approach as simple as possible
… status mechanism makes sense to me
… avoid eventing mechanism
… advanced opportunities may come later
… T2T group could help in this area also
McCool: big topic, let's defer to next Arch call
<mlagally> Here's the github issue about action semantics: https://
<kaz> [ 5min break ]
Security
Improved localizers
McCool: uri and body. uri is when the security is in the uri. body is when you embeded the key in the payload and it is mixed up with other stuff.
mm goes through some examples of localizers
McCool: Let's talk about Canonicalization. It is mostly about signing. We need to remove all the variants and reduce it one unique way in order to sign a document.
McCool: We also have some special cases. Default values etc. we decided to include them always. That makes it a bit verbose.
McCool: It is mostly an internal process, so it isn't critical to lose that space.
McCool: Prefix names must be retained. If you use a prefix, you have to use it.
McCool: There are also some weird things which timestamps.
McCool: I am not 100%, if I covered all corner cases. That is why we should test is in order to capture everything.
<Zakim> dape, you wanted to prefixes could be handled differently: Canonicalization could always remove any prefix and create ns1, ns2, ..by sorting namespaces
mm goes through some examples.
McCool: The example still includes security. That is wrong and gets removed.
Daniel: XML rewrites the prefix. Why don't we do that?
McCool: I did that originally. I need to look into my notes, why I didn't do it. Let's talk about it.
Daniel: If we make such decisions, we should note it down in the document.
McCool: The signature can verify, if the document is legit and signed by the correct key. We tried to use heavily already existing standards, even though we couldn't adopt a standard.
McCool: I looked at XML signatures, but since it is XML signatures, it doesn't work for JSON. But I used the structure of it.
mm shows some examples.
McCool: We currently have uris to refer to keys, but we can use interal pointer to embedded keys.
Marketing
Animation video
Sebastian: We released our animation video and have a couple of translations available. Japanese, German, Italian, Chinese, French and Spanish.
Sebastian: Another news is our video is ranking very good within the W3C Youtube channel. We reached the top 20. Very successful video.
Visitor counts
Sebastian: Another topic is that we don't have a visitor count for our web pages.
Sebastian: I think that is very important, in order to recognize if we are good with our page. In order to identify broken links etc.
Sebastian: When we use Google Analytics, we also have to use Cookies. I am not a fan of this. We have to find a way to avoid this, but have some data.
Sebastian: If anyone has experience with it, it would be great, if you support us with it.
Dissemination
Sebastian: We should be involved more in the maker scene.
Sebastian: We currently don't have a good variation of articles, videos etc.
Sebastian: I am currently in exchange with Philipp Blum. I asked him to help me with that. I have a budget for this available, I would like to use for this.
Sebastian: This budget is only available until end of september. I cannot guarantee to get another budget for next year.
Sebastian: If anyone else is aware of channels, media, please contact us.
McCool: I think we should target the maker scene.
McCool: my point is that we should target professional developer, rather than hobbiests.
Sebastian: I am supporting this idea. If we want to have this kind of tutorials, we should invest more time in it.
McCool: I think we should think about the sequence of videos.
McCool: We also need to discuss orchestration.
Cristiano: I agree with this direction. I just want to say, that if we want to contunie with that, we should improve our implementations first.
Cristiano: And then improve documentation.
McCool: We have node-wot. We also have the groud up C implementation.
Cristiano: I was thinking about the developer experience for node-wot.
McCool: I think there are two problems. Maturirity. Another issue is that node-wot isn't deployable on small devices.
McCool: I think we should document it and make a list of tutorials we want to have.
<kaz> pb: some confusion here. outreach by the end of september, and some longer-term work
<kaz> sk: right. on the other hand, let's think about our Twitter account
<cris> +1 we need people dedicated on dissemination
<kaz> sk: the question is there are too many things to do and who would work on marketing
<kaz> ... Siemens have some budget available now, so would think how we could use it
Philipp: I think we have two topics here. What Sebastian was mentioning is more short term until end of September. Having a sequence of videos is a good idea for our own Youtube channel. But we don't have the capacity for this.
Sebastian: Yes, I agree, we don't have the capacity for that. When we do this on our own. I don't think anyone has enough time to maintain that and participate in the standartization to that extend. I can support that until end of September, but we should think beyond that.
McCool: I think I can help with that.
Kaz: I think that is a good direction. On the other hand, I'd suggest we should think about a broader strategy of our work including all our Standardization, Implementations, Plugfest results etc. I am not objecting to that in general, though.
Daniel: I don't understand what direction we go. The tools we currently are not professional. But I think companies are going to start eventually their own implementation. I wonder, if we should start for a call for implementation again.
<McCool> followup - issues on wot-marketing, PRs here: https://
McCool: We ran out of time. I suggest we make PRs on the tutorial git.
Smart city workshop
Kaz: There was a smart city workshop. We discussed several topics, including use-cases, standards and W3C possibilities. Several important topics.
Kaz: We are making dedicated groups for several topics.
McCool: Are you making changes to the charter in order to include that?
Kaz: We have to regenerate a report from the minutes. We need a dedicated chair for this.
Kaz: We can start then more detailed discussions in the IG.
Lagally: Will that also include specification work?
Kaz: Good question. No specification, use-case documents etc.
<kaz> s/use case/only work on use case/
Administration
McCool: I just want to have a confirmation that we are not going to have a meeting on Friday on the 2 June.
Sebastian: I would suggest to have at least the main call for next week.
McCool: So then we cancel the other meetings, so that people have some free time.
McCool: Just let's assume for now that the meetings are canceled.
<McCool> https://
McCool: We got a 6 month charter extention.
McCool: People should take a look on it and add topics, if they have any.
McCool: Let's discuss that in the next main call.
McCool: Let's get the IG done and then let's go to the WG.
<kaz> [ vF2F adjourned ]