WoT f2f in Lyon -- 25-26 Oct 2018

<inserted> (Regarding the expected "Testing" session tomorrow, Kaz mentions that he'll provide information on the basic framework (what to do for CR/PR transition). also he has invited Mike Smith from W3C Team who works on the W3C Testing Platform. McCool will update the agenda for tomorrow)

Thing Description

Read-only vs. writeable flag in TD

Sebastian: the motivation is that there are more developer errors using writeable
... read-only is a more familiar concept

Matthias: has observed the “writEable” problem and it seems to be a common pitfall

RESOLUTION: we'll change "writeable" to "readonly"; case notation still to be discussed

Version

Sebastian: version is provided as a version number for the instance version
... it can be useful to add more metadata for creation and modification date
... the proposal is to provide created and lastModified using ISO 8601 compatible format
... where should we put it?
... does it go into the versioning container?

Matthias: there could be many versions besides the TD instance
... is created/lastModified metadata version information

Mccool: ... the dates could be used independently from version
... created/lastModified can be included at the top level as timestamps

Matthias: we should look at other specifications to see what the common usage is

Serial number

Koster: other SDOs create a separate model for this, should it be top level statement?

Mccool: it makes sense at the top level because TD is an instance
... we need to combine model and serial for it to be correctly interpreted

Matthias: the version container has three level version numbers and allows for semantic versioning to express things like HW version, SW version
... we can't limit the version categories to just three, so are using a more extensible scheme in the version container
... the "id" fiend in TD is the persistent identifier and remains the same when version changes
... there is an IETF document that defines URNs for device identifiers that can be used in "id"
... this is not for secure ID per se, but it could be cryptographically verified

Lagally: note that the dev:urn format is only an example of a unique ID and not a required format

Unit of measure

Sebastian: would be very useful as a core term in the TD
... which vocabulary should we use?

<victor> note on "serial": schema.org has a range of properties to use to provide product IDs. See https://schema.org/Product

Darko: we have a unit code term in schema.org that aligns with QUDT and others
... you need to have the context included

Matthias: what predicate should we use?
... there are problems with QUDT and UCUM

Mccool: we could define unit as a predicate that is defined in our vocabulary and allow it to be over-ridden with prefixes

Matthias: there is a cdt (common data type) ontology being proposed that enables most of these use cases

Lagally: looked at UCUM
... it's a big bag of all possible things you might measure
... furlongs, etc.
... it looks like UCUM is not constrained enough, should we add our own constraints

Matthias: adding constraints may be problematic because the lack of coverage on existing systems

Mccool: different countries have different schemes, the defined term "unit" is good

Darko: it's too early to require any one scheme
... the prefix doesn't work with the JSON serialization
... it would be good to have a default vocabulary that doesn't need a prefix

Lagally: we could define the term "unit" and with a default
... we should allow for constrained devices to be able to interpret units

Victor: it's hard to mix literals with URIs
... the prefix would be ignored
... constrained devices may not have web access

Mccool: propose that we provide "unit" and default to UCUM
... the value of "unit" should conform to UCUM

<kaz> Sebastian: there are many more topics today, so let's talk about this later

Action guarantees

Matthias: the proposal is to add "safe" and "idempotent" terms
... boolean default false

Input and output media types

Matthias: actions may use different media types for input and output
... for example, a camera action mat return an image
... we need to think more about the possible responses that might come back

<kaz> Kaz: possibly time synchronized/shifted with each other. maybe this idea might be too advanced for the current TD, though

Matthias: we want to be more hypermedia-aware than having to declare response codes

Mccool: this provides future extension points by using an array
... there could be new fields added

RESOLUTION: we'll add "responses" (as an array of media types) to handle multiple media types

Content type

Matthias: mediaType can only have a value of a simple media type and doesn't allow for parameterized media types
... for example, encodings and compound types
... content type allows additional parameters to be used
... proposal is to rename "mediaType" to "contenttype" and allow parameters
... this aligns with IETF "ct" identifier

kawaguch: no objection but does it impact for example the use of utf-8 with JSON?

Mixed case

Matthias: a lot of constraints in identifiers require conversion to lower case, for example encodings for web linking
... some conventions use camelCase
... some conventions are InitialCaps

TD and Scripting API

Matthias: let's resume
... last block for TD
... related to Scripting API as well
... btw, discussion about letter casing?

Matthias: case in-sensitive, etc.?
... consistency with the TD core vocab
... usual convention here
... we're defining web linking
... core link format for JSON
... might need lower case terms
... may convert back to camel case again
... the opinion so far is using camel casing
... but not conclusion yet
... show hands?

Matthias: we have other cases for other mechanisms
... we definitely to be consistent
... so far nobody against with using camel case for TD

<McCool> mm: proposal is that camel case would be for predicate terms, literals would be as in registries, etc.

URI templates

Matthias: uri with curly brackets here
... often used in web apis
... in our plugfest, didn't take into account
... but we need to revisit this topic
... sometimes required, e.g., for OMA LWM2M
... coding URI query parameters
... some kowledge on the client

Matthias: OpenAPI and HAL support that
... proposal
... something similar to uri template here
... understandable what this would mean
... data schema would provide information too
... full spectrum
... payload by the client
... I provide another proposal
... input field of action
... term templated to indicate input data goes into URI template
... question
... api example uses both uri template and payload data?
... different levels there
... fixed parameter for URI and can be used for payload
... go back to the original proposal
... and visit alternative again
... wondering if it's good

Koster: 2 items
... input points to item and schema
... could be validated by schema
... our use cases include both template and payload

Matthias: by definition we use object data schema
... subset of data schema allows
... object data schema, array, integer, ...
... template would be object data schema

Matthias: would construct specific data schema
... uri input
... payload input
... multiplex basically
... identify some semantic terms
... sub part of data schema to be considered

McCool: uri template as name
... different name spaces
... can see json template and payload
... assuming including other places
... will be willing to limit it for actions and events

Lagally: looking at the example
... missing regular input
... this uri template only referes to HTTP
... we should come up with concrete/complete example

Koster: we need to provide a schema
... type and value constraint
... providing schema to fill into the template

Lagally: we should define the data schema
... values of data schema to be defined as well

McCool: we should see CoAP, etc., as well
... header options
... extra parameters for uri template

Matthias: uri template is for URI
... not protocols
... fill in topic part
... imagine the server fills in the detail
... property to be written up
... possibly have 2 forms
... with same input

Matthias: constraint here
... defined dictionary for TD level
... possibly 2 different levels, one for uri and another for payload
... input definition
... forms knows how to construct message
... and the 3rd proposal would be only having input here (under moveleft)
... what is tricky is we have some container structure

Victor: still have type, name, ...
... would see this information in te schema
... input schema

Matthias: user concept defines new parameter
... on application matter, wouldn't matter

Koster: you're not sure how to generate the schema
... hard to know how to handle payload

Matthias: generating "4th proposal"
... decouple and only have input
... that's it for TD discussion

Scripting API

Zoltan: programming idioms
... how to handle events
... discuss other topics on WebIDL vs TypeScript
... challenges for scripting
... overloaded temrs
... object vs Thing
... WoT events vs programmatic events
... wot properties vs object properties
... wot actions vs object methods
... type definitions and mappings
... trends in the web platform
... do we use DOM or Node?
... our implementations are Node
... Sangwhan from TAG promised on that
... we don't use event currently
... how to do asynchronous programming?
... semantic meanings
... got feedback from TAG memtbers
... separate discussion on WebIDL break
... have slides about that
... respec makes braking changes
... multiple webidl versions
... "wild" ideas
... including Dave's simplified API proposal
... constructing DOM to represent WoT Things
... something new
... trying to create an issue
... Dave will have a slot?
... about the first point
... WebIDL or TypeScript or ...?
... discussions back and force
... some people suggest webidl
... some for typescript
... TC39 i moving to use WebIDL for ECMAScript
... WEbIDL is coercive and is used by all WEb specs
... typescript is informative
... should not use WebIDL for data structure
... need to see what the other specs use
... should use the infra standard to refer to @a

Daniel: given WebIDL causes many issues
... using TypeScript would make sense
... going back to WebIDL based on the TAG's comment is a possible option
... but would cost issues again
... don't know how others do

Zoltan: the next step is getting prepared for TAG review
... programming object vs Thing
... description on object and Thing
... Traditional IoT interactions
... <- request
... server-sent notification subscribed
... what we need to map
... to move on the topic MK asked
... web-nfc/issues/152#issuecomment-425179760
... you get promise
... written data or errors
... Traditional async programing with Events
... should use events
... traditional way is not really good enough
... DOM Events
... different context for EventTarget
... event listeners can dispatch events
... Node.js events
... difference how we add signature, etc., to event listener
... promise
... model for one-shot async operation
... no easy way to cancel the event
... cancellable promises have been discussed

Zoltan: yes
... Observables
... event hander can get any value (not restricted to event)
... AbortController/AbortSignal
... becoming similar
... pass the signal to dictionary
... have to implement some algorithm
... AbortController/AbortSignal (rationale)
... how to use it in the spec?
... function retures a promis and takes a dictionary parameter
... we have subscriber mechanism already
... takes notification handler
... takes optional subscriber
... named filter
... notification handler can take any values
... included onerror callback
... not DOM event
... we can take cancel into account

Matthias: how does the message look like
... to create a webhook
... for cancellation, you usually need
... body in the response
... where the resource is

Zoltan: why we need cancellation
... description here
... updated ConsumedThing
... different structure
... discussion
... last slide here
... do we expose programmable events?
... should follow DOM events
... one way to go

Zoltan: use the AbortController-compatible subscriber proposal?
... you can have options for subscribe/unsubscribe

Zoltan: right
... there is no Thing event or Thing signal
... you could handle multiple signals
... maybe overkill for us

Lagally: interrupting a thread was a nontrivial problem in the Java language, which was addressed 20 years ago
... interrupting a promise or using an abort action for unsubscribing does not feel natural

Matthias: here we're talking about programming language level problem
... 2 different levels there

Zoltan: not proposing we get resolution now
... people can give comments
... and we can make decision during the scripting calls

Matthias: DOM model to do or node model to do?
... we're at somewhere in the middle
... motivated this additional subscriber concept

<McCool> to clarify my earlier question: I asked if the Subscriber had a dependency on AbortSignal. It does. My concern was if it would break if AbortSignal turns out not to be "the future". It does, but my impression was changing it would be relatively minor.

<McCool> also, to clarify my comment: I was just asking if it was a convenience layer on top, and my comment about "not mappable" was about "not easily mappable to other languages that are not Javascript"

Discovery

Kaz: wondering if PlugFest participants have any idea/feedback on discovery and directory

Simple Interaction with things

Dave: produce and consume resolve with Thing that looks like a regular JS object
... special reserved name?
... or wot.model

McCool: comment on this proposal
... looks clean but not easily mappable
... convenient layer on the top?
... need minimal functionality

Dave: programming adaptation layer
... API exposed to the developers would be cleaner

Matthias: where is the mechanism?
... this part is clean
... but what about the underlying mechanism?
... what about lost message?

Zoltan: we could do that promise and wait
... there are JS implementation
... don't see any reasons we don't use promises
... the question about metadata
... is it similar idea to Koster's proposal?

Dave: maybe should have offline discussion
... e.g., how big the expected buffer should be
... read metadata, update metadata, etc.

Matthias: useful to start discussion about what the procedure is
... could see what developers prefer
... we've been defining low-level APIs
... reflecting the needs
... there are different flavors to be seen
... need to see if it's testable

Jose: one important thing we like WoT is that WoT is simple approach
... web has millions/10 millions of users
... you have many libraries already
... simplicity is good point of WoT

Zoltan: it's a low-level API you could use
... this is what this group would like to work on
... do we want to create a specific TF for simpler API?

Matthias: agree to make things simple
... WoT makes IoT easy to use
... we can show things work

Matthias: this proposal looks neat
... but developers need to handle the mechanism themselves
... how to roleback all the transition, etc.

Zoltan: stick with a scripting API that follows the TD
... the underlayer with metadata access needs more specification

Matthias: we agree that it's a good idea to create a simplified API but it needs more discussion
... we can keep this discussion going in the IG and CG where we incubate new ideas

Matthias: we can consider this in context of the rechartering
... if there are distinct communities that different ideas we could to work on it i a CG or IG

Matthias: can we establish a consensus on pursuing the scripting API as a low level TD based API and build more simplified/specialized layers on top

Dave: keep the current API focused on CR and do the simplified stuff in the IG without impacting the CR
... the simple event model using subscribe/unsubscribe

<Zakim> kaz, you wanted to ask if it's OK to record the conclusion using RESOLUTION

Matthias: the interest group is chartered to explore what should be standardized
... the WG is chartered to complete the CR

RESOLUTION: simplified API discussion to be handled by the IG; WG will continue the work on the current API towards REC

<dsr> A simplified API can be layered on top of the existing lower level API. The simplified API provides an object that you can synchronously read and write properties, and invoke actions as methods on the object.

<dsr> You get an exception when attempting to write an invalid value or writing to a read-only property - this can be done immediately using the TD

<dsr> The updates and notifications are handled in the background. Server pushes updates to client and vice versa.The client polls if necessary. Applications can subscribe to events such as the expiry of a security token or loss of connectivity.

<dsr> There is a means to get the meta data for a thing, e.g. either thing[“@model”] or wot.model(thing_name)

<dsr> The plan is to incubate this in the WoT IG, while the WoT WG focuses on moving the lower level API to CR as fast as practical

Binding protocol templates

Koster gives an overview about binding templates
... describe the binding of the transport to the interactions.
... binding template examples for different serialisations (MQTT, CoAP, HTTP)

Matthias: binding templates specification is an informal document, not normative

Matthias: used to describe bindings for different existing devices
... not a normative part of the WoT spec
... (talks about an example of OCF / CoAP binding)
... descriptive approach to compensate for the "noise" of specific protocols
... describing how to integrate LWM2M, CoAP
... we consider restructuring the document with sections for individual protocols
... and then sections with bindings into OCF, LWM2M ...

Mccool: who will standardise the coap binding
... who will standardise the coap binding?

Matthias: later on the agenda
... for HTTP we need to capture the method name - there is a W3C note describing HTTP in RDF - we can include this
... want to include it - need some help from w3c staff how to include it as a normative choice
... Victor has modelled CoAP in RDF
... should it become a note of the WoT spec?

Koster: we could make WG notes and decide later how to formalize or define a scheme and register with IANA

Kaz: This is a WG note, but please note that this is a Note because the WG who generated the document was closed before making this document a W3C REC. Also it seems there was a breakout session about how to manage vocabulary, e.g., registry. So we might want to check the minutes from that session and talk with those who organized that session. the minutes of the group that produced this note.

Mccool: we should publish the note.
... the problem is to describe HTTP formally in RDF.

Sebastian: prefer the HTTP approach - we could extend this to other protocols later

Kajimoto: our document will refer to various protocols, what about new protocols?

Matthias: new protocols can be defined by @context and including new protocols
... we can decide to include new protocols into the core later

Matthias: this declares a vocabulary, but not a linked data vocabulary
... we use this markup for HTTP and RDF
... we have the ontology and can generate the documentation

Kaz: the group was closed, so it was published as a WG note. Could become a normative document later.

Matthias: if there are errata, there's no WG to maintain
... who can answer these questions

<kaz> We need to talk with Wendy again about:
(1) What would be the right way to handle vocabulary for HTTP, MQTT and CoAP?
(2) Can we refer to HTTP vocabulary in RDF 1.0?, etc.?

RESOLUTION: add informal deliverables (WG note) for MQTT and CoAP vocabulary

URI templates (revisited)

Mccool: this group wants to participate in the next plugfest. They have complex APIs we may want to test

Mccool: there could be also a name conflict
... if a device is already defined and I use the same name in the parameter and the payload there'S a conflict

Matthias: separates API interface and protocol bindings
... the example takes one parameter into the URI and the other into the payload
... the example takes one parameter into the URI and the other into the payload - there may be naming conflicts, ambiguity of whether the payload is encapsulated in an object

Matthias: this is a corner case - you could define two actions
... we could fix it via extensions. Are there real use cases?

Koster: what if I have different payload format for HTTP and CoAP?
... that also won't work.

Matthias: it is unlikely that devices have multiple protocols with this kind of problem

Mccool: some cases have mixed protocols - in the worst case you have two TDs
... I prefer the original proposal.

Matthias: the developer of code has to look at the TD anyway, so he can handle it in code

Zoltan: when we consume a TD and call an action - can we make a map of the consumed thing and use it implicitly?
... variables are used for generating the URI

Zoltan: we have real applications- how does the end user handle that?
... what is the use case? if you change your service you just change the app. Is this part of the service or the datamodel?

Mccool: I have a 5th proposal: like proposal 4 , but with a rename option in the TD

Matthias: if we can resolve, it goes into WG, otherwise the IG
... suggest to merge binding call into TD call

Joint JSON-LD Session

Matthias: there are also people participating remotely
... as you know TD makes use of JSON-LD
... one aspect is readability for the developers to understand the TDs, other aspect is the LD part that is machine readable
... we had a preparation meeting with Greg on tuesday
... one requirement is defining the @id
... the goal is to do that without the @context
... it should be possible to have a pure JSON without any linked data
... this requirement was given by the developers
... as you can see you write the context like this which is a bit complicated
... it would be better to have an id alone like this
... we have this requirement in the WoT WG and we want to see what JSON-LD guys think of it

Gregg: this looks like a straightforward solution
... it doesn't solve everything you want to do
... the primary change to the processing rules would be local (?)

Leonard: that id is particularly useful if you want to refer to a specific node
... but if you have a separate id, then call it something other than id

Matthias: we want this identifier to work like your id but the people who don't know can still use it

Jose: will td+json be a different ...?
... so it will imply a particular context

Jose: my problem is that we have a new media type
... instead of using existing standards
... and also new processing rules

Matthias: that is fine in JSON-LD WG but WoT WG is broader
... there are people who want a defined a format, classically defined
... we have many people with different background
... that is why JSON-LD doesn't apply to everything
... that is why in IETF we rely in explicit media types to enable M2M communications

Matthias: there is framing if you want to use JSON-LD
... you have to option fill it in because you have the preprocessing
... we need JSON-LD framing to these filling
... you cannot do it with just @context

Matthias: there are multiple ways to do it
... the straightforward would be to define a new media type

Benjamin: I would hate to see a path that leads into a lonely direction
... like as if someone replaced the curly brackets with corner brackets
... you lose the community with all the tools
... the fewer media types would mean that there is less tools floating around

Matthias: but this constrained media type model doesn't scale
... there is now multiple combinations
... so we are not confident that we will solve all the problems
... we want to define a mediatype so that we can define an algorithm
... we want to go this way because we have these specific processing rules

Gregg: certainly one of your requirements
... the fact that we are with these non fixed things

Matthias: to explain this, we have this @container
... here is this example on how it would look like for the td
... ifwe look at this in a processing step
... pump status has this @id
... if we convert into triples
... we have this first part that is nice
... we have these statements that pump status is set to false
... writable set to false
... now these URIs are the same because the / is missing
... people are confused on why the / is not added automatically
... we have this @container solution
... compacting should also work
... our argument is that a lot of usage of JSON works like this
... that is why we would advocate this feature in JSON-LD
... do you need an @ based @id

Matthias: this is not something that can be or should be rushed
... there is definetly need for preprocessing
... best of both worlds
... json for developers and ld for semantic processing

Robert: is it possible that same property would be used in different parts of the tree

Leonard: you are not creating reusable objects
... it doesn't do other references, it is self contained

Matthias: they are handmade, a nuclear plant that is unique, one of a kind
... iot schema and ocf define these reusable parts
... we have use cases, like the Oracle cloud, it is out there, designed like that

Gregg: certainly the the usage case for json ld was ...
... this is deployed code I guess so there is no way to change it

Matthias: in our algorithm we will do these slashes
... if you use a json structure
... there is a hierarchy that these are different scopes
... so working in iot for a long time now
... there are lot of projects there are a lot of projects
... who do this slash

Matthias: working group will go until june
... with a possible extension
... I heard you in the internationalization discussion
... we also have human readable fields
... so far we thought that a construct like this would be enough

Ivan: the language spec covers a lot of specs
... the problem is with language text that mixes both directions
... language spec doesn't cover these kind of cases

Ivan: bidirectioanlity, ruby ...
... other groups hit this issue as well
... but that is the problem, it is up to you to decide
... while we know that we cannot express everything ... the internationalization review will not be "nice"

Ivan: think of the case where you have a machine that has a number in the name and you send it to Iraq and you have big problems.

Ivan: as I said if you can convince them, in practice these are, rare
... so it is an acceptable risk, in inverted comas :)

