<scribe> scribenick: McCool
<kaz> Sep-10
presentation by Matsukura-san on ITU-T home use case
need for discovery section; McCool mention tool now used for sequence diagrams in Discovery doc
and need to improve language in that section
discussed CHIP, agriculture-greenhouse use case
discussion of components
Lagally: shall we approve?
all: no objections
Lagally: minutes are approved
Sebastian: new regulations that has impact on standards work
forbidden to get involved in projects with non-public technology discussion that has use in US
McCool: for example, we have non-public (Member-only) mailing lists
so can't have technical discussions on those non-public mailing lists, but github is ok
proposal: not use non-public mailing lists for technical discussions or meeting minutes, draft minutes included
RESOLUTION: do not use non-public mailing lists for technical discussions or meeting minutes, draft minutes included
in general, for people complying with the law... it's obvious and implied, do we have to say anything?
eg compliance with auditing, privacy, safety, etc. requirements
my preference is to declare it out of scope
we could declare it out of scope, or add a disclaimer under conformance
something like "We do not specifically address any legal requirements that may apply to your application or location."
I think we should check with W3M if this is a reasonable thing to do.
McCool/Lagally: let's brainstorm, link them to use cases later
Lagally: describe a topology; relationships between entities
McCool: suggest we list relations we
want first, later on look for names or a spec we can
adopt
... and even if we adopt an existing set of definitions, we
should identify particular ones that should be used for
specific purposes in WoT
Lagally: right, we have to be a bit
more selective
... and there are some overlaps
McCool: and in a profile we also need to limit link relation types to a finite, static subset
<mlagally__> https://www.iana.org/assignments/link-relations/link-relations.xhtml
Sebastian: there is also a possibility of when to use a link relation type and when to use a semantic relation
Lagally: when you think about how you model things in UML: inheritance, implementation, aggregation
McCool: let's also list the entities
we care about
... thing model, thing description, directory
... what we want to know is where a TD was sourced from, so
that (for example) a consumer can subscribe to update it
... also need to deal with bidirectional links
... "implements" may also have inclusive and exclusive
variants
... eg can a TD implement more than one TM (for sub-APIs)
... need to clarify when to use links and when to use semantic
relations; suggest to use "dereferenceable"
Lagally: aggregation
McCool: is aggregation "member of a set"
Lagally: same or different types?
McCool: "like" is a fuzzy concept
Sebastian: do we need explicit entity types or will contentTypes cover that?
McCool: I was thinking of entity types more as a way to structure the requirements discussion
Lagally: note that inheritance etc. raises various naming issues
McCool: another general category of
link types is "metadata"
... manufacturer, author, documentation, etc.
Lagally: let's review iana spec...
<mlagally__> https://www.iana.org/go/rfc8288 Link relations: https://www.iana.org/assignments/link-relations/link-relations.xhtml
Lagally: (group looks at iana spec, update docs)
<mlagally__> https://github.com/w3c/wot-architecture/edit/master/REQUIREMENTS/link-relation-types.md
Zoltan: made a PR
<mlagally__> https://github.com/w3c/wot-architecture/pull/539
Zoltan: reviews diff
... added introduction, background of work, state names
... didn't want to make this section too long
... this section however is mostly interested in state names,
data that is involved
... separate section for data (information lifecycle)
... also system, thing lifecycles
... need to explain why we have three, what the use cases
are
... eg. using devices that are already provisioned,
provisioning new devices directly to work with WoT, etc.
... "provisioning service" may or may not be a concrete
service, is handled in different ways
... similar to T2TRG model, but we need to add some more
detail, "opening up" some of the T2TRG states
... eg. we add more detail to "bootstrapping"
... there are also examples mapping terminology to other specs
that call these states by different names
... e.g. bootstrapping/onboarding/initial provisioning
... is this normative or informative?
... can make the names normative, but hard to make transitions
normative
... different in different systems
Lagally: can't really mandate that certain transitions are supported by different devices
Zoltan: feedback that came up what
that other people have worked already on this
... so why should we be different?
Lagally: some states are not defined in other systems, eg. maintenance
Zoltan: some always appear, some are optional
Lagally: can we use end-of-life?
Zoltan/McCool: have to ensure that definitions are equivalent though
McCool: I also want to note that you can always destroy something, the question is whether you can do it through the protocol
Lagally: example of cash card that
used flash so you could only burn cells to decrease the value;
once discharged, cannot be recharged; eol
... suggest that we keep it as a PR and everyone does a
review
Zoltan: would like to create pictures, need to use the same terms
McCool: (I really wish we could use SVG rather than software-specific files like ppt or drawio but whatever)
Lagally: let's use SVG as the master;
drawio can read and write SVG, so...
... need to not have both svg and drawio in github, confusing
which is the master, so will remove .drawio file
Zoltan: is there a style guide?
(Sebastian leaves)
McCool: for the record I do like the simpler style that Michael brought; lots of detail in each state gets pretty confusing, and it's harder to edit; we can put that detail in the text
Zoltan: suggest we take the current
diagram and take out the detail and create a simpler
version
... what about actors, etc?
Lagally: I would put that in text too
Zoltan: ok, then we agree, let me go and draft something
Lagally: everyone, then please review
<kaz> wot-profile issues
Lagally: several issues for standardized capabilities, units etc
<inserted> Issue 30
McCool: all subsets of "limit to specific extension vocabularies"
Lagally: want to discuss more specific issue of organizing PRs to address each issue
McCool: suggest we add a single paragraph that just says "you are allowed to use these semantic extensions and ONLY these"
Lagally: probably should go in to section 5.1.1, at the top, discuss vocabulary
<kaz> WoT Profile draft - 5.1.1 General
McCool: I think we should also
specify the prefix, it will make parsing easier
... may also need protocol vocabulary; but we still need to
discuss how to handle/mandate protocols
... but WHEN we allow use of a specific protocol, also need to
allow those protocol's vocab
<kaz> Newly created issue 34
Lagally: for units...
McCool: issue #29
<kaz> Issue 29
McCool: units mandatory vs. use of
unit system is mandatory
... most of the discussion was around the latter
... pretty hard to make units mandatory, some things are
unitless
... probably just a strong requirement
Lagally: could make them mandatory, but provide an "unspecified"
McCool: and since "cm" is easier to type than "unspecified" it's easier to do it right...
<kaz> [adjourned]