<dape> scribe: dape

Past Minutes Approval

July-30

Lagally: we had 2 Calls
... no objections -> minutes approved

Profiles

Lagally: 2 open PRs and 15 issues

McCool: Several issues seem to overlap
... consolidate/close?

Lagally: Agree
... should look into
... Let's talk about co-editors first
... we have Lagally, McCool, Mizushima
... Matsukura-san and Sebastian
... 5 co-editors

<kaz> Issue 21

Lagally: Issue 21
... Mix of "scope" and "name" discussions

McCool: would be wise to start with scope first
... proposal: "core" does not even contain protocol

Lagally: Agree, should first talk about data model

McCool: In that case "core" makes sense
... insisting on a specific protocol in the core profile we run into problems
... with data model only we do not guarantee interop

Lagally: relating to digital twin discussion: with core data model we could have interop... even across protocols

Kaz: Agree. Starting with minimum set of features.
... we should define this set

Lagally: First set of features w.r.t. data model
... suggest splitting
... 1. constraints on data model
... 2. protocols and constraints
... 3. naming

McCool: some constraints are covered by JSON schema minLength etc
... related to strings is which encoding
... is there anything besides data models?

Lagally: interaction model... but I see it as part of the data model

McCool: ID formats? restrictions?

Sebastian: I agree we should avoid the naming discussion
... future profiles may pop up
... "core" assumes it is always part of of it
... I also agree splitting the constraints
... one profile with multiple constraints... security, . et cetera
... one profile might not always work for all interested parties
... e.g., HTTP and JSON is fine but needs "more" on the data model side

Lagally: Then you can extend the profile
... once you go beyond there is no guarantee that you will not blow other implementations
... conformant to profile means one has a guarantee

Sebastian: example: client with core and restrictions
... what do you do with strings longer than the expectation

Lagally: Cut string?

Sebastian: What is the difference with today's situation?

McCool: IF device says it satisfies profile.. it should satisfy the constraints
... if intentions of "core" is being part of any profile.. than name is fine
... out-of-box interop means I need to know whether it satisfies the constraints

Lagally: One can also validate the constraints

Sebastian: We have to differentiate OOB interop and interop?
... benefit: change is high that others implement the same

Lagally: should not talk about changes but guarantees

<Zakim> kaz, you wanted to say if we really need to avoid using "core" I'm ok with "vanilla", "plain", "minimum", "tiny" or anything.
... personally "core" is OK for the minimum set of the features, though

Kaz: need for defining what we expect
... "core" term might be ok, but terminology should come later
... let's defer naming discussions
... and start with use-cases and requirements

<McCool> another possible name would be "common" if we mean the "intersection of all constraints needed for interop"
... although I think "core" means that, too

Lagally: We are defining a common ground
... should get more concrete

McCool: 2 comments
... 1. should not use interop but OOB
... 2. leave name for now OR pick another name (fix it later)
... "common" instead of "core"

Sebastian: suggest naming it OOB also
... there are use-cases that do not need profile
... Modbus does not need it
... very easy protocol
... simple datatypes et cetera
... there you have already OOB interop

Lagally: Do you think Modbus constraints are good candidate for the data model constraints

Sebastian: Would recommend it. Very simple. Based on simple types...

McCool: back to discussion that "core" does not contain protocol
... Modbus is more restrictive than "core"
... but that is OK

Lagally: No-one needs to use maximum constraints

Koster: oob interop for CoAP and HTTP could be
... currently no core that works everywhere

<McCool> by the way description of "core" in section 1.3 does not really match the proposal of not requiring a protocol in the "core" profile; you would need the "core" plus at least one protocol binding, and the bindings would have to match, to get OOBI

Koster: we should call restrictions WoT-###

Lagally: main use case
... cloud use case
... multiple manufactures connect to same cloud
... with current flexibility in TD we can implement many different variations
... generic cloud service is not implementable
... without limitations it is not possible

Koster: Once you make choices it is not anymore broad consensus
... we look at the framing
... need to agree what the goals are
... unsure about the efforts... we are trying device specification
... like certifications
... maybe multiple profiles depending on domain

McCool: a device clarifies profile... it just works

Kaz: discussion during this call is great, because we're clarifying people's expectations for "profile" from various viewpoints
... we should clarify our expectation as a whole before diving into the details of this initial document
... which features, which data models, which technology areas and application domains we want
... because different parties have different ideas

Lagally: We agreed on horizontal profile
... common ground

Kaz: like we've been working on the use cases from the viewpoint of "horizontal vs vertical", we can think about profiles from the viewpoint of "horizontal and vertical"
... vertical part could be extension based on industry applications while horizontal part could be McCool's mentioning "core profile"

Lagally: let's try to do everything in horizontal

Kaz: we're not stuck with the name of "core profile" itself, but could use another name, e.g., "common", "vanilla", "plain", "minimum" or "tiny", for this draft document if needed. right?

McCool: suggest keep it for now and change later
... documentation requirements
... developer use case
... requirement for templates
... do not wanna burden small devices
... 1. specification of templates
... could contain documentation
... let's table "documentation topic"
... have it or link to it

Lagally: let's create issue for it, see Issue#27

Sebastian: similar discussion in templates.... how much should a TD be self-contained

McCool: developer needs documentation
... with tooling it should just work, no human readable documentation needed

McCool/ML: building UI is 3rd use case

McCool: Offline UI is the 4th use case

<kaz> Issue 27 - Human readable documentation

<McCool> scribenick: McCool

looking at issue #25

<kaz> Issue 25 - Comments on "core" profile and scope of constraints

