Meeting minutes
Organizational
Agenda
Ege: every Thursday the agenda will be prepared, 1 week in advance it will be ready
… also a new section in the agenda items from other members for suggestions
minutes
<kaz> Oct-11
Ege: minutes approved
TD TF Moderators
Ege: TF moderator requests was not received by Ege neither Kaz
<Ege> proposal: The TD and Bindings Task Force moderators will be Ege Korkan and Michael Koster until further notice
RESOLUTION: The TD and Bindings Task Force moderators will be Ege Korkan and Michael Koster until further notice
Ongoing General Topics
PR 1899
<kaz> PR 1899 - Fix "Intel" usage to "Intel Corp."
Ege: fix intel usage to intell corp PR 1899
merged w3c/
Ege: merging PR 6, means that the files are served by Github
wot-resources PR 6
wot-resources PR 6 - Mapping files for TD 1.0 and 1.1
Ege: any questions about this?
(none)
… we will wait for the main call to merge this PR 6
Jan: is the namespaces file in the TD repo supposed to be kept?
Ege: that becomes useless, we recorded the discussion previously on the namespaces.md file
… any opinions on this?
Kaz: As I mentioned during the main call, once all the resources are installed under wot-resources repository, this kind of information (redirection mapping) should be also istalled under the wot-resources repository rather than the wot-thing-description repository.
PR 1901
<kaz> PR 1901 - unnecessary triple quotes around comments
Ege: small fixes in the ontology by Mahda which does not affect the index.html file
… some editors face this issue and cause an error
Mahda: only half of the ontology has this issue with triple quotes not all
Ege: do you know why it was added with triple quotes?
<cris__> +1
Mahda: no, I didn't check the history of the repo on why
merged w3c/
PR 1900
<kaz> PR 1900 - Modeling string or array of string in the TTL files
Ege: PR related to string or array of strings in the ontology
Mahda: we don't require to necessarily model an array at this point as it will cause unnecessary complexity
Ege: do you agree cris?
Cristiano: yes
Ege: merged w3c/
Binding Templates
Guide document
Ege: still no feedback on the guide document. Michael Koster, if you work on the bacnet ontology if this is good enough for the user
Koster: will have some more time this week
PR 307
<kaz> PR 307 - [BACnet] Fix examples and one formulation
Ege: BACnet PRs
Koster: fix examples and one formulation on the BACnet binding
… will fail json-ld validation
Ege: any thoughts on this, Michael Koster?
Koster: no
Ege: OK with merging PR 307, but would like to wait one more week to get further review.
Ege: any other comments?
(none)
PR 308
<kaz> PR 308 - Adding BACnet JSON Schema
Ege: there is another one on JSON Schema, a conceptual thing that we have to think of as a group
… in BACnet there is the concept of datatype mappings, keywords that map to json schemas
… where would one see this and use this, we should be more expressive
… there are three services defined in the document, the rest are additional parameters, I added the types, but I don't know how we can really use them, I also used the previous context
<kaz> Issue 300 - "Philips Hue with HTTP" in Figure 1 of the note of the WoT Binding Templates
Luca: I think that the comment related to open issue and something that I would like to understand better is...
… BACnet has some ontology or schema and I am not sure what can be included in the TD
… you mapped some terms, I am not clear what we want to support, and in which direction we want to interoperate
… the part that confuses me alot is that we already we have a data schema, and hopefully in 2.0 we will have a data map so that there is another way that we take from our data model to whatever we are interacting with
… what is being done with the BACnet is that we are sort of being redundant
… would be probably nice to have an adapter that maps rather than redundantly describing the vocabulary
Ege: first of all I wouldn't be sad to remove it and would be fine with it
Ege: regarding the word mapping, it's not the same
… if you are coming from the BACnet world, you should model e.g. term bacv:Sequence as an array
Luca: if we could come up with some lines of description to know what it is about
Ege: creates an issue data mappings section has unclear purpose
Cristiano: your discussion with Luca clarified the situation a bit, because I also had a similar concern
… I noticed a small typo in the BACnet document, in the type:array missing curly braces
… this is like a suggestion to not refer to data type mappings rather than vocabulary
… It's comparing to different concepts
Cristiano: maybe you can put a guide on how to use json schema for BACnet
… is it more for validating or book keeping?
Ege: mainly for book keeping
Cristiano: i would remove it, because it causes clutter and confuses people
Kaz: Clarification question regarding the minutes and PR
mkj: the original idea was to use the BACnet in the binding and the json schema to validate, I agree that this is redundant
… the json schema has the same information in it, I am wondering if there needs to be a reference in the document
… but having a JSON schema is already known and the whole section can be probably be removed
Ege: from where
Koster: from the index.html
Ege: The idea was to add a description in the Data type mapping section because you can't use them in the JSON schema
… you need to refer to it somehow
Koster: right, because it's an identifier, now I see the point, there is nothing to actually validate
Ege: the really usage of this that I could see, example in JSON Editor online
Luca: we have a @type that is the json-ld type, so that part is sort of fine, but at the same time if we have a consumer that has to care about this part, assuming we have additional forms that don't have BACnet we are back to degraded consumption
<kaz> i|ege: BACnet PRs|PR 307 - [BACnet] Fix examples and one formulation|
Luca: if we agree that we can safely ignore what we cannot understand then this is fine
… I put in the issue the way it might a bit better, because then you have everything in the form where you need the information and can safely ignore the property that is using the BACnet protocol
… as it is now as 1.1, since it is not defined what to do with any kind of vocabulary term is fine, but you have a problem if you have a strict consumer that it can drop the whole affordance
Koster: +1
Koster: the BACnet specifc vocabulary when you see type Real form you are meant to associate it with type number in the affordance, it is not so much validation like json schema validation,
Ege: are you suggesting we should do some sort of validation that these do not match?
Koster: it's meant to be a table that contains the correct association between BACnet items...
… it doesn't make sense to have it in the schema
… once you generate it in the affordance, you can then validate how the affordance is being used
Ege: yes, I think at this point we agree
Cristiano: it's not only about consumers that will use BACnet, since you can have a mixture of protocols in the TD
Ege: commits to remove BACnet data types
Ege: fixed some small things in the index.html
We will wait one week before merging w3c/
URI variables
<kaz> Issue 302 - URI Variable for BACnet
<kaz> BACnet Binding Temlate - 5.1URI Variables
<kaz> PR 309 - Reorganizing uri variables section
<kaz> Preview
Ege: had a discussion with Klaus Hardke ,the original motivation was using it when you need to give additional parameters
… when expressing inputs, you can give additional pararameters to the operation, but it is weird because the BACnet scheme doesn't contain parameters
… I talked with Daniel to see how it will look like for in scripting API
w3c/
… some ideas generated under the issue
Ege: the proposed ideas by Ege and Luca explained
Luca: my full proposal is for the affordance I want to be explicit on the data schema
… the additional data is the idea of not all protocols require this information, the servient has to keep track of that, in the form you can be explicit in what to map
… for the mapper you can use a JSON pointer and then put it wherever you need, i.e. it can be protocol specific because you are in the form
Koster: thank you Luca, great idea
… there is two concerns, how to parameterize actions
Koster: The original design is for REST APIs
… we can make this look like an action but it is not right. So we are stuck a bit here
… general problem is that we did not provide a generic affordance
… we did not offer an affordance like colorControl
… also the schemas are problematic, we need to map them
… we need to express that some properties need additional parameters
… observing has common case of saying how often you want the values or how granular the changes are
… there is a similar problem with CoAP observe
… the problem with BACnet is that there is no query parameters that exist in REST APIs normally
… this is a good direction in general and we need something like this
Cristiano: I am aligned with what is proposed by Luca
… we need to abstract from single protocol
… the interactions can be grouped into affordances and the current patterns work for now
… it might be difficult to do this consistently
… it would be nice to have something like query parameters
… and not rush a lot with the design
… also now it becomes confusing why one would model something as property or action
… another thing is that in TDD
… in REST APIs you can have /things endpoint and then you can have additional query parameters. These are actions in TDD spec
Cristiano: when do we start new design on this
Ege: I think we should fix the bacnet issue asap and move with the new design
Luca: in http, there is header, body and query parameters
… we did not consider that yet
… for bacnet we can consider additional parameters in the form
… in that case, we can keep them in form so if you do not know what that form is, you can ignore
Luca: if you have need to put something in a "sidechannel", we have the mapping discussion in place
Koster: that pattern sounds good
… we have same problem with websockets or other "overloaded" protocols
… also http async notification has a similar issue
… we can keep it in the form, once with constant values and once with data schema
… we can also use the default value
Ege: (shows proposal on json editor)
Koster: we can use this proposal for now and avoid the design issue
Ege: the type problem is still there though
Koster: We need a schema
Koster: this type can as well be a json schema
Ege: the proposal including the sample code is available at w3c/
Figure issue
Issue 300
<kaz> Issue 300 - "Philips Hue with HTTP" in Figure 1 of the note of the WoT Binding Templates
<kaz> https://www.w3.org/TR/wot-binding-templates/images/binding-templates.svg
Mizushima: The commercial product of Philips is in the Figure 1 of Binding Tempaltes
… I think it is necessary for us to obtain permission to use
… if Ege uses Philips Hue, it is easy to explain the usage
… I think there are many similar products
… it is not good to use such commercial product names
… so it is a policy issue
… it is also used in Architecture document
… so the issue is related to the Architecture document as well
Kaz: I was not aware of this
… it would be better to say "Commercial Devices" or "Proprietary Device"
… we do not have to list everything
Koster: It is a common pattern, so we can call a general category
Ege: I think we can say something like "Commercial Devices such as Philips Hue, Echo"
Luca: Something more generic would be nice
Ege: should we keep example of hue or remove entirely
Luca: we can replace the image completely with "custom" etc. and then explain later on
… we should probably mention them to advertise for them
Kaz: I agree with Luca
<Mizushima> +1 Luca
TD.next
https://
Ege: let's continue the discussion on the new work items next week.
adjourned