Matthias: if these numbers are mixed, they would destroy the machines or something

Benjamin: I was tasked with the json-ld
... ? ... without the whole html parser kit
... who know what it will turn into

Ivan: it is slightly better than that
... unicode caracters indicate whether they are written from left to right or rtl
... arabic is by default a bidrectional language
... web applications has a table in the end
... written by richard ishida

Ivan: the fundamental problem from json ld point of view
... rdf never handled the bidirectionality

Remote context

Matthias: danbri gave an issue
... in our WG
... DanielP has said that xml solved it by registering your xml resolver
... these context files are stored locally
... we can say that the implementors should be aware of that

Benjamin: this is not related to that, packaging as a potential option
... short living signatures
... cache this hash, if you find another request hash that one

Matthias: we will work on that for sure
... maybe some knowledge from how fw updates are done in IoT

Benjamin: this is a generic web problem
... it has been in the web for a long time

Matthias: is it forbidden to have prefix registries
... if you have issues with that it would be good to hear that

Matthias: So i know that there are some discussions going on about these verifiable claims

Matthias: I was assuming that you were talking about the W3C activity
... thank you very much, for me it was really useful
... we now know about the timing issue
... we would like to stay in touch developing this

Robert: thank you for inviting us, very clear slides and all those who were present in spirit!