Ben Francis' comments about applicability of "web" if not using URIs, the internet, etc; for instance, Modbus

Sebastian: modbus does have OOBI though; just need TD
... but its constraints are fairly tight
... OOBI not so easy for HTTP is since it is much more open with many more options
... so constraining those options with a profile makes more sense

Lagally: mjk did we cover your points?

Koster: I think so
... but some use cases would help at this point
... need some horizontal guidance for people building systems from scratch
... even across domains
... and also for constrained devices, eg limit resources
... calling out the protocols that are constrained would be useful
... see a lot of systems where it would be useful to...
... td is part of what helps protocols being interchangeable
... but we don't necessarily want to do this for one particular use case

Lagally: let's take this step by step
... maybe find common ground for data model
... protocols are a different angle, may distract from other things, like data models

Koster: are you talking about payload formats, content encodings, or information models
... the definition of this varies and may or may not include all these things
... the power of a TD is that we can standardize/define the data model and to separate out and interfchange the protocols
... so maybe we are talking about the same thing
... what is your thinking about what should be standardized in the data model

Lagally: I think we should not go down into standardizing names, etc. but to put some constraints

Koster: so, for instance, a property can't be arbitrarily complex

Lagally: exactly
... certainly many things to debate in the strawman
... but there are some suggested constraints on data models there

Sebastian: feedback on that... worried about id field again
... had long discussion about id field
... second point is security is already mandatory in TD

Lagally: might be a mistake based on a basis in an old version

McCool: dates are actually formally defined, in a different category than free-form descriptions
... there is also room for negotiation around id; the issue was really having a central issuing authority
... we can allow sessions, randomly generated, DID, UUID, etc. maybe we should specific types of ids
... maybe "support" should always be an email

Kaz: regarding "id", we should clarify what kind of ID is needed in what kind of cases for what purposes, e.g., "globally unique" mentioned here is one possibility but "session-wide unique", "application-wide unique", etc., would be also to be considered based on the use cases and requirements.

Lagally: yes, that's related to the lifecycle discussion as well.
... and then additional field names with meanings, etc.

McCool: I think we need to handle a certain finite set of context extensions, and only those
... especially for things with formal meanings, eg data types

Sebastian: worried that we are extending scope and vocabulary too much
... my proposal would be to discuss these terms in the TD task force to see if they should be included in the core model
... would avoid for now bringing these up here
... already set up a PR to move these to an issue on the TD

McCool: I concur; I think we should trim down this strawman as much as possible to what we agree on

Lagally: what kind of timeline are we talking about?

Sebastian: it will probably take a while

McCool: propose we use an extension for now, and simply allow it in the profile for now
... then in the long run, eg TD 2.0, it might move into the core vocab

<mlagally_> https://github.com/w3c/wot-profile/pull/26

McCool: I am a little concerned about making this core vocab for 1.1 for compatibility reasons

Sebastian: mention geosparql in pr

McCool: please note I've listed a bunch in the geolocation use case, we should add this, and also consider compatibilty with the web API (defined by DAS)
... we will have to evaluate and look at dependencies, etc

Sebastian: I think we have to check and pick an ontology that makes
... we can decide in the TD model

<kaz> wot-thing-description issue 941

Lagally: if someone want to build an OOBI device that uses geolocation, what should they do?
... let's say october

McCool: I think if it's october, even TD1.1 will not be out yet, so you will have to use an extension
... this is fine, to get OOBI we just need to get people to use the same extension and allow it in the profile (for backward compat)
... I think we can agree we don't have consensus, and probably we should not be defining new vocab in the profile
... we should create an issue and discuss various proposals for solving this problem

Lagally: right now there is chance that people will use divergent terms...

Sebastian: we should be discussing use cases, etc. first

Lagally: there is a use case for this... it was one of the first ones

Sebastian: but when did we discuss that it should be in the profile?

Kaz: charter says "profiles" are subsets of TDs for interoperabilty purposes
... so I think we should define requirements for "profiles" as subsets of TDs, and then collaboratively discuss what should be the subsets of TDs with the TD TF

Lagally: would not have seen the definition of a pragmatic keyword
... as being a problem

Kaz: my point is not whether these keywords or features make sense or not
... but that we've been discussing requirements, and should discuss how to deal with the requirements for subsets of TDs with the TD TF

Lagally: right, that's the main point
... ultimately, what I want is these keywords available as soon as possible

Kaz: my assumption is that Sebastian should be OK if we just make a proposal to figure out where they should be implemented

McCool: our Charter says profile should be a subset. If we define new terms, it is a superset

Lagally: ok, agree we should not divergence

McCool: agree that geolocation is important, but we should follow the process and put them in the right place

Lagally: would it be possible to prioritize geolocation?

Sebastian: more important than serial numbers, etc.?

Lagally: together would be nice, but can be decoupling is ok

McCool: would like to point out this is also needed for geospatial queries in directories

Lagally: would be nice to get into 1.1 for September in the FPWD

Sebastian: will put on the table next Wed
... McCool, can you comment on the issue and link in other discussion?

Kaz: btw, we should look at the updated specs about geolocation/geospatial terms

McCool: and maybe a joint meeting with appropriate groups at TPAC, eg. DAS, etc.

Kaz: will talk with plh and ivan about that

Lagally: ok, agree to merge PR to delete these from strawman
... time to adjourn...

<kaz> fyi, meeting cancellation plans in August
August 13 - Architecture
August 11 - PoC
August 18 - PoC
August 19 - TD
August 20 - Use Case and Architecture
August 26 - TD may be cancelled; will discuss in main call on August 25

[adjourned]