Meeting minutes
Minutes Review
<kaz> Sep-11
Luca: They were very brief
… not much to say
… does anyone want to add something?
… also regarding the minutes from TPAC?
Luca: Ege, do you have the link to the TPAC minutes?
Kaz: (links the minutes)
<kaz> https://
Ben: (also adds a link)
<benfrancis> https://
<benfrancis> https://
Luca: Thanks, Kaz and Ben
… regarding the TPAC minutes
… who was there and wants to say something?
… is this the correct one?
Kaz: Yes, and the Profile discussion was done on the 2nd day
Luca: Who was present and wants to add something? Or wants to add to the minutes?
… otherwise we can just approve them
Profiles philosophy
<kaz> (minutes themselves have been approved)
Luca: (shows one part of the minutes)
… this is the part that I want to discuss today
… if we can write a paragraph on the relationship between bindings and profiles and hopefully can agree on that
Ege: In the TPAC, we had more or less the reolution that profiles should not extend the TD
… but I guess that should not matter too
<kaz> Luca's message (Member-only)
Luca: For today's topic, I hope everyone has seen what has been written on the mailing list
… if somebody did not
… the idea is, we have bindings to extend what to represent in a TD, and the idea is to use profiles as a boundry for what you can describe in a TD
… with that, we can restrict what is part of a TD and also validate the content
… if someone wants to take the floor and voice their opinion, this is the right time
Ege: Regarding your question on the mailing list, Sebastian has sent a mail that also includes my opinion
… maybe you can share it
<EgeKorkan> https://
<kaz> Binding Templates enable a Thing Description to be adapted to a specific
<kaz> protocol, data payload formats or platforms that combine both in
<kaz> specific ways. A Profile warrants that only the Binding Templates it
<kaz> mandates, or a subset of them, will be used to describe all the
Luca: I also noticed that Ben has expressed his opinion
<kaz> Affordances exposed by a conforming Thing.
<luca_barbato> Binding Templates enable a Thing Description to be adapted to a specific protocol, data payload formats or platforms that combine both in specific ways. A Profile document contains only a subset of features of the Thing Descriptions specification and of individual Binding Template documents to describe all the Affordances and metadata exposed by a profile-conforming Thing.
Kaz: That has been sent to the member's list, will share it one IRC
Luca: (also pastes the proposed text)
… this is the proposed text
… I think the spriti is okay
… but the use of "document" needs to be specified first
Ben: Sorry to interrupt, but what is the proposed text for?
… is it a resolution? Or something else?
Luca: Wanted to use it as an introduction to the document and at least agree on that
… and build consensus based on that
… and eventually expand to consensus on how the profiles should behave
… we will probably have some disagreements along the way
… but eventually we should end up with a registry
… my proposal is to start with that introduction
Ben: I've responded to the email, but I suppose it went to a private mailing list
Luca: Everyone should have received it here
Ben: Agree with the basic concept
… think everyone is agreeing here, disagreements are about the details on how to go there
… don't think that your text and Siemens' version capture that
Luca: Two parts, first how profiles behave and second, why they are useful
… two essential components:
… 1. profiles restrict
… 2. ensure that the Thing it describes complies to the profile
… to ensure out-of-the-box interoperability, need to ensure that no additional properties are added that break the contract
… what I did in June was describing why Profiles are useful
… today I would like to agree on the two fundamental aspects
Ege: What was this June meeting?
Luca: I think you were there
… it was a pull request
<benfrancis> w3c/
Ege: The introduction pull request?
Ben: Yes
Luca: It was the PR where I tried to clarify what we mean by "out-of-the-box interoperability"
… would like to have more opinions on these two points
… or maybe even have proposals that are more clear
… the Siemens proposal is fine if we could be more precise on "documents"
<benfrancis> luca_barbato: Or did you mean this PR? w3c/
Luca: otherwise, we could focus on the relationship between the Thing and its description
Ege: Agree on this
… with "document", we were trying to make sure that we are referring for a Profile
… and not to another document, such as a Binding or the core requirements
… like for the bindings, we defined it as a binding sub-specification
Luca: For profiles, we could call it just profile
… but that might be ambigious
… or we could call it profile instance
… I am open for suggestions
… "documents" might be too ambigious
Ege: If you have a registry, then you could have documents, in my opinion (?)
Luca: We can call it documents, if that is not used by a binding yet
<EgeKorkan> https://
Ege: I shared a link on the terminology
Ben: Is it still called a sub specification if it is part of a registry?
Ege: We could call them registry entries
… so for binding documents, that would be Binding Template Registry Entry
Kaz: We as a TD task force need to think about how to fix the terminology
… within the TD taskforce in the end
Ege: Correct, yes
Ben: So, I think we are all trying to describe the same things
… if we make a new attempt, we need to be very precise with our language
… don't think that the Siemens approach is that
… gave examples in my email
… don't think a TD should, for example, restrict the kind of properties a TD should contain
… in my opinion, a Profile should constrain the extension points of a TD
… for example, bindings, payload formats, or even discovery mechanisms
… so it is not really a restriction of the feature set from the TD specification, but rather a restrction on the extension points
… the reason is also the out-of-the-box interoperability and not another motivation
… need to be very careful with the wording
Ege: I don't think we are really on the same page then
… I don't think a profile should not be able to restrict a TD to only use string as a type for properties
… or that it should not restrict the length of descriptions, for example
… at some point, we might want to have a TD that is extendable from a profile-compliant TD(?)
… maybe we should write down the questions we have and then come up with answers
Ben: So, Ege, do you think that profiles should just be a set of assertions, then?
<kaz> Luca's original text
<kaz> Binding Templates enable a Thing Description to be adapted to a specific protocol, data payload formats or platforms that combine both in specific ways. A Profile warrants that only the Binding Templates it mandates, or a subset of them, will be used to describe all the Affordances exposed by a conforming Thing.
Ben: because that would make profiles more open-ended
<kaz> Siemens' proposed fix
<kaz> Binding Templates enable a Thing Description to be adapted to a specific protocol, data payload formats or platforms that combine both in specific ways. A Profile document contains only a subset of features of the Thing Descriptions specification and of individual Binding Template documents to describe all the Affordances and metadata exposed by a profile-conforming Thing.
Ege: but of course, if we would just extend to the properties, then that would already ensure out of the box interoperability, but you would need to rework the data model
… otherwise you would never reach that goal
Kaz: Thank you very much, very good and meaningful discussion so far
… since the discussion was only on the members list, maybe we could copy over the discussion to a GitHub issue and continue the discussion there
… also including the comments by Sebastian and the others
Luca: We should be able to that very quickly
… (starts opening an issue)
Ben: While you are writing: Where was the discussion that there was a consensus or a resolution?
Ege: There actually wasn't one, therefore we should agree on something here
Luca: Ege, please add the statement from Siemens
… it is better if someone from the company itself does that
Ege: (adds a comment to the issue)
Kaz: Ben, very sorry, but could you please copy your comment to the GitHub Issue 418?
Starting over the discussion based on Issue 418
Luca: Does anyone else have a different opinion or wants to give a +1 to something anyone said?
Ege: Wanted to give a +1 to what Ben said
… can reword to it say something like "should constrain the features of the TD specification" (?)
… we need to be careful here
… we could say something like "it constraints the information model of the core TD specification"
… to be a bit more specific but still generic
Ben: I think we need to go through a couply of concrete examples
… of what features and constraints mean, since there is a lot of potential ambiguity here
Ben: Ege, can you explain the second sentence of your proposal?
… is that supposed to be the motivation?
Ege: No, out-of-the-box interoperability should be the motivation
… I think the important aspect is that a Profile should restrict a TD while still being valid
… the second aspect is that a Profile restricts @@@
Luca: Ege, do you know whether JSON-LD already has the concept of a "negative" context?
Ege: I don't know
<kaz> i|shoes one part|topic: Profiles philosophy|
Luca: Since the way a Profile is supposed to work is removing items from the context
… so it is like a substraction
… but I don't know whether JSON-LD would allow us to do
<kaz> i|topic: Profiles philosophy|(minutes themselves have been approved)|
Luca: since that is what we need and we could feed that into a parser
… unclear whether we already have the tools for that
… in my opinion, a profile could be seen a diff that could be applied to a context
Ben: Although that would be neat, I don't think that this will enough
… the discussion is very much focused on TDs
… should also include the behavior of a Thing
… adjusting the context is not enough for that
… another aspect that should be dealt with in a profile is whether a Thing should stick to the defaults of a protocol binding
… and that is also something that goes beyond just adjusting a TD itself
Luca: I think we have more agreement on that
… so the first part is to get someone to reword the paragraph that provides that lead
… second aspect is that we agree on the main parts
… one aspects is removing vocabulary, the other one is restricting behavior of Things and Consumers
… when it comes to consumers, once they know the protocol binding they should know the intended behavior
… we need to see how it fares in a practical example
Ben: I think we are focusing too much on bindings at the moment
… only one of five aspects, others are semantic context or discovery
… can they also be restricted?
Luca: If these aren't bindings, then what are these?
<benfrancis> protocol bindings, payload bindings, security mechanisms, link relations and semantic contexts, and maybe discovery mechanisms
Luca: idea remains the same for other aspects as well
Ben: So could a profile say "A Consumer must support this semantic context?"
Ege: Given that the bindings are also vocabularies, I would say yes
… I am talking by the way about the broadest sense
… I would say that a profile can mandate the use of a certain vocabulary
… funnily enouhgh, even bindings are doing that
… for example, in the case of the MQTT binding
… I would assume that there is an MQTT URI scheme used in at least one affordance
Ben: I assume also security schemes would be part of bindings eventually, right?
Ege: Yes
Ben: Then the other things from my list are @@@ and discovery mechanisms
Ege: I would say that bindings should also be able to restrict discovery mechanisms
… should also be able to restrict the data model
… for example, the data length or how temperature is being described
Ben: Data structures are not really an extension point
… a bit different to the other items I mentioned
… but the other aspect you mentioned, about units ....
Ege: Units are actually another thing
… more about the data structure, so for example whether it is two numbers
… but also about the name of affordances, see Matter for example
Ben: For WebThings, we are rather using sementic annotations
… that is then an overlap of semantic context and also Thing Models
Ege: To add to that, if someone would use a different property name, they would not be out-of-the-box interoperable
… if we would enable that, we would be competing with Matter and BACnet and others at the same time
Ben: Would be fine with that
… always competed with Matter
… what we ended up with is a descriptive and a prescriptive approach
… I hope that will work
… if you choose a presecriptive approach you are competing with something like Matter
… with the descriptive approach, you choose a protocol binding and then just describe what is already there
Ege: I am fine with that
… we should just be aware that if we went all the way too prescriptive, we would not have out-of-the-box-interoperability
Ben: That corresponds with what we had before regarding levels of interoperability
… with WebThings, we are using a capabilities approach
… kind of an extra layer of interoperability
… but even without them you would still have interoperability, you would just not have the same richness of what the data means
Ege: I will also write to this issue
… this point regarding vocabulary terms and how they can be restricted
… will start writing now and finish after the TD call
<benfrancis> A Profile document constrains features of the Thing Descriptions specification and of individual Binding Template documents to describe all the Affordances and metadata exposed by a profile-conforming Thing.
Ben: I just pasted another version of the Siemens proposal
… and just added the phrase "constrains"
… not happy yet
… as the text leaves open what "features" means
… but it is closer
Ege: Agree with the chnanges you've made
… also agree that it is not specific enough yet
… will try to come up with a definition of features
Ben: The motivation is also not clear yet, implication via the "to" is unclear
Ege: Will add that to the issue description
Ben: We are getting closer
Ege: Agree
Kaz: Should we continue the discussion on GitHub or at the next meeting?
bf and lb: GitHub is fine for us
Luca: Thanks for attending, see you in two weeks
Ben: Always unclear whether the call is happening or not, by the way
Kaz: McCool made a proposal to make adjustments
<kaz> [adjourned]