Meeting minutes
Logistics
Ege: split the agenda into two parts
… you can add topic proposals at "Backlog" section too
Agenda
Ege: (goes through the agenda for today)
Minutes
Ege: (goes through the previous minutes)
approved
New TD slot
Ege: 1st slot on Wednesday at 10am Eastern
… 2nd slot on Thursday at 9am Eastern
Wiki organization
Ege: cleaned up the TD wiki as mentioned the other day
WoT resources
TM
Ege: Mahda has started to work on the TM resources
Mahda: still ongoing
Versioning
PR 1951 - Versioning of TD resources
Ege: (goes through VERSIONING.md)
Ege: some issue on the style of indentation
… "When a use wants", etc., should be part of "Initial thoughts on versioning"
Cristiano: not sure about each resource but useful to have release version
… useful for implementers
Ege: Alpha-version for REC release, and sub version for each release?
Cristiano: yeah
Kaz: detailed version management is fine but we need clear policy and procedure for that
… what kind of changes to be identified for what purpose
Ege: right
Luca: you can tag any kind of releases
… we can decide, e.g., every month by date and time
… that is a time anchor
… would be enough for implementers
… Git describes some number based on hash as well
… if we want to make some specific version periodically, e.g., monthly
… could put a tag to identify each version
… could use either way
Ege: so far we don't add any explicit identifier to each version
Koster: mostly agree
… we do CI tech work flow
… would be better to use explicit versions
… GitHub hash number should be long enough to identify the versions also
<luca_barbato> https://
Koster: we can use date/time instead too
… not sure about the need for periodic release, though
… we need more discussion
Cristiano: (audio trouble and rejoining...)
Ege: how to deal with TD versions in a semantic way
Cristiano: we're publishing typescript notation
… about a monthly release, some sort of deadline needed
… note that we're handling not only one library
… need to be aware of coding for CD coordination
… thinking about the scripting-api repository
<Ege> json-schema-org/
Ege: would consider versioning for JSON Schema as put above
… regarding this PR 1951, I'd merge it
Kaz: fine to merge it
… but please check the indentation, e.g., tab vs whitespace, later
Ege: will check the format first
Static dates
Issue 1940 - Fixing the Ontology HTML files to static versions
PR 1952 - Static Ontology HTMLs
<Ege> https://
Ege: the content is correct
… but missing abstract, etc.
… have fixed all the ReSpec errors already
… now we have a sub folder saying "staticFiles"
Kaz: the content is generated based on the TTL files
… and you need to specify the Abstract, etc., manually
… right?
Ege: yes
Kaz: technically, we can use ReSpec to provide the HTML content
… but do you want to avoid potential bugs from ReSpec?
Ege: exactly
TD
TAG reviews
Ege: not sure how to deal with this...
<Ege> https://
Ege: seems there was no Pullrequest but directly pushed
Kaz: would suggest we keep this kind of obsolete resources as an example for the future wide review for 2.0 spec rather than removing them
Ege: ok
… would add a README.md to describe them too
Kaz: nice
PLANNING.md
wot PR 1163 - Moving Planning.md items
<Ege> wot-thing-description PR 1948 - Delete PLANNING.md
Kaz: so that means simply moving the PLANNING.md content from the wot-thing-description repo to the wot repo. right?
Ege: right
Backtracking some additions in TD 1.1:
Ege: several misleading points
… generic use cases don't really help understand the need and capability of the detail of each feature
… for example, regarding Thing Model
… possible use case: managing a set of instantiations of the same model device
… requirement: one file to represent a model fo the device
Kaz: from my viewpoint, "managing a set of instantiations of the same device" is rather a requirement for a feature
… and we still need to describe the use case based on users' viewpoint
Cristiano: we thought about search for TD as well
… we had some discussion, I think
Ege: maybe "correlate" rather than "search"?
Cristiano: that's fine
… could be broken down into 3 parts
Ege: think we're on the same page
… need more descriptions
Cristiano: "user story" should describe what the users want to do
… "I want to do ABC to achieve XYZ."
… should describe the user's role as well
Ege: "as user X, I want to ABC so I can achieve XYZ"
Koster: sometimes called s "persona"
Jan: reuse existing definition too
Ege: (adds another entry for Thing Model description or that)
… extension/submodel in TM
… requirement: reuse of existing definition
Jan: looks good
Koster: how to redefine the semantic models?
… TM gives as ability to work with IoT Schema, etc.
… application model to be consistent with affordance
… I can write up a user story for that
Kaz: this discussion should be done collaboratively with the Use Cases TF
Ege: ok
Luca: one problem of mine with TM is...
… it is a custom template
… we have a situation which TM could be a tentative solution for semantic interoperability
… you can use it to validate a TD
… we can use the TM mechanism to author another possible template language
… validate and consume in some certain scenario
Ege: think you're basically describing something similar to "managing/representing a set of instantiations of the same model of a device"
Tomorrow
Ege: would like to discuss Binding tomorrow
[adjourned]