Day 2 - 26 October 2018

Present:: Kaz_Ashimura, Jose_Manuel_Cantera, Michael_McCool, Ege_Korkan, Michael_Koster, Kunihiko_Toumura, Kazuo_Kajimoto, Ryuichi_Matsukura, Takeshi_Yamda, Federico_Sismondi, Daniel_Peintner, Dave_Raggett, Hiroyuki_Sugiuchi, Lionel_Medini, Arnaud_Braud, Toru_Kawaguchi, Ryo_Kajiwara, Feng_Gao, Sebastian_Kaebisch, Tomoaki_Mizushima, Michael_Lagally, Matthias_Kovatsch, Shinsuke_Inamori, Hiroshi_Ota, Keisuke_Minami, Francois_Beaufort, Reinaldo_Ferraz, Qing_An, Zoltan_Kis, DarkoAnicic, Boaz_Sender, Simon_Pieters, Youngsun_Ryu, Michael_Smith, David_Singer, Eric_Siow, Yoshi_Tanaka, Jia_An, Hiroshi_Fujisawa, Mohammed_Dadas, Helena_Rodriguez, Takeshi_Horiuchi, Judy_Brewer, mlefranc, Bert_Bos
Remote: Maxime_Lefrancois, Taki_Kamiya, Tetsushi_Matsuda
Chair: Matthias, McCool, Kajimoto
Scribe: Koster, Daniel, Dave, Kaz

