Group photo from the OpenDay on 30 January 2019
Group photo from the WoT F2F meeting on 31 January 2019
(Some more photos are available online :)
Sebastian+Ege: gives instructions for today
and tomorrow
... assertion test for today
... behavior test for tomorrow
Expected deliverables from the TestFest
Device servient implementation summary
Ege: all the implementors are encouraged to put all the CSV results (and TD as the source of those results) under the 2019-princeton directory of the GitHub repository
Expected deliverables from the TestFest updated based on today's results
Where to install what on GitHub
McCool: goes through the report.html on his local pc
McCool: Hitachi did interoperability part
as well
... that is not priority for this time, though
staticaly rendered version report as of Jan 29
McCool: Ege has updated the assertion test tool
(note that Ege put a note on the whiteboard saying that 5 features have problem with the tool)
McCool: will revisit Ege's tool
... in hour or two, will explain the new setting
... should mention that features with underscore are not listed
here in the main table within report.html
... service assertion separately described
... we have gaps there
... would add that later but we'll remove that part from the final
implementation report
... make sure you check-in updated TDs and results
Ege: updated the playground/assertion tester
Kaz: by "updated" do you mean those 5 green features with problem yesterday also covered now?
Ege: updates the list of features with
problems
... now there are 3 features
... td-action-names, td-property-names, td-event-names
McCool: talks about hangout setting
staticaly rendered version report
McCool: updated the results
McCool: TDs, CSV results...
... please put your results like this
... shows update.sh script
area for automatically generated results
McCool: sub directories under the company-specific directory will be ignored
Ege: explains the assertion tester's behavior for parent/children assertions
McCool: let's focus on the results here under the "inputs" area
McCool: gives updates on automatically generated outputs
automatically generate outputs
McCool: don't edit this directory manually
McCool: starts the OpenDay
... introduce Kurt
... also thank Siemens to host the meeting
Kurt: compiles slides to introduce
Simenes Corporate Technology
... there is a video as well
... [Milestones]
... [Facts&figures on R&D]
... 5.2 billion Euro for R&D; 40500 R&D employees
... 8100 employees and 5650 software developers at Corporate
Technology
... [Corporate Technology at a glance]
... India, China, US, ...
... [Company Core Technologies]
... [CT RDA - Research & Development in Digitalization &
Automation]
... [CT IP - Corporate Intelletual Property]
... [CT UR - University relations]
... [Charter of Trust]
... implement the technology accordingly
... video ready
... tx!
... enjoy your meeting!
Sebastian: W3C Web of Things - Getting
Started
... glad to present WoT activity now
... giving some kind of introduction here
... WoT is a W3C standardization activity
... started with a workshop at Siemens in Berlin several years
ago
... discussion on technology building blocks
... WG working on its deliverables
... 200 participants in WG/IG
... counter the fragmentation in the IoT world
... there are isolated activities
... to be consolidated
... exploration and liaison
... setting up deliverables, WoT Architecture, Thing Description,
Scripting API and Binding Templates
... PlugFest effort for PoC
... close to submit a Candidate Rec for TD
... [PlugFests to Evaluate Current Working Assumptions]
... pictures
... [Why the Web - User- and Developer-friendly
... Internet of Things
... domain expertise, embedded developers, optimized protocols and
formats
... silos with high integration costs
... hotel booking site as an example
... World Wide Web
... interoperability and usability
... very nice example of collaboration by different platforms
... integrating any applications
... much bigger than IoT domains
... based on the Web technology
... that's why switching to the Web technology
... [The WoT Thing Description]
... first building block
... bring a new thing
... first thing to know
... who are you?
... what kind of functions?
... what kind of data?
... how does the payload structure look like?
... how can I access?
... context information?
... protocols/serialization?
... security?
... relations to other Things?
... all the questions here are answered by the TD
... [W3C WoT Building Blocks]
... other building blocks
... independent from other formats
... work with other protocols
... done by the Binding Templates
... also Scripting API
... normalize the interface
... develop apps using standardized I/F
... also security to be taken care
... taking care of existing security settings
... [WoT Thing Description]
... an example here
... JSON-based document format
... thing metadata
... couple of metadata
... decide what to use
... security metadata
... then
... list of interactions with data schema
... common data definition like JSON Schema
... we don't introduce new data model
... simply use already defined data
... semantic annotatiaon
... JSON-LD format
... kind of like RDF
... existing terms for existing domains
... reuse domain knowledge
... and protocol binding knowledge
... also links
... [WoT Binding Templates]
... instantiated in TDs
... special usage of protocols
... e.g., application/ocf+cbor
... based on OCF
... [W3C WoT Integration Patterns]
... integrate legacy devices
... [W3C WoT Roadmap]
... here Jan 2019 now
... candidate rec to be published
... also working on implementations
... TD spec and Architecture spec
... ready to be published as W3C RECs this year
... also WoT workshop middle of this year
... hosted by Siemens in Munich
... to get feedback and new ideas
... newly generated CG for iot.shcema.org
Koster: recently created a W3C CG
... iot concept and ideas
... semantic modeling problem
... extensions for iot
McCool: various verticals
... e.g., smart city
... several different stakeholders
... smart city business group to be generated
... also looking at other things, e.g., liaisons
... bridging to othr SDOs
Sebastian: [W3C WoT summary]
... [W3C WoT Resources]
... links here
... implementations and tools
... WG participants here
... [Contact]
... questions?
George: api definition?
... how are you doing that?
Sebastian: there is a document
... API definition based on WebIDL
George: something like swagger?
Sebastian: abstract API design
... description of API
... very abstract
McCool: covers various web services and protocols
Kaz: give some more clarifications on
scripting
... expose the device capability and consume it from the app
side
McCool: for orchestration
George: implementations?
McCool: eclipse project for node-wot
implementation
... thingweb, playground, node-red, etc.
... describe existing devices using TD
@@: what is the stance of orchestration?
McCool: node-wot is orchestration
layer
... discover and consume
... run scripts on runtime
Kaz: mentions "orchestration" here means interconnection between various devices and applications using standardized Thing Description
McCool: mentions our demos expected later
Matsukura: [Smart Agriculture]
... computer-controlled agriculture
... plant factory
... Fujitsu's factory here
... completely controlled
... second one is greenhouse horticulture
... last one is agricuture cultivation
... reduce labor of human resources
... using drones, etc.
... [Greenhouse Horticulture]
... features
... ensure a stable supply
... regardless of weather conditions
... temperature, humidity, etc.
... enable stable year-round supply
... increasing product of tomatoes
... advanced technology
... growth is 3-4 times
... [Goals for the project]
... 3 goals
... collect environmental data
... provide services and facilities anyone can install/handle
... enable to use with no maintenance/no damages regardless of
system troubles
... [Experimental fields]
... research greenhouses
... commercial greenhouses
... run by agriculture companies
... very big plants
... 4.0h in Shizuoka, 2.4ha in Miyagi and another in Ibaraki
... [System configuration]
... 100 sensors connected to the cloud
... 5 gateways
... each gw connected with 27 or 54 sensors
... the server aggregates the data
(break due to the network outage)
Matsukura: [Sensor units]
... 27 sensors installed in each fielded
... temperature, humidity, brightness, UV, air pressure, Co2
... also moisture, nutrient
... controller for BLE/LoRa
... extension cable connected with the sensors
... power supply methods: self contained, e.g., solar panel,
battery, AC power
... monitoring every 1 min
... [Area network]
... [Gateway and server]
... local proxy and remote proxy
... WoT core here means runtime on Java
... connected with adapters
... for sensors/actuators
... [Operation management]
... treats network equipment as devices
... [Example of operation management]
... visualization of the actual network topology
... detects problems
... [Summary]
... smart agriculture project started in Oct 2018
... WoT-based system
McCool: questions?
Ege: protocols for various devices?
Matsukura: currently using proprietary
devices and adapters
... some kinds of protocols are already supported
McCool: you mentioned ECHONET
... any relationship?
Matsukura: ECHONET has a lot of
descriptions
... useful to generate new devices
McCool: can we get the URL of the video?
Tobias: will check
UNKNOWN_SPEAKER: [Geospatial and
Sensors in WoT]
... [OTC topics for W3C WoT F2F]
... W3C/OGC Spatial Data
... [The OGC Mission]
... global forum of developers and users of spatial data
... [OGC Members]
... [800 implementations]
... [1000s of Services, 100Ks Datasets Worldwide Implement OGC
Standards]
... [Spatial Data on the Web Interest Group]
... two standards bodies working together towards a Web of Spatial
and (Linked) Data
... use cases and requirements, best practices, OWL Time ontology,
SSN ontology
... fusion of semantic data
... [Spatial Data on the Web Best Practices]
... simple location elements
... [WFS 3.0 Core - Resources]
... [Time Ontology in OWL]
... [Allen Temporal Interval Algebra]
... [New Time-OWL]
... [Semantic Sensor Network Ontology]
... [Observations and Measurements]
... syntactic interoperability and semantic interoperability
... [Sensors and Observations]
... [OGC SensorThings]
... [OGC Standard-based Data Model]
McCool: extending vocabulary
George: [From Sensor to the
Decision]
... [location...]
... [Next Generation First Responder IoT enabled Common
Operation]
... [SensorThings harmonizes both in-situ and...]
... [SensorThings Example - Smart Cities]
... [OGC topics for W3C WoT F2F]
... W3C/OGC Spatial Data on the Web IG
... OGC SensorThings
Taki: the model is based on
observation?
... foi, etc., different between verticals
George: not depending on verticals
... spec itself is generic
... units/measure is another question
Sebastian: we have very simple units
... and also referring to existing ones
McCool: vocabulary terms come from outside
George: similar approach
... can refer to the other units
Lagally: hot to validate devices?
George: compliant test framework
... executable test harness
... using scripted tests
... maintain official test site
Ege: what kind of test suite?
George: team engine
McCool: would be great to have resources on that
George: ok
Sebastian: say something more about test language?
Lagally: [W3C Web of Things + Oracle IoT
Asset Monitoring]
... [W3C Web of Things]
... describe devices (things) in a common ways across device
manufacturers and protocols
... multiple participants
... [Oracle IoT Applications]
... apps: asset monitoring, production monitoring, fleet
monitoring, connected worker
... platform: IoT cloud services including digital twin
simulator
... [Oracle device model and W3C Thing Description
interworking]
... multiple instances
... DM2TD converter converts device model to TD
... property, action and events
... another converter for device level as well
... consume device and expose device
... node-wot bridge/gateway
<taki> Scribe: TK
<taki> ScribeNick: taki
McCool is explaining meeting tools...
McCool: schedule. Sebastian is not available for an hour from now.
McCool: Matthias has time
constraint.
... Zoltan as well.
... Lagally suggested to split architecture session into two.
... one hour now.
... 9:30-10:30
<kaz> s
McCool: we do similar for TD.
... sebastian is available from 10:30-11:30
... zoltan is available after 12:30
Lagally: we can do another architecture session tomorrow.
McCool: 12:30, half an hour
lunch.
... 90 minutes scripting session.
... security and privacy, we can drop today.
... binding templates for an hour.
... 3:30-4:25 security testing
... 4:35-4:30 WoT security best practices.
Kaz: I want to invite JSON-LD person in TD session.
McCool: we have TD session tomorrow as well.
Ege: I want to go through test results.
McCool: everybody needs to take a
look at results.
... make sure test results are same as your expectation.
... for sanity check.
Nakamura: security meta data input, I would like to present.
McCool: meta data is TD. We can also
discuss in security and privacy session.
... we go through the issue as part of TD session.
... maybe tomorrow is better for Nakamura-san's discussion.
... we have some time this afternoon as well.
... can newcomes introduce yourself
Kaz starts self introduction, others follow suite...
McCool, Ege, Lagally, Mizushima-san, Nakamura-san, Taki, Yamada-san, Kawaguchi-san, Koster, Toumura-san, Matsuda-san took turn to introduce themselves...
Sato-san and Fujiyoshi-san from Toshiba introduced themselves...
Daniel Peintner self-introduced...
<kaz> Chair+ Matthias
Matthias self-introduced... remotely participating...
McCool: Sebastian is not present now, but will join us later.
Lagally: let's start Architecture
session.
... restructuing proposals
... one from Matsukura-san and another from Matthias
... after today's sesson, we need to do restructuring.
McCool: Zoltan is remotely participating as well.
Lagally is presenting architecture agenda...
Lagally: can matsukura-san explain your proposal?
Matsukura: straight forward agenda
items.
... intriduction, terminology, use case
... then functional requirements, WoT servient
architecture...
... I wrote whole description.
... I also uploaded deployment section.
<kaz> https://w3c.github.io/wot-architecture/#toc
Kaz: biggest change is restructuring building block and servient architecture section into one.
Matsukura: we discussed servient architecture and deployment in Bundang.
Matthias: reminder that we discussed
in Lyon.
... It was forgotten.
Matthias is showing all the contribution in Github.
Matthias: technical requirements, I am not sure how to fit this.
Matthias is showing his comments list...
Matthias: termonology replacement
look good.
... new functional requirements is ok.
... technical requirements. I think it is a bit too early.
... I propose this to section 11.
... WoT architecture by Matsukura-san. media type, interaction
patterns, those are missing. I suggest to merge.
... WoT building block. we should explain what WoT deliverable
documnets are.
Matthias is going through his proposal points...
Kaz: is this slide available?
... can you copy URL, Matthias?
<kaz> @@@ Matthias' slides tbd
<mkovatsc> https://github.com/w3c/wot-architecture/blob/working/proposals/W3C_WoT-Arch_Princeton-2019.pptx
Lagally: sequence flow is missing.
Matthias: it will belong to
interaction model section.
... properties, actions will be described, and sequence diagram
will be described too.
Lagally is showing introduction session...
Lagally: Matsukura-san suggests to keep this, and also terminology section.
Matsukura: application domains.
currently we describe smart home, etc.
... description of combinations of IoT components follows.
... summary of use cases picture does not have detailed servient
architecture.
Matthias: high level picture is a
summary.
... cloud, gateway, device, etc.
Lagally: we can introduce property, action, events in introduction section.
Matthias: "process", "state", we should use those terms in introduction.
Koster: I agree.
... command-level details and block level descriptions are
different.
<mkovatsc> Working branch proposal: https://cdn.staticaly.com/gh/w3c/wot-architecture/working/index.html
<mlagally> https://htmlpreview.github.io/?https://github.com/w3c/wot-architecture/blob/working/index.html
<mkovatsc> http://w3c.github.io/wot/architecture/
<mkovatsc> points to new repo
Lagally: there is some old stuff in
WoT/architecture.
... Stale, non-maintained version.
Matthias: it came from IG.
... it was used for stating WG.
... IG Note never happened.
Kaz: we can explicitly mention in Readme.
Lagally: we can say it was a work of IG, and urge people to look at WG architecture.
Matthias: OK.
Kaz: we can update Readme.md.
... when we close a WG, we usually mention the closure of WG in
HTML. We can follow this way as well if we want.
Kawaguchi: Let's focus on document content today. we can discuss this in editor's call.
Lagally: OK
RESOLUTION: We'll fix the README.md at wot repo, and think about further clarification during the WoT Architecture call later
Lagally: functional requirements.
Matsukura: we need to make clear
functional requirements.
... I uploaded details in the document.
... component-level requirements.
Lagally: WoT servients architecture next
Matsukura: combination of application
and device.
... proxy is a common architecture entity.
... in addition to application and device.
... configuration of servient. application and device srevients
have common stuff.
... runtime is an abstract interface, and protocol binding provide
concrere binding.
... this slide is about basic abstract structure.
... device interface adapter provides abstraction.
... proxy servient's runtime has two roles; i.e. both client and
server.
Koster: "protocol binding". "protocol adaptation" may be better wording.
<inserted> Kaz: I'm not objecting, but if we changed the name of "Protocol binding" here to "Protocol adaption", that would imply we'd change the name of the building block as well
Koster: building block diagram, and this diagram. Style should look similar.
Lagally: why we can't say "Protocol Binding"?
Matsukura: some terms in building
block diagram are obsolete.
... the diagram I provided is functional structure.
Koster: OK.
Matsukura: WoT servient architecture
next.
... TD manager is about how to control runtime.
... servient generate exposed/consumed thing.
... who contrtols operation? It is TD manager.
Lagally: it should also include
lifecycle management.
... such as onboarding.
Matsukura: servient is inside application. application receives TD, and makes ConsumedThing. TD manager takes care of this.
Lagally: where is Life-cycle
management handled?
... we should consider to change terminology.
Koster: we can described all components first, then can talk about configuration...
Kaz: we need to described requirement
in architecture section.
... Matsukura-san described requirements in requirements
section.
... we need to link the two sections, architecture section and
requirements section.
Matsukura: Deployment scenarios
next
... simple deployment structures first.
... application control device in local network.
... and the second deployment is two WoT systems connected each
other.
Lagally: PlugFest architecture
Matsukura: yes
McCool: security section. we need
more general architecture security discussion.
... we can't fix broken devices, for example.
... I have not started this yet.
Lagally: When will you be able to do?
McCool: I will discuss with Elena next week.
Lagally: so we have two proposals, I summarized them.
Lagally is showing the two proposals...
Lagally is showing combined structure...
Lagally: we should have "application
scenarios" separate from use cases.
... abstraction of all use cases.
Koster: we do not have to contain too many similar use cases.
Matsuda: application scenarios and deployments pattern how are they different?
Lagally: high level description is
application scenarios.
... for owner of business, etc.
Matthias: we can describe application domain in use case section.
Lagally: we agree on intention
now.
... we can name "application domain" or similar.
RESOLUTION: OK with not having "application scenarios" as a top-level section but possibly having that as a subsection of "Use Cases"
Koster: interaction should be mentioned earlier.
<mkovatsc> Feels like nobody remembers this: https://cdn.staticaly.com/gh/w3c/wot/gh-pages/wot-ucr.html
Lagally is showing detailed consolidated structure...
McCool: On Friday, we will read
through after restructuring.
... short session on Friday, and another short session on
Saturday.
Matsukura-san, Koster, Matthias: OK
Kaz: Example interaction patterns and references are already available within the Appendix section. and your point for them is that we still need to update those appendix subsections..
Kawaguchi: interaction pattern should be made a bit abstract.
Lagally is showing open issues...
Lagally: use cases for a thing
directory, use case for semantic search are missing
... extension mechanism is not mentioned.
McCool: TD session next.
Sebastian: I need 5 minutes break.
McCool: 11:10am, we come back.
<kaz> (break)
<kaz> scribenick: kaz
(Ege is ok to take notes in pm1 for Lagally)
Kaz: before starting TD
discussion
... group photo right after the TD discussion
... also dinner proposals by the end of lunch
McCool: 2 hours for today
... and 2 more hours tomorrow
Matthias: can make it
Sebastian: Matthias' slides include some of
the TD portion
... Matthias, are you available in the afternoon EST?
... that's evening in Germany
Matthias: not really
Sebastian: in that case, let's start with
Matthias
... will show the slides for Matthias
@@@ Matthias' slides on TD tbd
Matthias: summary noticed
... [Terminology]
... InteractionPattern (#282)
... comes from a different discussion than the TD elements
... maybe "Affordance"?
... this current term itself doesn't make sense
... offer possible interactions
... related to the issue 282 here
Koster: I also use affordance
Matthias: capability vs affordance
... if this is kind of problem
... combined hypermedia calls?
Koster: would be good
... Google API use "trade"
... no one uses "affordance" so far
Sebastian: pattern term for serialization
Matthias: kind of weird
Lagally: not really sure if it's clear
enough
... "interaction" is clearer
... don't think "affordance" is the right term
Koster: "affordance" is used by the
design guys
... element for interaction
... it means interaction
... if you talk with design engineers, they know about this
Lagally: why not "interaction"?
Matthias: it's design pattern
McCool: just change the class of name
Taki: potential impact to the Architecture?
Sebastian: possibly
McCool: probably we should read through the document
Sebastian: in 2 months we're done...
Matthias: let's think about this until
tomorrow
... "InteractionPattern" is wrong anyway
Sebastian: may I ask you to create a new
issue for further discussion?
... in addition to 282
... maybe we should add another issue for this discussion
Matthias: there is some additional discussions there already
Sebastian: ok
Matthias: next on "Vocabulary term"
... doesn't have a value or type
... just a term
... but we use it to mean RDF properties or class members or
whatever we have now
... issue on the next slide
... logic broken after removing RDF/JSON-LD foundation
... people don't read the history
Ege: do you already have any issue about this?
Matthias: collected recently
Sebastian: Ege to create an issue
<scribe> ACTION: Ege to create an issue on "Vocabulary term"
<trackbot> Created ACTION-156 - Create an issue on "vocabulary term" [on Ege Korkan - due 2019-02-07].
Sebastian: related to the deletion of RDF/JSON-LD portion
Koster: just "term"?
... often used
Matthias: talked about this with vocabulary members
Sebastian: "element term"?
Matthias: there is a related issue on the
next slide
... and also "Assumptions"
... overused throughout the spec
... next slide please
... [Information Model and Default Values]
... connected with "Vocabulary term"
... removing JSON-LD portion caused impacts
... what is actually our information model
... no formal grounding given
... @context, @type not included in the information model
... come back to show what all the model shows
... property graph, etc.
Sebastian: make sense
Matthias: have to find a way to mention
what our information model is
... RDF/JSON-LD background
... label for property graph
Sebastian: specific keywords from JSON-LD there
Matthias: we defined equally defined members and elements
Koster: @type without semantic information?
Matthias: need to mention semantic
annotation
... property graphs related to property labels
(Manu joins)
Manu: joins
... can provide some background
... have some specific question
... generalized discussion or data model serialization
Sebastian: maybe we should provide some more
background from our side
... some issues here
... regarding the progress of JSON-LD 1.1
... complicated due to the difference of timeline
... want to look like JSON-LD but not refer to it
... still our RDF scenario/background
... so going for JSON-LD 1.0 serialization at the moment
... and making some additional stuff
... maybe TD 1.1 would be synchronized with JSON-LD 1.1 later
Manu: we have same problem with VC data
model
... target is making sure people use only JSON-LD
... but difficulty with interoperability
... had to do refer to JSON-LD 1.0
... and make some restriction on JSON expression
... so that no changes would be required for 1.1 adaption
... for JSON processors, you have to ensure the context are
provided some specific order
... we added some language for that purpose
... your JSON-LD processor must use something additional
... the spec can be normative in a right way
... does that approach helps?
Matthias: yes
... sounds quite similar
... exactly same
... more details on our issues?
... something if you could provide that "special language", that
would be helpful
Manu: we have exact same problem
... we implement very soon
... the WoT context should come first
... the JSON-LD processor would throw error
... let me try to find the text
... same problem to be solved in the same way
Matthias: tx!
Manu: if you have issues with @context,
@type
... we also had same issues several months ago
<manu> https://w3c.github.io/vc-data-model/#semantic-interoperability
Manu: 7.1.1 Semantic Interoperability from the VC data model draft
<mjkoster> here is the github issue discussion:
<mjkoster> https://github.com/w3c/json-ld-syntax/issues/20
Sebastian: cool
Manu: other question I had
... alias for @type?
... you can do this in the context
<manu> In the context, you can do this -- "@id": "id"
<manu> In the context, you can do this -- "@type": "type"
Manu: you can do the above
... the question is context information has alias or not
Matthias: for @type, basically people didn't want to introduce this complexity
Manu: can understand the
motivation
... we had this discussion #20
... try to do is handling JSON version and JSON-LD version
<mjkoster> we wanted to keep the semantic annotation separate from the JSON type in the file
Manu: has anyone say they want to add objects that have no mapping?
Sebastian: should not the case
Manu: ok
Matthias: if you include other
context
... you always have to maintain @type
... for semantic meanings
... the other part people just add their own types
... saw a lot of examples
... intend to do in the beginning
Manu: ok
... safely added to the context though not clean
... as the result
@@@ TD 6.3
Matthias: core vocabulary for TD
Manu: do you have a @vocab for mapping to some vocabulary?
Sebastian: no
... our idea is that @context is missing
... before processing JSON-LD, all the necessary information is
added
Manu: ok
... the question of mine
... TD has @vocab or not
Matthias: if you could have a pointer, we
could look into that
... you have to know about the additional vocabulary anyway
... must be context
Manu: make sense to me
... valid mapping
... people can use their own proprietary vocabulary
... only remaining question about @type
... any other questions around?
Kaz: would like to continue this collaborative discussion
manu: ok
... my question is generating a generalized data model?
... or serialized as JSON, CBOR, etc.?
... we've been doing serialization-agnostic approach
Kaz: quite similar policy :)
Manu: just wondering about test suite
now
... anything else?
Matthias: some "central model" you mentioned?
Sebastian: do you want to show your slides,
Matthias?
... would return to the slides
McCool: can continue the discussion by
20m
... and 90m for lunch
Matthias: sounds good
... (going back to his slides)
... [Information Model and Default Values]
... moved to the serializaton
... why it's there now?
... may be CBOR
... if there is information missing, should add that
Sebastian: people are confused with our
mandatory terms
... give there explanations
... if you want to follow the default valuses...
McCool: any serializations
Sebastian: e.g., CBOR
McCool: clarify mandatory vs
optional
... still mandatory but could have default value
Ege: optional/mandatory/default?
Sebastian: also have some slides on that point
McCool: we should keep default
values
... to avoid confusion
Sebastian: still mandatory for serialization
McCool: information model is
mandatory
... clearly identify what shouldn't change
... possibly have 2 separate tables?
<Zakim> manu, you wanted to note that this is a canonicalization problem, agree w/ putting it in information model, but problem comes in testing interop at the syntax layer.
Manu: in general +1 to moving it to
information model
... if you make that decision, this is a canonicalization
problem
... how to do that?
... needed to work on that problem
... JSON model to JSON-LD
... canonical syntax vs everything
... how the information canonicalize?
... data set normalization
... what is in the information model?
... fine to specify how to express it
... the number is expressed, for example
... and now we want to express digital signature, etc.
... can do it on the data model
... and different seriailzations
... there are 3 things to do
... values in the information model
... and different serializations would express that in different
ways
... really think about canonicalization
McCool: regarding the issue on
testing
... convenient to have canonicalized version
... standardized converter
... that's more media problem
Manu: that's reasonable
... forced to pack syntax
... one way is take the data and syntax converted on te end
point
<sebastian> sorry
Manu: canonicalization mechanism
... JSON-based or CBOR-based
... and canonicalization in the spec
... ok to use the canonicalization
McCool: practical pov
... we're out of time to deal with that
... also switching to a different approach
... how to finish our test work
... have a standardized canonicalizer
... then we can use that for testing
... single assertion can specify what to test
... but we're going for manual way
Matthias: valid to have a tool for
canonical form
... quite easy way to solve the issue
... default value must move back to the information model
... mandatory/not mandatory/default would be good
... we're using XML Schema for data modeling
Sebastian: maybe we should show an example
@@@ TD thing level, property (6.2.3)
scribe: to show you concrete example
(ex. 7)
... this is actually map of property
Manu: afaik, not possible
Sebastian: 6.2.1 Thing
... we use XML Schema for any types
... e.g., "string"
... Property is actually a map for Property
Matthias: technically here is the type of
array
... object notation to list
McCool: syntactically they're map
Matthias: maybe we can find map's
McCool: +1
Ege: from JSON Schema pov
McCool: only question
... implementations how to render them
<manu> Are you using -- https://w3c.github.io/json-ld-syntax/#node-identifier-indexing
Manu: are you using the above?
... JSON-LD WG may have some idea
McCool: we should go ahead and implement that
Matthias: cardinality here
McCool: syntactically not arrays
... but objects
Matthias: what our information model is like?
McCool: we're end of our time for morning
Matthias: let's go through the last
slide
... [Serialization]
... there is no "JSON integer"
... serialization should be consistent
... unsignedInt must be serialized as JSON integer
... what about signed, or what about all others not listed?
... took out of the serialization section
... we have rule only for unsigned into
McCool: unsigned is wrong
... have to be numbers
... example is not normative, though
Lagally: problem with the table?
McCool: double type is also strange
Matthias: if you go 6.1, unsignedInt and double mentioned
Sebastian: got it
McCool: bug fix?
... may cause additional assertions
... should add some description on our using xsd type
Matthias: next
... some editorial thing
... names input and output rely on
... and the last point
... artificial constraint
... break the tool by @type
... string directly or array of strings?
Sebastian: can be both
McCool: the argument is inconsistent
Sebastian: "the @type MUST be serialized as JSON String or as JSON array of strings"
McCool: 2 questions
... must be serialized as array
Sebastian: why we should not simply use
array?
... have to check the issue, though
McCool: maybe could not force people,
though
... can we be flexible or strict?
... being flexible may cause problems
Sebastian: 5.3.2 ArraySchema
@@@
Sebastian: array or object?
Matthias: explains the behavior of array vs
object
... shouldn't have artificial constraints
Manu: maybe mis-communicating...
Sebastian: item term here (5.3.2)
... trying to assign 2 data
Manu: something from JSON Schema?
McCool: we could have canonicalized
version
... single or array
Matthias: we need one of the RDF experts
Manu: it can't have 2 different things at once
Matthias: we need to be consistent
Sebastian: we should have string and array of string for "op"?
McCool: time check
... 9mins for lunch
... Zoltan, scripting for 1:30pm
zk: fine
McCool: will update the f2f agenda
Ege: have generated an issue for this point
Matthias: there are 4 issues
<ege> https://github.com/w3c/wot-thing-description/issues
McCool: will update the agenda for
Fri/Sat as well
... take a look and give comments
(Manu leaves)
[lunch]
<inserted> scribenick: ege
Zoltan: here is the agenda
... in last f2f, we discussed we might need alignment with web
platform
various topics like webidl, use it?
scribe: not using observables
... it is not implementable for browsers
... we wanted to see how scripting api is understood in the group
and did the questionnaire
... only 7 out of 20 people responded
McCool: did you mean browser only or browser+nodejs
Zoltan: not many are interested in
browser implementations
... generally we implement for browsers, not the other way
around
... polyfill would be enough
... having it in browser is a long and hard process
... we need one way to provision things, like adaptation interop
testing
... does michael koster or matthias have comments on it
Matthias: like you said there is a choice
of not needing a browser implementation
... I answered from my needs
Zoltan: do you have any comments on this
danielp: the poll represents what we
have seen from previous calls
... there are not enough respondants
... so there is interest but the interest is very small
Zoltan: (presents issue 158)
... I have did this to make scripting API more browser
compatible
... we will not go for a REC track, only a note
... if it is only a note, do we go for typescript or webidl
... I will show a gist about the proposal
... any comments
Daniel: no interest from
browser
... what we have seems to work
... it worked well in testfest with node-wot
... we made step towards browser API but we wait for interest from
them to go further
Zoltan: there these two options,
slide 5
... option one, with fetch api. also change to typescript
... skipping slide 6. presents TAG tips to make scripting api more
browser friendly
... we can explain how to create a js object from td
... slide 8. we see thing property, it implements observable
... in browser friendly api, we see onchange instead of
observable
Kaz: I have comment regarding the discussion with philippe but can wait until you finish these slides
Daniel: to clarify, we just attach
handlers at the moment, like described in TD. then you can get a TD
by serializing.
... for browser you would need an algorithm to write a td like you
do for read a td
Zoltan: right I don't even have that
method here.
... there is an indirection here
... now ThingAction, it is similar. I need to update the
comment
... now events, we have overused includes
... if you want to sub to an event, you just add an event listener
... now we come to consume and expose thing
... consumed thing inherits from thingfragment
... we also use observables for detecting TD changes
... browser doesn't use observable
... that is also more similar to browser implementations
... now exposed thing, small font but similar principles
... exposed thing extends consumed thing
... it has emit event, expose and destroy. we don't need getter
setter since we inherit them from consumedThing
... the handlers are the same as before
... so only emitEvent has changed but not much
... now discovery
... discovery: has discover method and also has subscribe with
three handlers
... browser friendly, now we just build js object
... we can attach event handlers and call start and stop
... now wot object
... in browser discovery is by constructing a discover()
object
... it has fetchThingDescription instead of just fetch to avoid
semantic overlap with the fetch api
... register and unregister for directory
... now back to slide 5
... daniel do you an opinion
... I don't have a strong opinion
... both are sensible since getting close to browser but not close
enough is not worth
note from scribe: the previous two belong to daniel
McCool: I would go for an option 1.a to
show that we are inclined for browser compatability
... we can vote now to see how it can look and then continue with
email
[Voting: 5 for option 1 and 3-4 for option 2]
Matthias: I need more information to make a sound decision
Ege: agree on mk
McCool: it seems that this is a general
problem
... what would you need
Matthias: examples?
Zoltan: browser compatible means it
looks more like browser apis so more developers can
understand
... it would be also consistent with node.js developers
... node is more liberal in event handling
... we need more work on asking more people
Ege: do you have cases (non-wot) that have a browser a non browser version?
Zoltan: we can do that
McCool: there is generic sensor api that has this case that responds to ege's question
Zoltan: we won't go for a rec, it
will be a defacto api
... *** was ok for polyfill
Matthias: I am not sure if I understand
with what me mean by provisining
... what does provisioning add
Zoltan: it brings discovery
Matthias: why not call it discovery then?
Ege: students ask for tutorial
McCool: this is more of a marketing outreach problem
Zoltan: will there be an online device that people can use ?
no comments
Ege: but a tutorial is not an example, it starts small and builds up
McCool: it is more of a tutorial
... sorry more a workflow
Zoltan: this should be a task for the
architecture
... but happy to contribute
McCool: one would land at the landing page and then read the architecture and then the tutorial
Kaz: discussion with philipp
Zoltan: if we move away from webidl
we change a lot
... then it becomes a documentation for node-wot
Kaz: i wanted to invite them to the discussion but I couldn't
McCool: if it is a browser api we can leverage from the test suite they have
Zoltan: thank you, we can finish scripting pai
Kaz: we can include you to the email thread
Zoltan: please include daniel as well
<kaz> ACTION: kaz to include Zoltan and Daniel into the discussion thread with PLH and Yves
<trackbot> Created ACTION-157 - Include zoltan and daniel into the discussion thread with plh and yves [on Kazuyuki Ashimura - due 2019-02-07].
---- binding templates
<inserted> @@@ "mk:" within this section to be converted to "mjk:"
Koster: we stopped working on the binding
templates once we fixed the vocabulary
... the goal is to release it as a note
... it was released sync with prague td
... the current format of the document is appopriate
... it explains how they work
... there is some architecture that shouldn't be in this
document
... like having a security layer in between and so on
... so we should keep it simple
... enumeration of all the protocols we support
... what each term does
... it teaches a developer how to use protocol bindings but not to
create new protocols
Sebastian: I tried explaining protocol
bindings in the td documents
... I have said that you can find this form term in the protocol
bindings document
... we should check for consistencyt
... for example you should do a get request
... I say: please follow the guideline found in the protocol
binding document
... what is missing is ontology representation of http, coap, mqtt
terms
... that's why I removed them from the spec
... e.g. I didn't use the retain flag since there is no ontology
which defines that
... in mqtt you dont know the broker and topic from the href
... we should also do the media type registration in IANA
application/td-json or something like that
Koster: many can do that
... it is more for TD
... someone from eclipse foundation maybe? they use mqtt a lot
Sebastian: the default assumptions should be
also in the protocol binding
... since we are a standard and protocol bindings are not how do we
reference it
Koster: do you do make reference to sections
Sebastian: no just to the documenbt
Koster: I list the vocabularies but they
should be separete documents
... these documents can be used outside of WoT as well
... no one says that they should be published soon
... we should at least have an internet draft for mqtt scheme
McCool: could be based on real
devices
... we should test that before we put it
... so we should be testing more examples
... put it in an appendix maybe
... see the part that is relevant and then you can read the whole
thing
... maybe you can do expanders like in TD
... a way to hide
... at least node-wot needs to be able to speak with an OCF
device
Koster: but there is no reference OCF
Sebastian: we need clarification on how json document would look like
Koster: it is still not there
... now matthias is there
McCool: implementing how the payload looks like
Koster: maybe it can be only in node-wot
Sebastian: this was also a request from mozilla
McCool: is mozilla an implementation?
Koster: there is some new vocab like cancellation
Sebastian: we lack a good example for
events
... there is someone from, I think, ietf who wants to see how
events would be used
Koster: now there is a new thing called
websub
... from w3c
... if we will use webhooks, we should work with websub
... kaz do you know that
Kaz: no but I can check
Koster: there are multiple ways to use http to do async
Sebastian: we have subprotocol term but there is only one value supported, longpoll
Koster: that is why there is websub
McCool: we should reserve the word for now
<kaz> fyi, WebSub is now a W3C REC
Koster: what about extension points in
the vocabulary
... we don't have the idea of an extension point
McCool: how to make sure that people don't overwrite them
Ege: what do you mean by overwrite
McCool: we don't say that anywhere, meaning that something we already defined shouldn't be redefined
Kaz: websub is already a standard
Koster: that is easier then, we can implement
McCool: in two weeks please, :D
Koster: @@@ as I put above, WebSub is a webhooks from w3c
McCool: websockets from mozilla
Koster: we haven't figured out how to use websockets to make events
McCool: these strings are reserved
... there is a mozilla standard on how to handle eventing in
websockets
Koster: fujitsu implemented websocket handling?
matsukura: yes
Koster: then we can use that
... there is nothing that is competing that I know of
McCool: we put what is already out
there
... and then say that it is possible for user extensions since
there are a lot of experimental stuff out there
Koster: is there anything about eventing that is missing overall?
McCool: a binding for opc/ua
Koster: does anyone have an implementation for it?
McCool: in the long it would be nice for it
Koster: just the idea of having xml in protocol bindings would be nice
Sebastian: there were some previous work by taki on how to map json schema to xml schema
Koster: so that would be nice
McCool: CORE shows up in the book by
guinard
... we should have a generic http example
... there is some overlap between security metadata and
forms/protocol bindings
Koster: is there security meatadata in forms
McCool: yes
Sebastian: in the coming sessions, in the TD
spec it would be good to show different cases of TDs
... a rich example set
Lagally: we should mention opc/ua in the
architecture document
... in addition to zigbee zwave etc.
Sebastian: we should have a rich set
McCool: but that would be putting
something that we didn't tested
... maybe we can put in examples
Sebastian: maybe we can have a document about only examples
<inserted> kaz: wonders if Sebastian's mentioned "example document" is related to the "TD Best Practices document" proposed by Victor and Maxime. think the concept is different from that, though
McCool: that would go well with the
tutorial
... adding more protocols for longpoll
Koster: sure I will create an issue for
adding more to longpoll
... it is a more discussion issue right?
McCool: yeah
Koster: I don't know if we have more to discuss and to create issues
McCool: opc ua is a long term
requirement
... eventually we should try to get that
<Zakim> kaz, you wanted to ask sebastian for clarification on media type registration
Kaz: something to say about the iana registration
<kaz> media type registration procedure
Kaz: W3C is taking care of that
... registration form can be put in the td spec
... and we'll send an application email to IANA
McCool: also what about .td format
<kaz> like HTML 5.2
Sebastian: there is also one in coap, in content-format
Matthias: oh yes we can do that
... 65100 is the experimental range value
Sebastian: without this and without @context there is no way to identify a td
McCool: will we talk about cbor serialization?
Sebastian: not in this charter
Matthias: there is no advantage on doing batch registration
McCool: i worry that someone can steal
the name
... we can register so save the name but not specify how it should
be done
... standard encoding of cbor in json
coffee break
<kaz> scribenick: mjkoster
<kaz> @@@ Sebastian's slides tbd
McCool: we need to be able to check all terms
McCool: on previous topic, can we
agree to optional, mandatory, default
... propose a separate section about how to canonicalize
... defaults may be serialization-dependent
... like content type
... but we can e.g. say JSON is the default
... ege: it is difficult to extract defaults from the
specification
... we will add extra information into the document
... forward reference to the section where defaults are
defined
... like a star with a reference
... if we canonicalize the file, we can express these defaults and
other things like string vs. array
... we can also write tests against the canonical version to make
assertions easier
... validators have a way to add defaults
... the canonicalizer would be a required processing step for
TDs
The spec would have a special section to explain the non-canonical formatting options but in general use the canonical version for assertion extraction
Taki: does default always imply mandatory?
McCool: we should create a concrete proposal to evaluate tomorrow
UNKNOWN_SPEAKER: seems to be OK
McCool: the server can always refuse and offer it's choices
Koster: you can't always get what you want
McCool: then the server can simplify responses
Toru: the negotiation uses only the title field?
Sebastian: yes
discussion of issue #161 on language negotiation and issue #359 about singular and plural terms which refers to #161 terms
<inserted> [kaz points out that issue 359's title is confusing if the main point is language negotiation]
McCool: this is security scope which
associates an interaction with a security scheme
... could remove it at the interaction level and put into a
form
... for e.g. oauth and bearer token schemes
... this is issue 355
McCool: we need more examples
<kaz> Siemens example on periodic events
Sebastian: shows example of the 3-schema pattern for events
McCool: concern that this is
different from how actions work
... there is no response schema from the subscribe operation
Koster: we need to try these against some subprotocols
McCool: what about longpoll?
discussion about subprotocols and how this pattern will fit
Sebastian: what is the outcome?
McCool: create an issue to add a
response to the subscription operation
... for each subprotocol, build examples to validate the pattern
and explain how to use
... make sequence diagrams
Sebastian: the seq. diagrams should go into the binding template document
Koster: need to support both of these and also contains
Ege: make an issue for contains
... what about adding "not"
Koster: "not" may not be useful for the use case of a client breaking items out of a packet but might be good for validation cases
McCool: let's add only what we know we need
<kaz> security test plan
McCool: the security testing plan is
in the charter
... it is ambiguous how to test a standard as opposed to an
implementation
<kaz> rendered version
McCool: so we will be testing implementations based on a framework
<kaz> Charter
McCool: to collect evidence that the
standard support security
... and ensure that conforming implementations are tested
... functional test and adversarial test
... we wanted to enable different tools to be usable and not
require any one particular tool
<kaz> toc
McCool: functional testing verifies
that the server conforms to it's own TD
... e.g with proper authentication access is allowed, with improper
auth, the access is denied
Lagally: what about things with known vulnerabilities?
McCool: these can't be passed as
secure
... functional test would pass but pentest would fail
... adversarial testing simulates an attack
... we can use web service attacks but IoT devices may have new
vulnerabilities, e.g. physical attacks
... we will only consider network based attacks and attacks in the
operational state
... the stages are information gathering, discover vulnerabilities,
try to exploit vulnerabilities
... the focus is on vuln. discovery
... static code analysis, can be done with source code or
binaries
... dynamic analysis is more black box testing over the
interface
... we have both network interfaces and scripting API
... fuzz testing tries to generate side effects to erroneous input
to trigger vulns.
... it may create a huge array, or pass corner case values, numbers
instead of strings, etc.
... e,g, trigger buffer overflows, etc
... tools for CoAP, HTTP, but not found for MQTT
... also over-the-air/wire protocol analysis can be done to find
evidence of vulns.
... requires isolated networks due to network traffic
generated
... there are tools that try to attack based on known
vulnerabilities
... our framework will do static, dynamic tests and analyze the
results
Kaz: we should have 2 or more passing implementations
McCool: we can start with node-wot and decide another implementation
Ege: there was a comment from an AC
rep and another that they need to capture the test steps and show a
test result in a formal fashion
... they use a well known language
Lagally: how are we going to implement the test plan? Will there be certification?
McCool: W3C doesn't certify things so it is the manufacturer's responsibility to run the tests
Lagally: how would we then make a recommendation for a particular device?
McCool: there will be published test results
Lagally: then it's
self-certification
... we don't make any recommendations
McCool: we could sponsor hackathons
to facilitate the testing
... we can run some tests against node-wot and the OCF bridge as a
demonstration of two implementations
McCool: the coverage is pretty good but many assertions are still untested
Ege: we need to cover the untested items before we can publish the CR
McCool: these could be easy to cover
but someone needs to implement the missing assertions in a TD
... please focus on filling in the gaps and the manual
assertions
Sebastian: can we review these gaps before tomorrow ?
McCool: created a "checked" directory
where each org will create a subdirectory wcontaining ".impl" files
for correction of the bad assertions
... add a column to the csv file to add a correction note for each
bad assertion
... there is an example created in the checked directory
... tomorrow we can go over the list and assign people to add
missing features to their TDs
... 20 minutes tomorrow to discuss additional security and
validation issues
... everyone please go through your results and create the checked
file entries within the next week
Kaz: we can prioritize the failure cases
Ege: we still need to cover false
failures, unimplemented features, and manual assertions
... make a results-checked directory to copy results into
... look at the files and correct not implemented errors
Lagally: to do a good job this needs to be a very thorough line by line assertion check of all the files
McCool: will send out an email with
instructions
... will try to schedule a mini-workshop for this tomorrow
... just go through the results and look for the incorrect
assertions
... adjourned
<kaz> remote+ Matthias_Kovatsch, Daniel_Peintner
<inserted> scribenick: kaz
Lagally: summarizes the results
TestFest summary by Lagally
People's interested industry areas
Lagally: we should get prepared for the demo during the upcoming workshop based on the results
McCool: two main messages to convey: input for use cases and proof of interoperability
Lagally: stories: home, industrial, ...
McCool: matrix of application scenarios
Lagally: checks people's interest on home
scenario and industrial scenario
... using the matrix on the whiteboard
McCool: need to think about more attractive demo scenarios
Lagally: adds smart cities, buildings
McCool: remote things are nice but would be even more attractive to bring actual devices to the venue
Lagally: let's continue to think about
it
... what about agriculture?
matsu: part of industry
Sebastian: this is a wish list and I think
we should think about something realistic as well
... also we should think about people to invite
Kaz: would suggest we put a note
about "who to invite to the workshop" and "which topics to be
handled during the workshop" at the bottom of the whiteboard
... rather than starting discussion about that now
McCool: +1
Lagally: puts a note
... and continues to check people's interest in possible future
scenarios on smart cities and buildings
... Intel
... Oracle
... Fujitsu
... Siemens
... Panasonic: maybe difficult at the moment
... Hitachi: would also concentrate on industrial scenario
McCool: 2 issues: orchestration for multiple vendors, and concrete products
Koster: orchestration for conference room, etc.?
McCool: interested in Huawei's opinion as well
Lagally: asks Matthias about his opinion
Matthias: can't tell the detail at the
moment
... but some work on oneM2M inter-connection
Kaz: thinks it might be easier for people here to express their interested technology points like orchestration and bridging in addition to those 4 categories (home, industrial, smart cities, buildings)
zk: some collaborative work on smart building with a university
Lagally: asks people about their interest in bridging with other SDOs
Sebastian: we should think about not only
quantity but also quality
... also want to think about automotive industry as well
... mentions possible stakeholders to be involved
... BMW, VW, Mozilla, Everythng
... also would like to invite Automotive WG guys
Lagally: adds notes on those points to the
whiteboard
... and continues to check people's interest in bridging
... and then wrap up the discussion
Ege: Testing Procedure
... [Current Testing Procedure]
... 1. implementation owner pushes TDs to "inputs" directory
... [Very Soon Future]
... need to see what is NOT implemented
... reverse direction: implementation report => results =>
imputs
... need correction
... got feedback from Panasonic
... [Testing Procedure]
... need feedback since this procedure will be applied remotely
from later on
McCool: any feedback about the procedure itself?
Koster: tool itself seems easy to
use
... we don't need to think about that
... but the tool is still buggy...
McCool: we don't have dynamic interface
check yet
... just static syntax check now
... [My Feedback]
... the testing tools are automated but not in the lop of
everyone's development cycle
... no one provided the manual assertions, so 20+ assertions are
not marked even as "not implemented"
... github is not well suited for this fast paced changes when
submitting TDs, results and report during the TestFest
... since someone needs to merge and pull the changes
... GitHub itself is version control system rather than data
store
... there are many versions there too
Kaz: thinks we can simply use vendor-specific repositories to manage the data with appropriate permission
(or simply create an additional "wot-testfest-results" kind of repo and give write permission to all the TestFest participants)
Ege: TestFest results
McCool: shows the latest results
... the pink areas here shows features at risk
McCool: goes through the "Results"
column
... pink means less implementation than 2
... yellow means 0
Ege: [Feedback from implementation
owners]
... feedback from SmartThings and Panasonic
McCool: tool is useful but we need to check the results manually
Ege: [Non tested assertions]
... Some assertions (27) CANNOT be tested automatically. Thus,
we
need manual input from implementation owners.
Ege: [Non tested assertions
(Examples)]
... Td-serializiation-default-values: For JSON-based Thing
Description
... serialization, if values are not given for certain mandatory
fields, default values
... MUST be assumed.
... Td-form-protocolbindings: Syntax
... If required, forms MAY be supplemented
... with protocol-specific vocabulary terms identified with a
prefix.
... And more related to behavior
... [Parent and Child Assertions - Discussion]
... how to handle a parent implementation if a child assertion
about a non mandatory term is not implemented?
... Example:
... Td-action-names: Each optional vocabulary term as defined in
the class Action and its superclass
... InteractionPattern MUST be serialized as a JSON name within an
Action object.
Lagally: would like to check the purpose of testing effort again
Kaz: points out that there are 2
separate issues here
... check assertions to display implementation experience
... and tooling for that purpose
... but we don't have to generate a smart automatic tool if there
is difficulty with that
... we can simply check the assertions manually if needed
McCool: the problem with manual assertion check is that TD spec is still changing and we need to check the assertions frequently
Kaz: in that case, we should fix the spec right away given the timeline
Ege: [At Risk Assertions]
Ege: the above list still includes "not tested" ones
McCool: would like to walk through the report
Kaz: repeats his point@@@
McCool: so let's go back to the
report.html and see the actual status
... starts with "client-data-schema"
... basically what we need is...
... top 3 are client behavior
... bottom 3 are server behavior
... we need 2 more server implementations and 1 more client
implementation based on the results
... I can do the server part
... Koster, what about you?
Koster: can also do it
McCool: asks people about the assignment
for manual check based on their implementation status
... regarding "td-action-arrays forms" and the following 2
assertions, maybe we can remove them given they're not implemented
and we can have them at the top level
... continue to see volunteer checkers
@@@ McCool's check list tbd
[break till 12:15]
Lagally: give summary from the discussion
yesterday
... and shows the updated draft (using Staticaly)
<mlagally> https://cdn.staticaly.com/gh/w3c/wot-architecture/restructure/index.html#introduction
Lagally: Abstract here
McCool: structure to be straighten out
Sebastian: security missing as a building block?
McCool: maybe as "cross-cutting security" rather than one of the building block?
Sebastian: will create an issue for wot-architecture for further discussion
<scribe> ACTION: sebastian to create an issue on how to handle security (building block or not) within the architecture spec
<trackbot> 'sebastian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., sha, skbisch).
Matthias: we shouldn't discuss the details
now
... there are many topics here
McCool: right
... some of them are related to each other
Lagally: Introduction
Matthias: did a review for the updated draft
Lagally: first we need to agree on the
structure
... that's my plan
Matthias: ok, just wanted to make it sure
Lagally: toc here
... 3. Use Cases
... including Application domains and scenarios
... based on Oracle's input
... then two requirements sections
... functional requirements and technical requirments
... then WoT Servient architecture by Matsukura-san
... how to rework it?
... and then
... Deployment scenarios by Matsukura-san
McCool: having two similar sections is
strange
... for Security and Privacy
... would like to merge 10 and 11
Lagally: ok. let's remove section 10
then
... we should now look into the use case section
... 3. Use Cases
https://cdn.staticaly.com/gh/w3c/wot-architecture/restructure/index.html#sec-use-cases
scribe: there are too many sub titles
McCool: please scroll them a bit?
Lagally: do so
McCool: may be "Oil and Gas" as
"energy"?
... energy as the top level which includes oil and gas?
Lagally: goes through the list
... connected car, agriculture, healthcare, smart cities, ...
... and then high-level topic like Environment Monitoring
Koster: maybe one big table to list the top topics?
Lagally: ok
... 3.2 Use Case Patterns
https://cdn.staticaly.com/gh/w3c/wot-architecture/restructure/index.html#commonusecasespatterns
Lagally: no changes here
Koster: what does the gray fringe line mean?
McCool: fig. 2 has two gray boxes
... maybe security boundary?
https://cdn.staticaly.com/gh/w3c/wot-architecture/restructure/images/smart-home-t2t.png
McCool: let's kill the house from the figures
<scribe> ACTION: lagally to remove gray box of home
<trackbot> Created ACTION-158 - Remove gray box of home [on Michael Lagally - due 2019-02-08].
Lagally: how to handle security boundary like fig. 3?
https://cdn.staticaly.com/gh/w3c/wot-architecture/restructure/images/smart-home-multi.png
Ege: here the gray box means different kind of network?
Koster: conceptual diagram or network details?
Matthias: these figures are for use case description
McCool: reasonable to say this is for use
cases
... text here says the gateway manages electronic appliances inside
house.
Lagally: Cloud-ready Devices
... how to explain Cloud Proxies, etc?
McCool: would move the section and
describe different kind of proxies
... logically gateway settings should be sub sections of proxy
Lagally: Legacy Devices
... we need something here
... then Smart Factory
... should mention BACnet, etc.?
McCool: should mention more than one
protocols
... diagram is fine
... but should use different color to describe different
standards
... if include OPC-UA, should say oneM2M OPC-UA
Lagally: this is more or less bridging setting
Matthias: we should show different standards
McCool: would suggest we use different
color to identify them
... industrial circumstances
Matthias: common use cases with different technologies
McCool: could put very similar pictures
including different technologies
... monitoring smart building and others
Lagally: would be great to have some concrete figures and text
Sebastian: can volunteer
<scribe> ACTION: sebastian to generate updated figures and text for smart factory
<trackbot> 'sebastian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., sha, skbisch).
McCool: managing many devices using
common infrastructure
... that's the pattern applied to smart factory here
... let's call the common mechanism "institution management"
... which doesn't apply to smart home
Lagally: ok
... next Connected Car
McCool: car is just an example of interaction by multiple subsystems
Ege: robot is another example
McCool: users don't see the internal complexity
Lagally: maybe "Mobile Embedded System" as the main category?
McCool: fine
Lagally: then Cross-domain Collaboration
McCool: point-to-point interaction and cloud-based interaction
Koster: are those par of "Use Case
Patterns"?
... they're rather use cases themselves
McCool: remote access is one use
case
... and collaboration is another
... and interaction
tou: fine with moving cross-domain collaboration to Use Case Pattern
McCool: additional use cases on mobile users
<scribe> ACTION: mccool to generate additional use cases on mobile users
<trackbot> Created ACTION-159 - Generate additional use cases on mobile users [on Michael McCool - due 2019-02-08].
Lagally: goes to Requirements
... Common Princeples
... flexibility and compatibility
... and then unchanged sections
... Functional Requirements
... make sense to split "Functional Requirements" and "Technical
Requirements"
Matthias: not sure about "Technical
Requirements"
... maybe non-functional requirements?
Lagally: let's go to WoT Building
Blocks
... no change here
McCool: maybe we can add "cross cutting
building block"?
... e.g., for security?
... maybe should mention security briefly at the beginning of
section 5
Lagally: could you generate concrete text?
McCool: will do
<scribe> ACTION: mccool to generate text on security at the beginning of section 5 building blocks
<trackbot> Created ACTION-160 - Generate text on security at the beginning of section 5 building blocks [on Michael McCool - due 2019-02-08].
Matthias: maybe you could do high-level review?
Lagally: ok
... we're reviewing this within 15 more mins
... 6. WoT Servient architecture
... please review this section in detail
... within section 9, there are several missing text marked as
"t.b.d."
... would like to look into Matthias' PR as well
<mkovatsc> mkovatsc.github.io/wot-architecture/
Matthias: have a link for the rendered
version
... basically fixing issues which we've already discussed
... did some renaming as well
... focus on OCF and more than just smart home
... also renamed common patterns
... what the use cases are here
... different locations from different networks
... put summary here (3.3)
http://www.kovatsch.net/wot-architecture/#summary
Matthias: diagram from Matsukura-san's
slides
... so far, so good?
Lagally: think so
... any other comments?
McCool: this is a better starting point
Matthias: thenrequirements
Lagally: would suggest we all review the proposals
Matthias: content-wise, there is no
difference
... now we should review the content and get comments
... 5.2 Architectural Constraints
... started overview about the architecture first
... and detailed description by each subsection
... uniform interface, interaction model, ...
Lagally: you're planning to provide some text?
Matthias: yes
... also normative assertions as well
Lagally: great
... how to handle digital twin within figure 11?
... maybe not using this fig. 11 itself, though
... can do that
<scribe> ACTION: lagally to generate some text on digital twin idea around 5.1 overview
<trackbot> Created ACTION-161 - Generate some text on digital twin idea around 5.1 overview [on Michael Lagally - due 2019-02-08].
Matthias: fundamental things like how the
TD was designed
... can be referenced by the TD document
... much overlap about 5.3 Building Blocks
... 5.3.3 is important to explain what the binding means
Lagally: wondering if "5.3.1 Web Thing" is
one of the building blocks
... maybe belong to interaction model?
... we don't have "Web Thing"
Matthias: let's put it up there
... would help from somebody from semantic web
... under "5.4 Servient Implementation"
... servient architecture
... effects one of the building blocks, Scripting API
Lagally: we currently have two sections
for Scripting API
... 5.3.4 vs 5.4.1.2
... Scripting is optional but still one of the building blocks
Matthias: question about "6. WoT Servient
Implementation"
... text here to be moved to deployment?
Matsukura: servient architecture
... this section is very familiar with the requirements
... describes conceptual architecture
Lagally: how to rename it as "servient inter-working"?
Matthias: or could be simply the existing
"WoT Deployment"?
... make sense to describe different roles of servients there
Lagally: would it make sense to use Matsukura-san's diagram instead of fig. 14?
http://www.kovatsch.net/wot-architecture/images/architecture-implementation.png
Matthias: which figure by Matsukura-san?
Matsukura: Futjitsu don't use Scripting API but use another kind of scripting mechanism
Lagally: can we use fig. 19 instead of fig. 14?
Matthias: can't make decision yet
http://www.kovatsch.net/wot-architecture/images/arch-simple-conf-wot-servient.png
Matthias: question about section 6
... high-level architecutre, servient architecture to be moved to
deployment
... refinement with servient internal design (fig 19) to be moved
to section 5
http://www.kovatsch.net/wot-architecture/images/arch-simple-conf-wot-servient.png
Matthias: and SNIPPETS: (was WoT Deployment
Scenarios and Guidelines)
... if there is something useful take it
... otherwise should remove this section
... because there is overlap with Matsukura-san's content
... how to deal with editors list?
... Kajimoto-san is not active any more, and Toru-san to be
added?
Taki: will check with
Kajimoto-san
... myself to be added, though
Matthias: will generate another PR and you can merge it
Lagally: ok
McCool: to be added under "Marketing and Outreach"
[lunch till 2pm]
<jeff> Hi, everyone.
<jeff> What are the coordinates?
<inserted> scribenick: mjkoster
Kaz: Introduces workshop web
page
... questions?
jeff: in the context of 4 years work on WoT, the level of application/semantic interoperability general IoT space has improved but not as large an impact as expected
<kaz> wot architecture draft
jeff: we haven't gotten to the level
of implementation
... would like to find the areas of greatest impact going
forward
... Interoperability is still a huge challenge
... concerns that the workshop will play a sufficient role to
result in a giant step toward consensus
... will the workshop as now planned be effective?
... the range of topics is very broad
... What do others think?
McCool: agreed, it is a matter of
prioritization
... what is our next step of activities?
Kaz: agree, we can regenerate the topics
McCool: also we can look at the goals
and identify gaps
... the contributions need to focus on achieving the goals
Lagally: we also need to drive toward adoption
kathy: we have a bridging system that
works to put a smarthome system together
... produce a web thing that is not tied to cloud services or
smarthomes
McCool: there are things in this
implementation that could be standardized
... we may want to standardize runtime plugins
kathy: where we need to agree is on
the schema
... the gap is the schema, how to describe the device and the
API
... basically where are we with iot.schema.org?
McCool: one data model is working on a common information model
<Zakim> jeff, you wanted to comment on the range of use cases
Lagally: what should we take out and leave in?
jeff: for each of 35 sub-bullets
there are 10 application domains
... an eexample of narrowness is the Mozilla smarthome
implementation
... maybe we need to move toward 1/2 dozen narrow examples like the
Mozilla system
... look at those and identify areas for standardization
... the current call looks so broad that we may not get consistent
examples
... The Mozilla system is a good example of the narrow input that
would result in cohesion
Kathy: the mission statement is great about countering fragmentation with a web based abstraction layer
McCool: we could reduce the number of
topics and the application areas
... but maybe we shouldn't jump to smarthome
Kathy: the range of use cases is a good thing
McCool: can we get feedback on which topics are priority?
Ege: worry that the whole topic list will be considered to be Web of Things
Lagally: what is the actual problem we are solving?
jeff: too many topics, too little
focus
... focus on future standardization opportunities that are
associated with each contribution
Lagally: how do we align with the submission deadline?
jeff: the leadership team can take a
convex hull of all the ideas
... for example, under the "Information models" and "use cases"
bullets, there may be enough material to go on
... especially if there are not a lot of coherent submissions in
other areas
Lagally: the committee can take up this process of prioritizing
jeff: that's a great idea, then you can go back to the introduction and tighten up the verbiage around determining the next generation of WoT work
Sebastian: how do we get a final OK that the workshop is taking place?
jeff: personally don't have approval rights, but can drive consensus at the W3M
Lagally: so we will get feedback from everyone here, narrow down the scope and range of topics, and present an update at the next Wednesday call
Kaz: we can have an updated draft by the end of Tuesday
Lagally: so we need all feedback by
noon Tuesday CET
... is that enough time for people to provide feedback?
<zolkis> it should be enough
Kaz: continue this discussion online with the assumption that we will ask for feedback by Tuesday
<kaz-win> dan: "This workshop solicits papers touching on many varied areas that relate to the Web of Things initiative, but will prioritise submissions that focus clearly on the role, nature, maturity and integration of various standardization efforts."
jeff: anything else at this point?
everyone: Thanks, Jeff
McCool: we should narrow it down to five topics
McCool: interop testing is not a
priority for this testfest
... there are tools to process the interoperability and people can
put the results in the same place with a slightly different csv
file
... wot-thing-description/testing directory
... record the outcome of testing producer-consumer pairs
... for failures, provide detail
... P-C pairs can be listed more than once if there are different
tests
... the tool collates all the results together and builds a
matrix
... points off for no security
... the names in the table are defined in the impl.csv file
... and are also used in the implementation description
<kaz-win> https://github.com/mmccool/wot-thing-description/blob/updated-test-results/testing/inputs/impl.csv
McCool: create PRs against the main
repository
... will add dates later
... spend 1/2 hour to get organized
McCool: how do we get people to adopt
and deploy ?
... and make it easy to use
... how do we track adoption?
... what targets can we focus on to drive adoption while
maintaining balance and breadth
Lagally: the W3C landing page is very old
McCool: there is a draft of a new page but we haven't pushed it out yet
<kaz> https://www.w3.org/WoT/
McCool: landing page should point to
the workshop
... we can start over with a simple landing page and maintain
it
... can we meet with the W3C team about this?
Kaz: will make the contact with W3C team
McCool: also we will want to promote
reference implementations like node-wot
... there are some simple implementations that people can also
use
<kaz> ACTION: kaz to talk with the W3C Comm Team about the WoT landing page
<trackbot> Created ACTION-162 - Talk with the w3c comm team about the wot landing page [on Kazuyuki Ashimura - due 2019-02-08].
McCool: each company may have things
they want to promote around WoT
... we don't have branding or logo
... W3C does have badges like the HTML5 shield and graph logo
... there should be some well known indication of compliance
... W3C published test results and a compatibility matrix on
browsers
... there might be a similar thing for WoT
... self-certification or do we run the tests?
... we could make a compatibility list of features e.g. security
schemes
Kaz: we could start by publishing notes with the plugfest results
McCool: we could put the matrix up
front, linked from the landing page
... look at the current HTML material
<kaz> (sounds like something like "Can I use WoT?" site. fyi: https://caniuse.com/)
Sebastian: who is going to be responsible, who is the point of contact for this work?
McCool: we can do some basic items
with shared responsibility
... we should get 1 or 2 volunteers
<kaz> (fyi, accessibility initiative has a WG on education and outreach: https://www.w3.org/WAI/about/groups/eowg/)
McCool: for the education task
... let's use the intro paragraph from the CFP about countering
fragmentation as the intro to the interim landing page
... what about tutorials, who is interested in working on a
tutorial
Ege: can I write it on medium?
McCool: we should get a couple of
people together to discuss and bring a proposal back
... both examples of node-wot and ad-hoc implementations
... with security etc.
... proposing a task force to deliver tutorials
<kaz> https://www.w3.org/WoT/WG/
McCool: core tutorials on W3C site
<kaz> https://github.com/w3c/wotwg
<kaz> (we can put the actual content on GitHub and add forwarding configuration to the www.w3.org server)
Nakamura: will present security
metadata examples
... worry that people will have difficulty understanding the 2
proxy configuration
... three patterns, direct servient-servient, one proxy, and two
proxy
... proxies that use WoT exposed and consumed thing for
communication
McCool: how does it work with firewalls, where are credentials needed
Nakamura: it is hard for the
application to manage all of the credentials
... in the 2 proxy pattern
McCool: no way to carry header
information across proxies
... but the inter-proxy API may not be public
... how does the application tunnel through the near proxy to
authenticate to the far proxy
... also may be an issue of URI rewriting
Nakamura: the proxies can each
authenticate locally to the next proxy
... pattern 3-2
McCool: could the reverse proxy be a
forward security proxy
... and hide the proxy from the TD?
... also there is a pattern with multiple forms that have different
entry points on different proxies with different security
mechanisms
... the reverse proxy could delete the forms with local URIs
... with multiple forms there could be a way to help the client
choose the best form
... there could be ordering rules, internal metadata, or external
metadata
... only one base URL witih full URLs for the alternate entry
points
... we need to work through how to secure local access i.e. LAN
without CA based PKI
... and how to organize the selection
Nakamura: should show how to structure the security metadata for the configurations in the architecture document
Kaz: this may belong in the security document
McCool: the security best practices
document is a good place
... next steps, we can take this up in the security meeting
... start with a list of configurations we care about
... it may be too late to add to the TD document
<kaz> f2f agenda
McCool: to summarize, we need to update the landing page by next week, and start an education task group
McCool: discuss TD and test
assertions
... we have a 6 month extension so don't need urgent recharter
resolution
... IG charter is a long list of topics
Kaz: there is approval for the IG
extension but we need to make an announcement about this
... the workshop is barely ahead of the recharter deadline in
June
... discuss tomorrow
... what else do we have to talk about
Lagally: event discussion
... TD events
McCool: respond to the event issue
and discuss in the TD session tomorrow
... missing a payload definition for subscription response that may
contain unsubscribe/cancellation information
... what if the response contains a URL?
... can we use the pattern of a returned TD fragment?
Kaz: we could discuss recharter now
McCool: what is the expected date for
the IG charter?
... target end of March
<kaz> draft IG Charter
McCool: need to have an election for new chairs in March
<kaz> Ben's comment to issue 599
McCool: simple API, browser API, or
other?
... have a general topic about application API standardization in
the IG
discussion on the hypermedia driven API topic
discussion on profiles for applications and protocols
change to "additional Use cases and Requirements"
<kaz> kaz: also we need to convert "specification"s to "document"s
<taki> Scribe: TK
<taki> ScribeNick: taki
Sebastian: Camel Case for op
values
... issue #179
... Proposal - use readProposal, writeProposal, observeProperty
McCool: for consistency
Koster: also consistency with IETF specs
McCool: also subprotocol, longpoll, webhooks, etc.
Koster: if we do not care about IETF rules...
<kaz> issue 179
Koster: Weblinking spec says terms
rels should be lower-case.
... also good for round-tripping
Sebastian: this is nice to
have.
... everyone ok as it is now?
... Let's keep as it is.
Ege is recording the decision in GitHub...
Koster is closing the issue...
Sebastian: meaning of op values
McCool: we need behaviour
section.
... it does not say anything about behaviour.
Sebastian: Include JSON Schema
"anyOf", "allOf" and "not"
... issue #298
<kaz> issue 298
McCool: no use case so far. it may help developers.
Sebastian: Full JSON Schema
support
... we currently support a subset of JSON Shema
... we can have a note that semantic processing for such terms are
not possible.
McCool: "oneOf" has an use case.
Sebastian: URI datatype? Introduce
"format" term?
... #226
<kaz> issue 226
Sebastian: JSON Schema "format" term.
Koster: It is used for URI pattern, there are also other use cases.
McCool: there can be multiple
context
... please keep this in mind.
Ege: does anyone support this?
McCool: this is mainly for validation.
Lagally is enumerating various formats...
Sebastian: format is about hint of the pattern of strings.
McCool: we need two volunteers immediately at this point.
Sebastian: JSON Schema "format" helps identify URI as URI.
Koster: example? href?
McCool: subscription's dataschema too
Sebastian is writing an example
Sebastian: "format": "uri-reference"
McCool: who volunteers implementing?
McCool assigned people to implement this feature...
<scribe> scribenick: taki1
McCool: I hope we can find a good reference we can point to.
Sebastian: Link also has a set of specifications.
McCool: it does not change validator.
Sebastian: right
Koster: namespace can help avoid name conflict
McCool agrees
Ege: property is readonly, but op=writeproperty. we have this kind of cases.
McCool: readonly/writeonly definitions are not present in TD spec.
Ege: are there dependency?
McCool: it just does not have
effect.
... it is ok though it should be disallowed
... putting it into spec is very complicated
Koster: op is optional. when there
are multiple, it is mandatory.
... default can depend on readonly/writeonly.
... it should be covered by default.
... we already have default for op
McCool: but not context
dependent
... Canonicalizer can do that.
... we may want to stay with the current way.
... we should also check definition in JSON schema.
... it may allow to write those combinations.
... we need more precise definition
... current definition is self-referencing
... definition in JSON schema seems clearer
Ege: I discovered that href can be
""
... empty string
Koster: it is ok. perfectly fine.
Ege: we are aware of it right?
Koster: URI reference allows for that
Ege: I suggest to link vocabulary with examples.
McCool: forward link?
Ege: yes
Sebastian: we have to do it at the
end.
... good idea.
McCool: extra column pointing to example?
Sebastian: maybe too much.
Ege: I created many new issues as the result of testfest.
Lagally: observable property.
... how to cancel?
Sebastian: unsubscribe to the same topic.
Lagally: this is not event
Koster: some protocol requires
unsubscription
... what if application wants to unsubscribe?
Sebastian: we have "obserbeproperty"
Sebastian: why not have "unobserveproperty"?
McCool: naming should be
consistent.
... unobserve is fine
Ege: vote?
McCool: "unobserve"
Koster: how about cancel
action?
... I can provide an example.
McCool: do we need websub?
Koster: we need to take a closer look
first.
... how about SSE?
McCool: eventsource, SSE, websub
Koster: we need to take a look at Fujitsu and Mozilla implentation for WebSocket.
McCool: webhooks has one implementation.
Koster: RESThook is an implementation name
Ege is adding a new issue for adding webhooks and event source...
Kawaguchi: Webhooks, we saw siemens
example TD yesterday.
... is it possible to use it for observing properties?
Koster: it is more complicated.
... we want to keep property as simple as simple
Kawaguchi: it should be clearly described.
McCool: longpoll and event source.
This is simpler.
... webhooks?
Koster: In CoAP, I can use webhook.
McCool: subprotocol is mostly for
HTTP
... should we add those two?
... we can clearly describe WebHooks is not for property.
... for tomorrow, I am going to make a several PRs.
Sebastian: same room logistics
procedure tomorrow as well.
... Until 12:00. No lunch. Coffee to be provided.
... We can still discuss TD tomorrow, but won't be that long.
McCool: dinner plan?
Kaz: Chinese restaurant next to
Mexican restaurant yesterday.
... 7:30 @ Lobby
McCool: next meeting collocated the
upcoming workshop?
... maybe after the workshop?
Sebastian: would make sense
McCool: can you look into the possibility of Sat/Sun?
(workshop expected on 27-29 May)
Sebastian: need to ask TAG for review
McCool: let's get things cleaned up
McCool: need to talk with W3C
management
... e.g., possibility of publicly available WoT test site
Matsuda: certification of WoT?
McCool: validation of people's resources
Kaz: we need to clarify our expectation/requirements for that before talking with the W3C Management
McCool: hoping lighter mechanism to
validate resources as a starting point rather than
certification
... would think about some kind of branding as well, but that
is another story
... validation about TD and device behavior
Sebastian: good topic for the IG side?
McCool: can take an action to put the ideas together
McCool: kind of discussing possible collaboration with other smart city orgs
McCool: should invite people from the
other SDOs, e.g., IIC, to our meeting, e.g., the workshop
... anybody going to IIC next week?
(McCool, Taki, Matsuda-san)
Sebastian: end of March, there will be an IETF meeting
McCool: Koster?
Koster: will be there
... discussion with WISHI guys
McCool: can go
... when will we have vocabulary extension?
... should discuss how to do that
... currently have difficulty with validation
... if I come, would like to talk about that
Sebastian: can you share the information about the meeting?
McCool: WISHI links
... will try to attend the online meeting
... talk about extension schema
... how to validate them
Koster: currently protocol binding service doesn't check the data
McCool: our first priority is getting REC but we should discuss validation as well
McCool: btw, regarding the upcoming
WoT workshop, who from us are planning to submit position
papers?
... I myself will
Sebastian: W3C workshop is not an academic conference
<mjkoster> here is a link ti the T2TRG WISHI wiki pages
<mjkoster> https://github.com/t2trg/wishi
Sebastian: position paper could be just a one pager
Kaz: clarification on workshop expectation@@
McCool: maybe one pager is not enough
Kaz: the purpose of w3c workshops is getting new ideas and participants from the industry
McCool: would work with IIC
... and ITU
... nice to bring them to the table
... and One Data Model
... when is the next OCF meeting?
Koster: OCF is sponsoring the One Data Model
@@@ slides tbd
Koster: [What is the OneDM Group?
Who is involved?]
... a liaison group including mostly SDO members
... OCF, Zigbee, Thread, OMA
... data model interoperability is one of the topics
... what they decided to invite non-liaison people as well,
e.g., W3C
... also include Bluetooth
... proposal for a subgroup to handle private information
... we have Google, Amazon, Comcast, Honeywell, Legrand,
Philips Signify
... hosted on the OCF Enterprise Workspace (Kavi)
Lagally: any resources?
Koster: some presentations
available
... high-level interoperability stack, etc.
Lagally: can access them?
Koster: probably you need to contact
somebody from them
... we can join them as one of their members as well
... [What is the goal?]
... very similar to our goal
... define a common data model for high level interoperability
between IoT devices and services
... interesting question about data model how tightly coupled
with serialization
... [What is the process?]
... reviewing existing models in progress
... iot.schema.org/WoT, Google/Nest, OCF, Zigbee, OMA LWM2M,
etc.
... some people are thinking about higher model
... focus on abstract model
... decoupled from serialization
... common meta model
Lagally: what about interaction?
Koster: we need some kind of
commands
... event, action, property affordances are common features of
most models
McCool: curious about IoT
stakeholders involvement
... what about browser companies?
... other than Google
Kaz: do we want to establish a liaison with them?
Koster: if we want, maybe we can establish a liaison but their work include NDA portion
Lagally: possibly we can think about a liaison without NDA part
Koster: that's what I'm suggesting to IETF too
Kaz: if we want to establish a liaison with them from our side, I think I should talk with the W3C Management as well beforehand
<scribe> ACTION: kaz to talk with W3M about possible liaison with the One Data Model group after McCool/Koster/Lagally's outreaching them
<trackbot> Created ACTION-163 - Talk with w3m about possible liaison with the open data model group [on Kazuyuki Ashimura - due 2019-02-09].
Koster: having some presentation
about our work on WoT to them would be interesting
... also would like to look into Zigbee, etc.
McCool: data model for Zigbee
... you (Koster) and should coordinate
Kaz: btw, we should invite these guys as well to our workshop. right?
Koster: right
McCool: remember that Oracle has data model translator
Matsuda: the scope of the one data
model is specifying some concrete data model?
... or just thinking about metadata?
Koster: think both
... common data model is something like our TD
... at a high level
... that is definition of interaction model
... and different schemas to specify the value
... decided to work on high-level data model
(some more discussions)
McCool: what to do for the next
step?
... 3 of us (Intel, Oracle, SmartThings) to look into their
work?
Lagally: we should see what they're doing
McCool: want to present OCF work and WoT work to them too
Koster: put all the WoT work including Oracle, etc., into that WoT presentation?
Lagally: let's put our ideas together first
Koster: can contact them and ask about if we can get their information
McCool: our internal meeting next
week?
... we'll have a Wed meeting (main call) and a Fri meeting
(TD)
... and decision in 2 weeks
... any area for presentation?
Kaz: under the wot repo
Kaz: btw, won't we have f2f recovery rest next week?
McCool: no
... we'll have calls next week
Kaz: so no call on Monday but all the expected calls on Wednesday?
McCool: right
... all the calls wed and fri will happen
Sebastian: wondering about the possible sponsors for the workshop
Kaz: we can think about sponsorship after getting approval for the workshop :)
[break till 10:35]
McCool: regenerated the
implementation report
... including the updates from Panasonic, Oracle
... still working on bug fix for the assertion tester
tool
... looking through the results
... still have uncovered features
... by Wed, will create new directory for the data
Sebastian: regarding the spec, Victor is
working on the section about transformation to JSON-LD
... possibly several additional assertions
... goes through the PR version TD
... about transformation to JSON-LD
... list of container, type, context
... have not reviewed this update completely yet
... would like to discuss this during the TD call on Friday
McCool: all this content informative?
Sebastian: we should discuss that
McCool: think this proposal is
clear
... but may effect the assertions
Koster: I do use semantic information within my TDs
Lagally: wondering about the text from
this proposal
... does this pushing RDF?
Kaz: would be better to send this to the group and ask the group to take a look before the review during the TD call on Friday
Sebastian: ok
... and let's discuss how to deal with this during the TD
call
Lagally: what is the status of JSON
Schema?
... already tight enough?
... need further iteration?
... there is an Editor's note
... "This schema is known to be too permissive."
McCool: we need to clarify how to do
what is needed.
... we should tell people how they can make the schema
restrictive
Kaz: who is expected to explain that?
McCool: Ege to generate a PR for that?
<scribe> ACTION: ege to create a PR on how to make the schema restrictive
<trackbot> Created ACTION-164 - Create a pr on how to make the schema restrictive [on Ege Korkan - due 2019-02-09].
McCool: this point raised an issue about checking all the remaining Editor's notes within the spec draft
Sebastian: searches for "Editor's
Note"s
... (noticed fig. 2 is missing)
Kaz: we should think about the updated timeline
McCool: we should aim the end March
as the deadline
... also we need to get TAG review
... what about mid March?
Kaz: we need to list "features at risk" within the status section
McCool: can add some additional ID to identify features at risk
Kaz: note that we need to generate "explainer" for TAG review
McCool: any template?
Kaz: there are many examples on GitHub
McCool: will make updates for report.html by the TD call on Friday
Kaz: would suggest we create a specific directory on GitHub so that we can search for them easily
<scribe> ACTION: kaz to create an area to store presentations from f2f meetings
<trackbot> Created ACTION-165 - Create an area to store presentations from f2f meetings [on Kazuyuki Ashimura - due 2019-02-09].
Taki: points out an issue
<taki> TK: Appendix B Thing Templates
Sebastian: related to issue 279
<taki> TK: There is a paragraph that says it is Thing Description where some optional parts are not present... But example B.1.3 is a composite template.
<taki> TK: which appears to be different from what the description says.
Sebastian: put a proposal on the
issue
... already working on that
[[
Proposal:
Since a Thing Template is a subset of the Thing Description in which some optional and mandatory vocabulary terms does not exist, however, it can be serialized in the same way and in the same formats as a Thing Description. Note that Thing Template instances cannot be validated in the same way as Thing Description instances due to missing mandatory terms.
]]
all: ok with that proposal
[f2f meeting adjourned]
