Lagally: (goes through the
minutes)
... can we approve the minutes?
(no objections)
Lagally: approved
Lagally: will send a reminder to the whole group
Kaz: the results imply the
current marketing slot would be the best
... let's talk about that during the marketing call today
Sebastian: yes, let's talk about
that
... anyway, we need to search for a better slot for
marketing
Lagally: tx!
... Sebastian, we need your input as well esp. for the profile
discussion
Sebastian: ok
Lagally: let's look into the issues
Lagally: McCool's proposal to reduce
number of goals or differentiate
... the common understanding so far is creating a single
profile as a starting point
... (adds a comment to issue 7)
Sebastian: wondering if we could have
more additional profiles
... the resolution made last week doesn't say "a single
profile"
Lagally: right
... do we want to start with multiple ones?
Sebastian: we should clarify our
point
... this is a baseline with one profile which provides a
guideline
... and then how to extend it
... if people have some legacy mechanisms, don't have to follow
that
... we should clarify which kind of use cases to be addressed
by the "core profile"
... we should discuss that
Lagally: we should have more
discussion about that during this Architecture call
... what the central points for interoperability
... starting with one core profile and think about extending
it
... people can use the core profile as the basis
Sebastian: definitely agree to the idea
of profiles
... but a bit concerned about how to deal with it
... we should be careful how to communicate with implementers
outside W3C
... who are working on IoT based on the market needs
... might need to work on various different technologies
... what kind of protocol could be used for what, etc.
... should consider the actual benefit of having profiles
... would be better to provide multiple solutions
Lagally: completely agree
... we shouldn't exclude people working on MQTT, etc.
... if we support only one protocols, that would not be
good
... we have to discuss the details and find a solution
... (shows the initial draft)
Kaz: we can concentrate on the
core profile for the FPWD
... and put the other possible profiles into "other expected
profiles" section
... after getting consensus, we can move them one by one to the
main body
Lagally: agree
... regarding issue 7 itself, it's asking us to reduce the
number of the profiles
... and we've already reduced the number
... we have a consolidated requirements for profiles as well
here
Lagally: (adds some more comments to issue 7)
Sebastian: seems to be reasonable
Kaz: Ben's last comment for issue
7 is kind of old (in 2019)
... so let's give this update and see his response
Lagally: ok
... let's keep this issue 7 open and see his response
Lagally's comments based on the discussion today
issue 17 - vocabulary not in TD context
Sebastian: Section 4.1.2.2 list a number of vocabulary (e.g., softwareRevision, loc_latitude,...) that are not mention in the TD specification yet.
section 4.1.2.2 of wot-profile draft
Sebastian: this is listed for the core
profile
... but no new term is clearly defined
Lagally: we have practical knowledge
based on our PlugFest efforts
... but the knowledge requires some baseline for
interoperability
Kaz: regarding the terminology
definition itself, we can start with listing undefined terms
with "to be defined" :)
... e.g. softwareRevision: TBD
Lagally: (adds comments to issue
17)
... our intention is not to divere from the TD spec or define
duplicate entities
Kaz: we can move the possible new
terminology section to the Architecture draft or the TD draft
later if needed
... but starting with listing necessary terms would make sense
Lagally: ok
Lagally's comments to issue 17 based on the discussion today
Lagally: we have to look into the
Architecture issues as well
... now we can quickly skim the initial draft wot-profile
Lagally: (and then create another
issue)
... profile is not exclusive
... add text that explains that the TD can be used without
restriction for all purposes
Sebastian: we can discuss the detail for the issue next time
Lagally: would it be OK to use this initial draft as the basis of further discussion?
Sebastian: let's work on that so that we
can publish the FPWD in September
... btw, I should be also part of the Editors to give
updates
Lagally: tx!
... aob for today?
(none)
[call 1 adjourned]
Lagally: (goes through the minutes)
(no objections)
<mlagally___> propsal: Use the current strawman document as the baseline for the Profile specification
RESOLUTION: Use the current strawman document as the baseline for the Profile specification
<mlagally___> proposal: Accepting the following requirements for the FPWD: Interoperability, Limit and reduce complexity, Eliminate ambiguities, Limit resource consumption, finite set of features and capabilities, follow security and privacy best practices subject to group feedback
RESOLUTION: Accepting the following requirements for the FPWD: Interoperability, Limit and reduce complexity, Eliminate ambiguities, Limit resource consumption, finite set of features and capabilities, follow security and privacy best practices subject to group feedback
<Mizushima> wot-profile issue 16
Lagally: adding co-Editors
McCool: fine to be added
Lagally: would merge PR16 as is right
away
... we can add McCool and Sebastian later
McCool: ok
McCool: we should start with the main
ontology
... the question is if we would limit extensions, e.g., do we
want to let OneDM, etc., to be included in the profiles?
Lagally: have been working vocabulary from our PlugFests
McCool: we need to think more about testing side for the PlugFest work
Kaz: as I proposed during the
first call, regarding this issue 17 from Sebastian itself, I'd
like to suggest we clarify which term is defined and which is
not
... and think about the concrete definition later
McCool: yeah, we should respond to
Sebastian
... note that we should not fragment because a profile TD is
still a valid TD
... we might want to define a limited frozen set of
extension
Lagally: (adds a label of "defer to 2.0"and removed the "requirement" label)
[adjourned]