<inserted> scribenick: mjkoster

Update on ETSI ISG CIM work

Slides

presentation from Jose Manuel Cantera on ETSI NGSI

Jose: NGSI-LD is based on json-LD and describes entity types, entities, and attributes
... NGSI follows a RESTful approach to API design and also has a pubsub model using webhooks
... entities have formal relationships with other entities following the property graph approach, i.e. provides properties for relationships
... also allows properties of properties
... (presents example)
... entity type vehicle, property of brand name
... the example describes an accident with a number of actors and relations
... vehicle has a location, accident is "observedAt"
... s/At"/At" some time some time
... THe API exposes the entities for RESTful operation and queries
... we call it a temporal API because it can be used to predict
... not strictly historical
... a subscription is a type of query that results in notification via webhooks, as previously noted
... we don't use SQL or SPARQL languages but prefer a simpler approach
... we allow queries by entity type and relations

Sebastian: are queries allowed in th epayload?

Jose: only in the URI, it is more RESTful
... we use GeoJSON
... all results are returned in a single compact array format
... thoughts on interoperability with WoT
... thoughts on interoperability with WoT
... bring WoT Things into the NGSI-LD system by accepting Thing Descriptions
... establish a relationship between the entity and the WoT thing
... it can work with semantic annotation in a TD
... we need to find a way to describe a room and the things in it with their relationships
... considering how to map events that trigger actions in the management layer
... considering how to actuate things using TD
... important to interoperate with WoT to make it easy for developers vs. lower level systems
... (presents a list of links for further study and investigation)

McCool: we have a threat model that could be extended to general IoT threat model and we can share the concepts

Jose: (presents roadmap for NGSI-LD with FiWare)
... Thanks!

Matthias: there is a lot of good experience we can share
... we should work on aligning terms like Thing Description

McCool: we can work on discovery

Koster: we are conceptually aligned on entities and Feature of Interest and the integration pattern

Matthias: +1
... we are working on setting up a W3C CG for the semantic vocabs
... had a discussion with Orange also on the property graph patterns

Jose: we did some investigation and found that the number of nodes in the graph explodes when mapping to RDF
... there may be a better mapping model
... it needs a lot of intermediate nodes

Matthias: please keep us updated on the progress on property graphs
... and on the alignment with RDF

McCool: we need to evaluate an implementation of property graphs

<ryo-k> W3C Workshop on Web Standardization for Graph Data https://www.w3.org/Data/events/data-ws-2019/cfp.html

<kaz> [ ALL, sorry but it seems the PC for webex connection got rebooted. so please wait a moment. ]

Dave: there will be a workshop coming up on property graphs
... (describes a bunch of stuff around the workshop with a sales pitch)
... i.e. please particiate

McCool: there is a SensorThings API with queries built into the API, also the NYC has implemented some query languages

Architecture document

Matthias: especially need to look at use cases
... need industry cases to be covered
... looking for more diverse material

