Sebastian: talked about OPC UA
… PRs w.r.t. security
… placeholder concept
… ThingModel discussions
… actions vs property discussions
<sebastian> issue 1044 - Adding term to indicate a stream of data
Sebastian: Any objections?
-> none --> minutes approved
Collecting topics for vF2F
Sebastian: I put some topics already like ThingModel
Philipp: w.r.t ThingModel, using multiple TMs
… merging seems tricky?
Sebastian: at the moment TD can only refer to *one* TM
Philipp: Extending: e.g., "base" sensor + TM for X and Y
Koster: I have similar use case also
… iotschema, light bulb having several capabilities
McCool: Wrote this up for plugfest scenario, see link above
<kaz> kaz: +1 with McCool
Koster: separate TMs seem to be useful
McCool/Sebastian: discussing outcome of these topics from the PlugFest
Sebastian: Agree. Experience in the area of TMs seem important.
Kaz: agree we should think about concrete scenario for plugfest. also if possible we should think about how to deal with Thing Model at the discovery phase.
McCool: in discovery we do not look into TM right now. Not sure if we should though
… being TM in directory as well
Koster: topics of overriding
Sebastian: How much time do we have for TD task force?
McCool: 3-4 hours for TD?
Sebastian: ThingModel seems to be the most important TD topic for the upcoming F2F
… let's continue discussing the F2F topics next week
Cristiano: I committed Modbus changes
<sebastian> 109 - Refining Modbus protocol binding
Cristiano: I fixed renderer script
… I also proposed Modbus document
… followed TD pattern: HTML enhanced by SPARQL queries
<CA sharing his screen>
Cristiano: sharing rendered Modbus document
… rendering is still not complete ... eg. missing whether something is optional
Sebastian: You might need SHACL file for doing that
Cristiano: I also added default Modbus mappings
… readproperty to modbus fuction
… I would like to get feedback whether the document structure makes sense
Sebastian: Looks good.
… I am missing TD examples
Koster: ontology might be a standalone document
… could be used in other areas as well
… practical examples make sense also
Cristiano: having various documents makes linking more problematic
… i think the current proposal could be a template for future bindings
Sebastian: I imagined a self-contained document for Modbus ... forgot about ontology file
Sebastian: wonder how we best align with binding core document
… wonder about the number of documents, Ontology and HTML, general documents multiplied by every binding
Koster: Remember the discussion
… lots of documents vs generic template spec
… not sure there are arguments for both
Kaz: I wonder whether we should talk to Modbus implementors or not
Sebastian: 2 topics
… 1. content makes sense
… 2. whether we use multiple documents
Kaz: We started to think about other liaison as well. We can ask them what they would like to see
… For example, ECHONET and others could provide ontology
Sebastian: Yes, need to get in touch
Koster: Having separate vocabulary makes sense
… we did have HTTP pattern
… we can not push others to do the work
… propose to have vocabulary separate
… I recommend core document being stable
… maybe just having some pointers to bindings
… standalone document should be self-contained
Sebastian: like Uniform resource Locator ?
Cristiano: Question: separate document for ontology?
Koster: start with one document. Once it is final we might break it up
… suggest to talk to Ege also
Sebastian: MQTT is part of core at the moment
Sebastian: Okay, lets go with having separate documents in the future for each binding
Kaz: DID could be useful in the future
Cristiano: What are the missing steps on my side?
Sebastian: Good so far. Examples are missing ...
… ontology should be generic. examples are related to TD.
Koster: TD mapping should not be part of generic ontology. rather part of binding document
Sebastian: Thanks Cristiano for all your work
Sebastian: Summary can be found here https://
Koster: I have one more issue in mind? Shall I add the comment to this PR?
… will create issue
Sebastian: Agree with what Kaz mentioned before. Should get in touch with Modbus people
OPC UA Binding
Sebastian: Kaz mentioned to have a separate call
… do we plan a web meeting?
Kaz: Yes, I think we should do that
… I can create doodle poll
Sebastian: or PlugFest week, re-using cancelled calls
Defer issue to TD 2.0
Sebastian: please look into https://
Sebastian: and provide feedback
PR 1052 Fix HTML fragments in ontology docs
Daniel: fixed reference issue
Sebastian: I am OK with merging
PR 1049 TM Schema generation
Sebastian: PR is about JSON schema for ThingModel
… Ege provided version and script
Daniel: Ege uses script which is good
Sebastian: Since it is marked as WIP we should wait before we merge
PR 1042 Add additionalResponses to Form
McCool: PR is not yet done
McCool: wanted to get feedback before moving on
… proposal: use additionalResponses to avoid backward compatibility issue
McCool: property should not report back different data from input (use action instead)
Sebastian: What is the use case for multiple responses?
McCool: e.g., different kind of errors
… or also different success responses
Sebastian: using oneOf?
McCool: oneOf is the alternative
… should add text when to use what
Cristiano: wonder whether it is possible to state response is error?
McCool: Could have error codes...
Cristiano: among those possibleReponses can we mark one that this is an error
McCool: having a boolean?
… could make sense
Cristiano: will add comment to PR
PR #1024 Topics around Thing Model
Sebastian: tried to incorporate input from last week
… re-structured chapters
… start with basic concept
… next is thing model declaration
… followed by "modelling tools"
… like using versioning
… extension and import (import is still missing)
… afterwards "placeholder" concept with example
… we have "required" feature also
… should look into SDF approach w.r.t. required
… I also explained the steps from TM to TD instance
… see section 10.4
McCool: Do we say we MUST NOT put security in TM?
Sebastian: No, it is weaker ... "MAY NOT"
McCool: Sounds good
Sebastian: I plan to extend the examples section 10.5
McCool: Placeholder for number types?
Sebastian: Placeholder provided as string. Mapping file is typed as number. There are libraries doing that already.
Koster: SDF style approach? Overriding?
… shall we have examples for it?
… I could create some of those examples
McCool: would be good to rewrite the existing examples in that style to compare
Sebastian: Expect more feedback after the PlugFest
… SDF examples make sense
Koster: SDF uses JSON pointer or reference mechanism
Sebastian: we cannot override interactions
… we cannot override type's
… except number being cast to integer
McCool: scale factor might be a related topic
Koster: OCF has some of these scale factors
McCool: step is a related issue
Koster: unit might also play a role here
McCool: narrowing types is another topic
Sebastian: created issue
Sebastian: I propose to merge Pr#1024
… will add come warnings that we are still collecting experience
<kaz> PR 1024
McCool: I think we need section about validation
… relates to discovery
Issue 1037 - The "body" location value for security schemes is underspecified
McCool: Not ready to close
… need to add mentioning of JSON pointer
Issue 1044 - Adding term to indicate a stream of data
Cristiano: relates to scripting
… stream vs object
… from scripting API it is transparent
McCool: in directory we talk about streaming
… GeoPose streams data also
Cristiano: usually the protocol level handles it
McCool: I think we should capture the use cases