<kaz> scribenick: ryuichi
Lagally: logistics
... Architecture 1.1 contributions and new requirements
... Issues
... Profiles
... any more agenda for today?
... none
<kaz> Sep-17
Lagally: any objection?
... approved.
<kaz> scribenick: kaz
Lagally: let's defer this one since we don't have Zoltan now
Lagally: not ready
McCool: we had discussion on Thing Model
during the TD call yesterday
... use cases for Thing Model needed
... to see Digital Twin and Developer support
... for digital twin, protocols don't matter
... but for developer support protocols matter and would see
security information as well
... would see whether protocols and security information to be
mandated or not
Lagally: also would see the big data use case
McCool: for developer support, you need protocols and security information
Koster: when you have things which are
not online
... not sure if the developer support use case is so different from
digital twin
... to me interaction has to be there
... could be at different stages
McCool: would avoid duplicate names
Koster: what we call workflow
McCool: fill in the details on the interaction
Koster: helpful to show what is considered by IoT Schema, etc.
McCool: we should have some general
statement
... as for developer time, there are two kinds
... those using scripting API
... vs doing all myself
Lagally: would be nice to use the queue
:)
... we want to have Thing Model
... but need to clearly state that
... precise definition
... when we have a formal relation type
... need structured data type
Kaz: would suggest we start with the
use cases themselves
... and elaborate the requirements based on them
McCool: agree
... also we should think about minimum requirements as well
... some use cases might be more desirable
Lagally: we already have a requirements description on "thing template"
Lagally: should be renamed (to "thing-models.md")
McCool: maybe we can add "variants"
... also minimum requirements?
Koster: please continue
Lagally: requirements section includes...
Koster: if you look at the overlap with
oneDM and IoT Schema...
... think Sebastian would like to have a mechanism so that TD can
do what oneDM can do
... some of the use cases have schema and some don't
... it's an orthogonal thing
... if I have a thermostat, I have two levels
... the last one is TD which has the address and device type
... do we want to make TD have the whole lifecycle capability,
etc., like oneDM has?
... basically it's part of the discussion
Lagally: why don't we start with what we
currently have?
... based on our own use cases
McCool: we should clarify the Thing
Model
... interaction and schema first
... and could add modularity, etc., later on
<McCool> ... once we have modularity, we can perhaps add a "Thing Capability" which is like a Thing Model, but perhaps with just affordances (and no data schemas for instance)
Kaz: maybe we might want to have an
additional section of "what we want" right before the
"requirements" section to clarify our background on the need for
requirements
... for example, Michael McCool wants to think about security
portion
... and Michael Koster is interested in the compatibility with
oneDM, IoT Schema, etc.
McCool: yeah, that would make sense
Lagally: (adds a subsection of "what do we
want for different use cases?")
... (and adds subsections of "Digital Twin" and "IoT
Orchestration")
(some more discussion on "what we want" from various viewpoints)
Lagally: (captures the summary)
McCool: would compare "Digital Twin Modeling" and "IoT Orchestration Modeling"
Lagally: would like to see "Big Data" use case as well here
Kaz: we might want to have some
concrete scenario for each use case
... those three use cases are horizontal ones and could be applied
to various vertical use cases
... but we could identify some typical scenario like gas plant
which mentioned in the use case section of the v1 Architecture
spec
McCool: would see the description on the
abstract level now
... could revisit concrete cases later
... minimum quirements for common elements are interactions and
data schemas
Lagally: inheritance of multiple classes would be too complicated
McCool: as a starting point, could focus on single inheritance
Lagally: (adds constraints)
... Thing Model constraints must appear in the Thing Description
with possible additional details
... wondering if we could have some description on possible
alignment between oneDM and Thing Model
Koster: that would make sense
Lagally: would suggest we allocate a slot for that, e.g., next week
Koster: ok
McCool: maybe semantically annotated TD
would be useful?
... btw, next week will be PlugFest
Koster: yeah
... will busy as well
... related to the use case on generating TD from SDF
... workflow you could take things
Lagally: (adds an agenda item on the discussion to the Architecture call agenda)
Koster: when to do that?
Lagally: Oct 1?
... Thing Models and OneDM
McCool: would include SDF explicitly
Lagally: yeah, SDF is a separate IETF WG
now
... more technical discussion there
McCool: also requirements and enhanced
use cases for Thing Models
... would have Sebastian as well
Lagally: (puts Sebastian's name there with a note of "TBD")
Kaz: thanks a lot for the
discussion
... and I think it would be even nicer to have some more
supplementary description on why we want this mechanism
... based on today's discussion
... e.g., need a flexible mechanism to automatically generate TDs
for these horizontal use cases
Lagally: (adds supplementary description on that)
McCool: open issues on modularity, etc.
Lagally: (adds that to "Open issues" section)
<mlagally> updated Thing Models Requirements
Lagally: who could generate an updated diagram?
McCool: maybe Toumura-san?
Lagally: (adds a comment to Issue
538)
... could you ask Toumura-san about this?
McCool: will do
Lagally: who could work on this?
McCool: can work on that
Lagally: McCool, can you work on this?
McCool: ok
Lagally: somebody to generate requirements
for time stamps/time series
... related to media use cases?
Kaz: can ping the MEIG guys about the
pre-meeting on Oct 1
... also the joint discussion on Oct 7
... could ask NHK guys as well
Lagally: ok. let's defer this then
Lagally: requirements on accuracy
Koster: can look into this
Lagally: if we could have a starting point, would be able to accelerate the discussion
Lagally: not ready today
(GitHub Preview doesn't show the diagram, Statically requires account. so Kaz shows the index.html and the diagram which have been locally cloned)
Zoltan: maybe need to update the
transitions
... it's complex
Lagally: would illustrate what happen for lookup, etc.
McCool: this is device lifecycle
... would see how to upgrade the system too
... resource needed for access control
Zoltan: commissioning for WoT?
Lagally: McCool, could you add a comment to PR 539?
Zoltan: please leave comments
Lagally: need some label for "resume" etc., to come back to the "Operational" state from "Maintenance"?
Zoltan: wondering about what would be the
good name
... I'm open for suggestions
Lagally: ok
... this is work in progress
Zoltan: what else do you need?
McCool: why don't we have a quick review
round?
... would prefer merge this and review the changes
... having an acronym of "TD" is confusing
Lagally: we're out of time
... why don't we keep this open, and continue the discussion next
week?
McCool: two editorial PRs for small changes
[adjourned]