McCool: We could provide some material for the security section
... we are also extending the functional requirements
... cleaned up the structure to improve the explanation of the concepts and architecture
... starting with common IoT architecture
... going into how Wot works with IoT architecture
... describe the constraints e.g. URI addressing
... then describe some abstract flows for interactions that we can also use to explain binding templates
... then explain the building blocks
... then describe implementation of servients
... next section explains deployments with servient roles, e.g. devices, proxies, applications
... also describes directories and discovery but this is informal since it's not in the current scope
... then describe integrations and plugfests
... finally the security section
... the security section also covers alot of general IoT concepts, e.g. the threat ontology

Matthias: if anyone has time to help with this document, please let us know

Sebastian: we need to work on alignment of the figures

Matthias: the examples show one way we could normalize the figures

Industrial use cases

Lagally: this is a summary of IoT use cases from Oracle perspective
... predictive maintenence, real time monitoring, and other categories
... also some specific application domains, e.g. cold chain management, utilities, oil and gas
... Smart Cities, Environmental monitoring
... Smart Buildings

Koster: we can say "climate change"

McCool: I see a few more we can add, but it's already a big list

Matthias: what are the use cases that need integration across application domains?
... These are the real applications for Web of Things

Dave: when there are many producers and consumers

McCool: when there is data sharing
... maybe we can define like 5 characteristics related to architectural patterns
... or some way to aggregate into groups

Lagally: the list is aggregated by vertical

Matthias: we should be focusing on those use cases that need integration

McCool: (restates the conclusion around use cases that need integration)

<mkovatsc> https://github.com/w3c/wot-architecture/blob/38a4bdaaee0f3226e6f783419b56b22d0addea95/proposals/Industrial%20IoT%20Use%20Cases.md

Kaz: can we link functional requirements to use cases?

Matthias: yes, that's the idea

<inserted> and maybe the discussion from this session could be a good starting point for that purpose

McCool: and maybe there are different patterns for different scenarios

Matthias: terminology needs to be improved
... the new terms are hard to learn
... we tried to change the terms be used but they are all important and meaningful to the group
... so we need to document what terms we use and do a good job of explaining to newcomers
... (proposal is to keep the terminology and make a good explainer)

Jose: it was a challenge to find the examples to help understand WoT

Lagally: could we start up a Q&A to capture these issues?

Matthias: feedback is welcome so let's work together

<McCool> https://github.com/w3c/wot-security/blob/master/presentations/wot-security-tpac-10-2018.pptx

Security

McCool: I will summarize 3 hour meeting on Monday and other recent work, and some other small topics
... coap security schemes added to the security test
... question about how strong the guidance needs to be, e.g. should vs, SHOULD
... security considerations document is done but needs to be strengthened
... (monday October 22 meeting summary)
... functional testing and adversarial testing are two different things that we track separately
... we are working on how to use https locally
... also working on object security defined as a content format
... defining adversarial tests
... (describes https local ideas with oauth and forms and overrides)
... strawman proposal for local https modeled on coaps
... presented to the local WG
... the local WG is looking for things that work with browsers
... their schemes all have some issues and there is no firm recommendation
... (discusses some of the issues)

<ryo-k> httpslocal CG F2F Agenda (took place yesterday) : https://github.com/httpslocal/group/wiki/Meeting2018Oct25TPAC

McCool: psk could be made to work but there is additional specification required
... recommendation to not develop this in our spec but work with upcoming implementations
... it's not baked yet

Ryo: we don't have a concrete roadmap for which proposal(s) to follow up on
... also they hav eexternal dependent orgs like IETF
... but as of now there is no concrete direction maybe in 1/2 year

McCool: machine to machine is solvable but might not be the same solution needed for browsers
... there is a best practices section which lists the configurations that achieve a minimum required security level for testability
... looking at discovery security and TD signing
... finally, we are working to develop adversarial testing

Jose: how are TDs distributed?

Matthias: the distribution of TDs is not in scope for the WG
... it is use case dependent
... there is Thing Directory but that is a topic for the new charter

McCool: we are trying to first mitigate the risk of surveillance and tampering
... need to go through the document and make security assertions

Matthias: also we need to define what is expected from an implementation

McCool: deferring the work on Security Definitions
... there is not a big need for this

Matthias: this comes from implementation experience where there is work for an implementer to do research
... people prefer to have security definitions at the top level of the document

McCool: OK, we will look at restructuring the document with a definitions block

Matthias: we should create a workshop to address this

Koster: smartthings would like to participate in a workshop

<McCool> https://www.w3.org/TR/wot-security/

McCool: proposing a terminology change from URI
... (showing some examples from BP document)

<McCool> https://github.com/w3c/wot-security/blob/master/wot-security-best-practices.md

McCool: we don't need some of the content, moving some content, etc.
... the important part is transports and their security schemes

Matthias: TLS 1.3 is pretty new and might be approached cautiously

McCool: should we simplify the testing by removing things from the document we don't test

Matthias: propose to keep them in as informative terms

Sebastian: how do we add new upcoming security schemes?

McCool: we develop a general extension mechanism and test it with some cases
... it needs an implementation and a test

Matthias: we need to look at how it will work with terms in the controlled vocabularies
... it comes down to whether an implementations can understand the terms and correctly act on them

recess until 11:00

<boaz> present

<dape> scribe: dape

Test Suite Requirements

Mike: work for W3C (Japan)
... involved in testing HTML
... have test suite with ~200 specs
... github web platform test
... open source, not controlled by W3C
... other organizations involved too

<kaz> General requirements/resources on testing

Mike: wold like to hear testing plan.. so that we know how we can help

McCool: WoT not browser oriented spec

<McCool> https://github.com/w3c/wot/blob/master/testing/wot-test-plan-tpac-10-2018.pptx

<kaz> General requirements/resources on testing

Kaz: wanted to provide basic resources (see md)
... from CR to PR we need implemenation experience

McCool: No substantial changes after CR?

Philippe: possible. but requires to go back

Kaz: What implemention experience?
... browser example... implementation for each feature in IE/Chrome/FF/..

McCool: test pairs of implementations (at least 2 pairs)

Matthias: in browsers client side tests only
... in WoT there are tests for each side (server&client)

Kaz: need to different sections in report, one for client and one for server

McCool: node-wot client vs node-wot client is ok

Simon: in W3C there is custom server in pyhton ... can be used to do more complex stuff

McCool: different validation/testing tools.. e.g. security vs dataSchemes

Kaz: test report can mark optional/required feature ... number of passed implementations

Boaz: Not sure what we are doing right know...

Matthias: WoT group tries to figure out what other groups did w.r.t. testing

Kaz: web platform test might not work in all cases for our use-cases

<zcorpan> https://wpt.fyi/

Boaz: interesting. worth showing how web platform tests look and work

Federico: difference between "test results" and "interop"

Boaz: can test custom protocols

Simon: e.g. also websocket

Matthias: reference websocket server?

Simon: websocket server implementation...

