Meeting minutes
Minutes
<kaz> Apr-2
Luca: Nothing much has changed in the minutes
Luca: anything to change in the minutes?
Luca: minutes are approved
Housekeeping
Luca: we need to agree on whether to keep the async actions in the profile. They are a TD problem
Luca: It is underspecified in the TD spec
Luca: also we need to agree on how a profile relates to our context?
… so what happens when a pfoile brings their own ontology
Ege: so the first one is async actions and the other one is profile relationship to ontologies
Async Actions
Koster: I am missing a bit of context
… is it about one profile or all profiles?
Luca: in the TD there is no relationship between invokeaction and query/cancelaction
… you need to express the payload you expect for querying etc.
… we can say in a profile that you need that specific payload format for query and cancel
Luca: the open question is what happens when a consumer doesn't know the profile? Should it reject the profile or try to do something with that profile
Koster: do we want to assume that we will have async actions in the TD next version? I would say yes
Luca: we can do either X ? (sorry missed that) We can drop the async actions and get a profile 1.0
Koster: ok removing the dependency makes sense
Luca: then do we want 1.0 as REC since it achieves some interoperability. Or do we want it as a note
Koster: we can have discussion in a bigger group
Kaz: async actions should be done in TD.
<kaz> BTW, in addition to talking about "how to deal with sync/async actions", we as the Profile TF should
Kaz: the Profile TF should discuss what should be specified by profile
Ege: I am fine with removing async actions.
… I do not see anyone wanting to publish as REC, at least it was the case last time
… also I have only seen a simple example implementation from Michael Lagally and one from Ben but that was already profile compliant
Luca: there is also mine
Luca: I have implemented async actions as well
Luca: Having it as a REC is strong but if we publish as a note, be it.
… the issue with different implementers require all the complexity of linked data
Luca: we can approach implementers who do not want to adopt WoT because a device can be too complicated
… handling multiple ontologies and understanding linked data is not something that many want to do
… if we publish it, we can give it to people and say this is the minimum you need to implement to support WoT
Ege: two points. 1 is the example with units is that it is not clear with current profile which SI units one should use. M, meter or metre? How about Units of measure?
… creating a list of units will be like creating a new ontology
… from Siemens side, we do not plan to say you have to support these profiles at least to support WoT.
Luca: this is the second part (relationship between profile and ontologies), the SI units requirements would be saying that you should use this ontology that has SI units
Luca: you can support WoT without profile but then anything goes, we do not have degraded consumption
… when it comes to consumption, you need more effort (like an oracle that tells you all the ontologies) or you will have a very degraded consumption
Luca: the selling point is implementing a minimum of very useful aspects (correct me if I am wrong here) and still achieve advanced scenarios
Luca: so that within that profile you have full interop
Kaz: many years ago we had mobile web, I feel that wot profile sounds like that
… in that case profile should be a collection of existing wot specs
… and not specify additional mechanisms. That's why I'm suggesting we clarify what to be described by the WoT Profile spec. btw, if the current topic is still "Asynchronous Actions out of the profile", we're ok with removing that. right?
Luca: if mizushima-san doesn't say otherwise, we can move to the other topic
Mizushima: we need to clarify what is described in the document because our goal is to publish the document but it is difficult to understand the document
… so we need to clarify what the profile document is
Ege: I just want to second to the fact that people get confused when they read the document
Relationship to Ontologies
Luca: a profile can say that you must support these ontologies
… then we can say that a Consumer can support ontologies without supporting full linked data mechanisms
… since the terms would be in the profile
… do we have consensus on treating profiles as a list of keywords of ontologies that is constrained
Koster: yeah so it is about hardcoding the ontologies. But did we fix this in the TD in the first place?
Luca: the core point is fixing the prefixes so that you don't have to fetch ontologies to understand the TD
Kaz: we need to clarify what is expected by the developers
… the word ontology used today might be a bit vague
… we need to explain how constrained devices would handle these ontologies (or vocabulary)
Ege: I am fine with the discussed mechanism but it can be difficult to agree on what specific set of ontologies to take and which subset of them
Mizushima: If you think that ontologies are important, you should make simple case study.
Luca: everything should have use cases
Luca: next meeting will be solving some of the issues
Luca: aob?
<kaz> [adjourned]