Matthias: test results for websocket also...

Simon: no tests for server side
... server needs to be correct
... server developed organically

Matthias: we need server side also

Boaz: first time we would do that... interested in doing that

Matthias: server side might be out-of-our control

Kaz: most of our implementation is not browser-based
... other testing framework... TV browser-related

<boaz> can you paste a link to this?

<boaz> kaz, can you paste a link to that site?

Boaz: what is the timeline?

Kaz: 2 months

McCool: asked for extension
... June

Boaz: should start sharing materials
... are already sharing material with node.js
... Bocoup is interested in verifying submitted data

McCool: most of our systems run node.js

<boaz> kaz, can you link to the wave report that you had up?

Kaz: automotive did testing also. WoT can do the same

Matthias: We got experience in our PlugFests
... automatic testing woud be great.. but I do foresee also manual steps

McCool: Timeline
... charter extends to 30 June 2019
... REC 27 June
... PR 28 May
... CR 16 April
... "at risk" feature can be removed

Simon: minimum time in CR?

Mike: there is.. not sure out of my head
... believe less than 6 weeks

Boaz: need way to show spec conformat impls for enter/exit CR

McCool: starting CR we should be sure assertions do not change
... have functional and non-functional testing
... functional testing: traditional, TD validation etc
... non functional testing: security, robustness
... Scripting API is separate

<Zakim> MikeSmith, you wanted to comment

Mike: wanted to make sure. web platform tests are mainly for browser apis
... main benefit: all browser run test for CR
... get good characteristics
... do not see real benefit for non browser APIs at the moment
... possible.. but maybe not sensible
... use separate repo

Simon: W3C process: should make it as smooth as possible.. not entering CR until tests are fine
... avoids entering CR multiple times

Mike: no point starting CR when still unsure when exiting CR

Kaz: need to check progress

Matthias: No need to are in CR for testing

Simon: Correct. start before

Singer: testing shows no issues --> ready for CR/REC

Lagally: 2 thoughts
... validate TD.. fine
... behaviour testing...
... was thinking about "describing what we want to test"
... concrete reference devices

Matthias: we have a "test thing"
... tries to cover corner cases

Lagally: Not complete yet... see uri templates et cetera

Matthias: sure...
... need to collect more input

McCool: discover all features
... proving all features

Matthias: BTW: our job is not that OCF device behaves properly
... our job is about TD

Kaz: should concentrate on TD assertions first

McCool: did have preliminary scan through assertions
... marked assertions and have tool to extract them

Boaz: wanted to say more about browser testing

<boaz> kaz, can you share a link to the wave test suite you showed?

Lagally: question about test categories (adequate representation of target eco standard)

McCool: tested it in PlugFest, but need to document it

Boaz: i think this point is beyond CR testing and their needs

<taki> +q

Kaz: suggest separate topics into (1) testing for spec transition and (2) more advanced ones

McCool: lets correct items under "behaviour testing" (on MCC slide)

Lagally: reference test thing used for advanced testing?

McCool: think so
... >back to assertion test collector<
... some of our assertions can be handled by "is JSON valid"
... Ege proposed "postive" and "negative" example

Taki: the earlier we have test framework... the earlier we get feed back from outside the group
... --> should publish testcases and framework soon...

McCool: hope to get this up on github soon
... have set already
... 2 pairs needed (server/client)

Ege: TD is only contract between 2 devices
... can test whether client creates correct requests

Matthias: parts of tests are for REC
... others are good in general.. (interoperbaility)

Ege: trace can be used for testing

Matthias: clients creates right request, ..and gets/interprets response

Lagally: question also whether JSON schema in annex conforms to the rest for the spec

McCool: make sure assertions are clear (not to vague)
... I can do the tooling#
... we have several tools we need
... JSON Schema and JSON-LD tools
... need to figure out which tools are needed

Matthias: Question: How is HTML spec tested (document format)

Simon: question how html parser is tested?
... tests live in separate repo, html5
... different kinds of tests

<boaz> https://github.com/html5lib/html5lib-tests

Simon: tests for tokenizer
... difficult to run in WPT
... tests... compare DOM tree in browser with DOM in format
... tree builder tests

Matthias: expected DOM... how is this represented?

Simon: custom format

see github repo

Matthias: how is comparion done

Simon: custom runner.. able to parse this format
... for WPT runner.. own parser written in JS
... comparing browser DOM and virtual DOM

Matthias: have something similar.. scripting API
... BUT needs to be tested separated

bouz: parsing natively implemented?

Matthias: in node-wot it is TS implementation
... Panasonic is browser-based

Simon: represent object in JSON?

Matthias: TD is JSON already
... not exact roundtripping...
... client just needs to parse JSON.. not produce JSON

Boaz: browser implementations run in sync... exporting/importing tests

McCool: like to see this kind of automation

Matthias: Believe we have to deal with mixture
... work on automation step by step

Boaz: Implementors should be able to "push the button" to run the test
... aria practices guidelines table look similar to your.. worth looking at it

<mkovatsc> https://github.com/w3c/aria-practices (?)

McCool: Gaps and Issues
... non functional testing
... we have some assertions that are too broad.. and some are to narrow

<boaz> https://w3c.github.io/aria-practices/

<boaz> and here are the examples source code: https://github.com/w3c/aria-practices/tree/master/examples

<boaz> ^ mccool

McCool: should focus on functional testing
... ToDo's
... look at assertions carefully
... to exit CR we need complete sets of tests
... example and counter example

Kaz: finalize test preparation before CR

Simon: correct.. that would be my suggestion also
... how do we approach manual tests in WPT
... use test drivers
... e.g. clicks on coordinates

Koster: emulator?

McCool: would be a good solution
... wrap w.r.t next steps
... make sure assertions are clear

Dave: can we group up the work

Sebastian: we have some new stuff in TD
... still some open issues on github w.r.t. TD

McCool: when do we say "no new features"?
... we need last day like freeze in January

Matthias: start with assertions for stable stuff

McCool: will start working/organizing tool.. creating reports

Matthias: got inspiration from other testing reports
... white for not implemented, green pass, red failes.. row per test case

column for test pairs

Sebastian: new TD slot... test discussions should take place there also

Kaz: should start test work soon

McCool: Focus testing in Online PlugFest also

RESOLUTION: we'll start initial review on test assertions in 2 weeks with the TD TF; concrete time slot to be determined

<inserted> [lunch till 2pm]

<dsr> present?

<dsr> scribenick: dsr

Smart Cities Proposal (Michael McCool)

This is something we’ve been discussing for quite a while now within Intel

The opening slide lists the people involved so far

From a business perspective, the diversity of the IoT inhibits scaling, slowing growth

Smart cities seem like a domain which has a great deal to gain from establishment of open standards

There is a proposal to launch a W3C Business Group and to enage in pilots

The early market with early adopters is qualatively different from that for later adopters post the chasm

Early on different vendors push their own proprietary solutions, but later the market matures and grows as open standards are widely adopted

We want to motivate and enable cities themselves to articulate use cases and requirements

The ultimate goal is to enable economies of scale

A McKinsey survey identified New York and Singapore as two successful first mover smart cities

They both implemented an online data portal for others to create applications

Applications are typically not portable to other cities due to local contextual requirements

NYC adopted a proprietary approach for making data available. Singapore went down the route of CSV files.

McKinsey talks about the technology base, open data access, and the application ecosystem

Open data access an an open application ecosystem needs standardisation to scale

Michael shows a crowded slide for IoT standards and reference architectures

Many standards and tools for ingesting and managing data

User interfaces provide value through visualisation and control

W3C’s strengths include user interfaces (web browsers) and metadata (RDF, Linked Data and a suite of associated standards)

Metadata management and semantic modelling are key missing elements in many other standards but are necessary to manage and combine data from diverse sources

W3C Web of Things provides simple clean way to describe devices and services. The Linux Foundation’s OpenAPI defines a way to describe Web APIs.

We want to work with W3C’s Alan Bird to launch the Smart Cities BG and to feed emerging use cases to drive technical requirements in the WoT IG/WG

We want to do so in collaboration with other groups outside of the W3C

Some discussion about the security scaling challenges

Smart cities nonetheless have difficulties with running their subways (metros) and heavy traffic

Michael: different kinds of cities have different problems to overcome

Cities can be classified into groups by their most important challenges

Michael notes that we are expecting to focus on deep analysis for a few problems rather than an overall top down approach

Lagally: do we expect new use cases to emerge (after the list he presented this morning)

yes

mkovatsc talks about the architecture document which includes that list. The Smart Cities BG will come too late for our short term deadline for the WoT architecture doc.

jbrewer: we’re very interested in plugging in to the scenarios and use cases in relation to accessibility

Michael: one example is helping people to discover accessible entrances for buildings

Accessibility also relates to support for aging populations in cities

an increasingly important topic for smart cities

IoT.schema.org

mjkoster introduces the context for the work on semantic vocabularies and the role of iot.schema.org

Darko is collaborating with Michael Koster on this. He talks about some work based upon Node-RED for designing simple applications

An example involving a CO2 alarm

Node-RED supports event flows across a graph of components

You use a graphical interface to add components to a canvas, to connect them up and specify the handling behaviour.

Adapter components (nodes in Node-RED) can be used to broker between other nodes that are not directly compatible, e.g. due to using different physical units

The Node-RED demo uses nodes designed with iot.schema.org vocabulary

This could be offered to people contributing to WoT plugfests and interested in creating mashups

McCool: How far can this go?

Darko: this is currently based upon thing directories for the set of nodes

<kaz> kaz asks Darko if he would participate in the upcoming plugfest using this mechanism, and Darko says "yes"

<inserted> it would help people implement servients easily

Koster: I presented iot.schema.org at the SSN workshop last week

<mlefranc> Link to the SSN workshop webpage: https://ssn2018.github.io/

We’ve created a charter for a W3C community group, and one of the reasons for the CG is to provide an IPR framework

We’ve created some introductory materials

We’re looking at integration with schema.org perhaps a sub-domain

Matthias: schema.org focuses more on ecommerce

Some commentary on developer tools

<mkovatsc> ... and hence has conflicting classes. The subdomain is most likely necessary

We can map existing schemas in different formats into TDs and then annotate them with semantic descriptions

We need to get the CG running with the new charter

Amelie Gyrard has done an industry wide survey of existing definitions

Michael talks about integration with other ontologies

The web of things TD is a crucial ingredient

Bruce Nordman has worked on vocabularies for smart energy

(perhaps similar to the European work on SAREF?)

Dave needs to chat with mjkoster on conversational agents (chatbots) and future W3C workshop

Web of Things Roadmap

<mjkoster> https://github.com/iot-schema-collab/teleconferences/blob/master/iotschema-status-20181026.pdf

Current charter ends 31 Dec 2018. We will get a 6 month extension within which to get our work items to REC

<mjkoster> (the iot.schema.org slides)

We are encouraged to recharter the WoT IG as soon as practical

charter for 30 months to sync end with rechartered WoT WG (assuming it is rechartered at the end of June 2019)

IG charter to work on incubation and liaisons

Mozilla want to avoid wording precluding developing a Web platform, so we need to figure out some tweaks to the IG description

Initial planning for a WoT workshop for technical audience and out reach around the RECs

McCool: we’re also talking about a separate (non technical) workshop on smart cities

Matthias: we’ve also expecting to incubate work on simplified APIs layered on top of the existing API

We want to avoid blocking constraints between the different groups

The smart city workshop could be later - in September

Some discussion about possibility of re-entering CR if we discover the need for changes. McCool would prefer a more solid spec before entering CR to reduce the likelihood of such circling back

lmedini asks about packaging of web applications

McCool: this is something that could be incubated in the IG

Dave notes that this relates to requirements for open marketplaces

we could have an IG task force on open market places that looks at discovery, packaging, licensing etc.

Matthias: the rechartered WG would focus on maintenance

Dave: we could have an AC review with very small addition if the IG wants to move a new work item over to the WG

The aim is to keep the lawyers happy

Kaz: there is an option for creating additional small WGs if we think that appropriate

Koster: too broad a charter could be counter productive

McCool: our immediate priority is to freeze the specs and develop the test suites

<kaz> Matthias: is everybody happy with this plan?

<kaz> (no objections)

Possible iot.schema.org CG

<DarkoAnicic> iot.schema.org CG Charter: https://github.com/iot-schema-collab/intro-materials/blob/master/wg-charter.md

mjkoster comments that he wants to focus on commonalities not features of interest that are diverse across devices and domains

the objective is to develop a process for work on vocabularies

consensus driven, and a light license with minimal restrictions

Contacts: Koster, darko, and Danbri

Darko: tools could be something we need to work on

Koster: the CG needs to focus on vocabularies, but perhaps not tools

Dave: I would like to see some consideration on metrics and tooling for measuring an analysing adoption of vocabularies

Sebastian: I have something to report on that topic

Koster: the next step is to review the charter to see it matches our needs. We want to apply the charter to the WoT CG to take advantage of the large set of contacts

McCool: perhaps a CG name that is more specific to vocabulary development?

Matthias: what’s happening in the CG currently

Dave: nothing, but developers will be very interested in work on vocabularies

Matthias: there are arguments on both side

Koster: a survey could be helpful on the choice of name and to get feedback on the charter

Dave: a survey would be good , I got 75 lengthy responses to the one I did last year on behalf of the Open Data Institute on vocab development

you could announce it to the current CG members and try to reel them in for the new work

<kaz> [break until 4pm]

<kaz> scribenick: kaz

Next Online PlugFest

Matthias: would check the schedule
... good to block several days
... one of the achievements was setting up the infrastructure

Lagally: we can host the infrastructure

Matthias: everyone set up the infrastructure reachable
... people meet again online
... discussion online/offline
... testing instances
... first week of Dec?
... any conflict, e.g., with OCF meeting?

Sebastian: not good for me

Matthias: proposal: 3-7 Dec. 2018
... conflicts: Sebastian, Toru
... let's cover several candidates
... Proposal: 10-14 Dec.

Kaz: maybe depends on the time as well as date?
... do we need to do all the 3 slots?

Matthias: brought up node-wot on the new eclipse site, etc.
... would envision something...
... on Monday, everybody on their timezone set up the infrastructure
... also talked with Federico about VPN
... first need Web interface
... but need some configuration

Koster: Federico and I had some discussion
... shouldn't be hard to set up the configuration

Matthias: multiple members will login
... so multiple connections required

Koster: that's the goal anyway

Matthias: did you talk about concrete timeline?
... e.g., 1 month?

Koster: yeah
... could work for that

Sebastian: question about tools to Ege

Matthias: test tools
... automatically send commands to the tool?

Ege: VPN, etc., shouldn't change the test results

Sebastian: good to have kind of dashboard
... e.g., who/what is online

Lagally: want to test on the simulator as well?
... would be useful

Kaz: wondering about proxy and directory
... already included in the "infrastructure" part?

Matthias: regarding proxy, we don't really need it given VPN
... should have joint call on Friday
... and feature table we discussed during the testing session

Ege: can generate an initial one
... based on the assertion list

Matthias: we should work for all the assertions for full coverage

Kaz: if we need a test but it is not included in the spec
... we need to update the spec

Matthias: update test spec
... prerequisites, stimulus, expected results
... question abou thte basic plan?

Lagally: comment on "Monday"

Matthias: friday before to satisfy JST
... Yamada-san, what about you?

Yama: ok

Toru: wondering about the spec to use

Matthias: this basic plan just mentions "one week from Mon to Fri"
... we can pick up concrete date
... what about "Prerequisites"?

Ege: the name of the test bench is "WoT Testbench"

Lagally: and "TestThing"

Matthias: some problem with cases
... our current direction is camel cases
... we have to precheck
... new vocabulary to add as well
... playground to be updated based on the latest draft

Sebastian: TD to be fixed by the end of Nov?

Matthias: shows a big table of language coverage
... this is not for our spec
... but number of implementations here

Sebastian: meaning of the colors?

<mkovatsc> As inspiration only: https://w3c.github.io/typography/gap-analysis/language-matrix.html

Matthias: we ourselves can decide how to use the colors

<mkovatsc> https://github.com/w3c/wot/blob/master/plugfest/2018-sept-online/preparation-TEMPLATE.md

Matthias: next our own test plan
... this list is not complete to cover our specs
... need to merge with actual test cases
... Sebastian, what about the TD spec?

Sebastian: by the end of Nov?
... deadline with what to do
... to generate a table on implementation results
... probably including a plan
... like preparation.md

Kaz: yes
... W3C WGs used to publish something like that as an implementation report plan

Matthias: would suggest we start with clarifying what to do first
... and then automate it

Kaz: +1

Koster: we should include information on the components of the testing environment, e.g., node-red, node-wot, ...

Kaz: +1

Matthias: please send detailed implementation information to Matthias
... Koster and Ege ask Federico about F-Interop mechanism
... Sebastian pings Ege for playground
... Matthias/McCool work on the test spec
... regarding the date?
... probably we should organize a doodle again

Kaz: after making decision on the basic date/time
... would be better to use a spreadsheet to manage the concrete slots

Next f2f meeting

Kaz: Tokyo, Japan hosted by Keio
... checking with the Keio Headquarters

Matthias: when to enter CR then?

Kaz: Feb at the latest is the suggestion
... and we can review all the provided reviews/comments on GH at the f2f

Matthias: CR: ideally Jan, latest in Feb
... failed if Apr
... (updates)
... ideally in Jan, recommended in Feb, latest in Mar, failed if Apr
... would it be better to have f2f earlier?
... plan to freeze and ship CR at end of F2F?

Kaz: in that case, we don't have to stick with the option in March at Keio

Koster: could check within Samsung

Matthias: for member representative
... who can check possible locations?

Koster: wondering about the cost

Matthias: meeting room, network, catering
... but doesn't have to be provided other than the meeting place

Koster: can check

Matthias: any possibility for Keio in Jan?

Kaz: need to check

Lionel: just fyi, Web Conf in May in San Francisco

Koster: how many days?

Matthias: we can skip openday this time
... Sumsung (US or UK): Koster to check
... Siemens (US): Sebastian to check
... next
... 2nd WoT workshop
... had discussion with the W3C Management
... marketing event for specs
... would target May
... after publication to get comments
... may want to invite automotive companies as well
... possibly have a separate session on smart city and invite the (expected) smart city BG
... purpose: promote W3C WoT RECs
... location:
... Web Conf in San Francisco in May

Kaz: would suggest we hold our workshop separately

Sebastian: +1

Matthias: could have a mini-workshop or a W3C track session there

<lmedini> WWW2019 workshop call: http://www2019.thewebconf.org/call-for-workshops

Sebastian: btw, having that possible satellite event under the "location for the wot workshop" section is confusing

Matthias: moves it to another section of "satellite event"
... we should think about the program committee
... Sebastian Kaebisch, Michael Lagally, ...
... duration: usually 2 days

Sebastian: should set the date already

Kaz: it usually takes 6 months for preparation

Matthias: would check people's potential conflicts
... 22-23 May 2019, Munich, Germany?
... note: AC Quebec on 7-9 Apr

Next steps for TFs

Matthias: WoT Architecture
... new WD within 2018

Sebastian: good to finalize early since there are references from TD

Matthias: TD
... update for online plugfest
... close issues
... target freeze?

Lagally: some of the GH issues are marked as "next iteration"
... would be better to use another label like "need more discussion"?

(discussion about possible labels)

Matthias: will continue the discussion during the main call
... thanks a lot for joining the f2f meeting

[wot f2f adjourned!]

- DRAFT -

WoT f2f in Lyon

25-26 Oct 2018

Contents

Summary of Action Items

Summary of Resolutions

PlugFest Day 1 - 20 October 2018

PlugFest Day 2 - 21 October 2018

Developer Meetup - 22 October 2018

WoT Demo - 24 October 2018

Day 1 - 25 October 2018

Agenda