(Some more photos are available online.)
sk: explains the summary
mk: explains the procedure
... cross-domain/vendor interoperability
... difficulties with mappings
da: [TD repository]
... [Thing Description with Semantic Annotations]
... [How-To]
... step 1-4
... step1: include WoT common context in TD "@context"
... step5: discover a Thing
... (clicks the link of
http://plugfest.thingweb.io:8081/td-lookup/sem?query=YOUR_ENCODED_QUERY)
... (clicks the link of http://plugfest.thingweb.io:8081/td-lookup/sem?text="Temperature"
... [Sum-Up]
da: TD repository
... More details on GitHub (github.com/thingweb/...)
sk: small automation scenario
... node wot scripting
... local system connected by CoAP
... node WoT to integrate different devices
... temperature sensor still not working
mk: new version of TD
... need cross-vendor testing
... data types to be understood
... would clarify what is working and what is not
lm: new version of SSN and TD
mo: will show a demo having many
devices in Osaka
... lights, air conditioner, etc.
... [Panaonic Demo System Configuration]
... use Amazon Echo for speech input
... control devices in Osaka
... using a command
nk: [WoT Scripting API
Implementation]
... scripting API provides abtract API of things, and enables
developers to implement apps based on WoT
lr: our vision proposing a solution
to interoperability problems
... proposed architecture named "SEPA" (SPARQL Event Processing
Architecture)
... 3 different contexts
... cards, colors and users
... context manager handles those 3 contexts
... this is our research topic
... explanation on SEPA, PAC pattern, SPARQL 1.1 Secure Event
Protocol
bp: : a water tap and a sensor
bk: BMW demo
mm: OCF demo
... CoAP-based
... REST APIs as well
... the goal is not translating each OCF device
... but translating all the OCF world
... starting with motion sensor
... (shows TD example dynamically generated by an OCF device)
[Mr. Ohsumi and Daniel join]
mm: whole bunch of stuff here
... 10 devices included
... (clicks on of the links)
... gasSensor
ud: how to proceed
... people come to each table
[ break ]
[Taki joins]
mk: we'll have demo tomorrow
... how/when to give the wrap-up?
mk: gives quick summary on testing
things
... error handling as well
sk: connected to lemonbeat
device
... shows scripting part as well
... also typical network issues
... with node wot
lm: semantic annotation
da: what kind of Things are
available?
... you need discovery
... how would you find Things to connect to?
... so discovery is important
kn: Panasonic demo
... also Darko's discovery
... trying Matthias's device
... issue with security server
... will try tomorrow again
mk: need to describe security
mechanism
... accessing token, etc.
... what to do with HTTPS?
... will work on the issues
... how to model this for TD?
kn: need to think about online
testing for better use of time
... performance test as well
mk: demo is a specific use case
... component test and combining test
<inserted> ud: mentions lemonbeat demo
ud: next step would be automatic connection
dw: it was interesting to see the current status. made progress in understanding the context better
lr: semantic web and IoT
... semantics is also important
... security and privacy
... not clear yet
mk: most of the participants come
from protocol level
... how to automate interaction between various devices based on
semantics
... loose coupling
... possibly handy query language
... would be a library for all the implementers
... to make it easier for developers
... what kind of tools are needed?
... input would be helpful
mm: OCF mapping
... what is missing?
sk: would be good to have even nicer
setting for preparation
... to have enough time for actual PlugFest
(question on how to organize PlugFest prep. and PlugFest demo)
mk: fully agree
... could have more discussions beforehand
... for tests as well
... e.g., dedicated online meetings for PlugFest preparation
[ PlugFest Day ends ]
<kaz> scribenick: kaz
oliver: CEO of lemonbeat
... happy to host this event
oliver: [The Lemonbeat GMBH]
... origin is smart home
... happy to contribute to IoT space
... would introduce Andreas
andreas: [BMWi* Funding
programme]
... 2 step approach: sketching and actual project
... [The 5 "SINTEG" showcases]
... [know-how for the region]
... we can cover all the energy transitions
... high-load areas, medium-load areas and low-load areas
... combining 3 different areas
... getting funding
... [Experienced partners from on of the economically strongest
regions in Germany]
... 31 project partners, 15 associated partners
... [The energy system becomes more distributed and complex]
... in the past - in the future
... [The distribution network - Backbone of the energy
transition]
... EHV - HV - MV - LV
... more than 90% of the renewable energy systems are fed into the
German distibution network
... [Sokutions which ensure that the region actually benefits from
the energy transition]
... huge infrastructure
... self-learning by AI
... out of experience
... [Designets integrates individual solutions from various
sectors]
... overall system, e-mobility, intelligent grid, digitization,
distributed generation, flexible industry
... no standard protocol yet
... standardization would be very helpful
... [Just ike DNA in cells, our lemonbeat software stack with our
LsDL empowers each device]
... offer flexibility and get flexibility from the market
... [We make the energy transition easy to grasp with the "ENERGY
ROUTE"
... demonstrators come alive
... signage of demonstrators along the "energy route"
... access to demonstrators, "showrooms", events and open-house
days
... combination of different projects
... sector coupling for different energy transitions
... [Five answers]
... our motivation, our goal, our approach, our path, our
showcase
... need to be neutral to various vendors
... tx!
... questions?
lindsay: web protocol working so far?
and: lemonbeat implementations?
scribe: yes, there are
dsr: electric car is one challenge, and...
and: e-mobility massively effects our infrastructure
scribe: shift the systems
... 2 opportunities
... challenge is renewing the end
... huge tech problems
... e.g., voltage drops
... infrastructure like cables
... using IoT compensate usual consumpation
mk: how many different protocols/standards are there?
and: can share my feeling :)
scribe: the solution provides
flexibility
... heat pump, heating system, water system, etc.
... not based on standards so far
... there are different manufacturers
... using different protocols
... standard interface would help interaction
... if you want please follow the slides and contact me
... tx!
uday: meeting followed by a social
event in the evening
... city tour and dinner
... looking forward good discussions
<dsr> scribenick: dsr
Kaz Ashimura (W3C) introduces the W3C Patent Policy and its implications for our work.
W3C advances specifictions through 5 steps from an initial Working Draft to the final Recommendation (W3C’s term for its standards)
W3C Recommendations must be available to implement on a royalty free basis.
You are encouraged to join the Working Group if you haven’t done so already, and to make the corresponding licensing commitments.
The WG Chairs can invite guests to WG meetings, however, we need to be aware about potential IPR issues that could arise from contributions from people who are not formally part of the WG.
Kaz shows the important points from the W3C Patent Policy document
When contributions are being considered for inclusion in a document intended to become a W3C Recommendation, the WG Chairs should ask the contributor to disclose any essential claims that they would not be able to provide royalty free licenses as per the W3C Patent Policy
Kaz lists the managed repositories relevant to the WoiT WG
If the WG is unable to secure licensing for essential claims under the W3C Patent Policy, the Chairs should endeavor to steer around the concerned technical aspects.
Michael Koster (SmartThings/Samsung) presents.
There are many standards organisations, and these have taken their own approach, and in some cases are competing with each other.
The approach we’re taking is to enable semantic interoperability at the application layer
We’re looking at well known formats to describe how applications can interact with things.
We’re adapting the patterns from schema.org that were developed for smart search results, and combining this with other ontologies and vocabularies.
We want to do this in an open process that doesn’t require formal membership of a standards development organisation..
Contributions based upon either the W3C Community Group or the schema.org frameworks
Michael presents a semantic stack model
This has the ontologies at the top, the web of things in the middle, and specific IoT standards suites at the bottom
We want to enable a means to abstract capabilities, e.g. motion sensing, turning something on and off and so forth.
Actuation may be incremental, e.g. light levels and colours rather than simply on and off
Michael describes how the iotschema,org capability pattern relates to the web of things.
Essentially a capability is mapped to an interaction pattern with its associated properties, actions and events.
Michael shows a JSON based representation of an example capability
We’ve done some initial work to prepare a charter. We hold monthly teleconferences and we’re about to apply the charter to the W3C Web of Things Community Group.
We plan to use the CC-SA license for contributions.
Collaboration with the W3C WoT IG and WG
We’re aiming to collaborate with other organisations to enable re-use of existing ontologies
Work on factoring out differences across ontologies, semantic annotations and support for composing services.
Zoltan: I really like the notion of capabilities
Michael: At Smart things, we have had several years experience with capabilities
Capabilities also help with security
<zkis> capabilities could be used as funcionality units for permissions and policies
Capabillities are building blocks for things and not for use on their own
We don’t need to express capabilities directly in thing descriptions, but rather to use them to describe relationships between things and capabilities
Stefan: is this approach already accepted by schema.org ?
Michael: that’s an interesting question. We’re really at an early stage where we are working on a proposal that we want schema.org to take on board
Matthias: in the Web of things, we want to model the physical world. We need to relate the interaction model to the physical capabilities
Dave: we need to recognise that different communities will develop different vocabularies, so we need bridging ontologies that allow search using shared concepts rather than having to use the different terms for each of the different vocabularies
Lindsay: ETSI is also working in this area. The problem of relating different models can be likened to the parts of an iceberg that is under the water - it is very much larger and risks sinking the ship of interoperability
Philipp Hoschka: what is the relationship betweeen schema.org and W3C?
Tobias: how do you exploit these descriptions in applications?
Michael: the combinations of these different kinds of descriptions can be used to support discovery, composition and adaptation by smart services
The Web works because it is simple, much simpler than some of the older ideas for hypermedia
We want to make it easier for people to innovate and contribute new ideas
The protocol binding for the web of things maps the abstract models to the concrete protocols
We want to avoid the complexity of the Semantic Web and make life easier for regular developers.
Michael_McCool: there is a risk of alienating developers if we don’t do a good job on that.
Kajimoto-san: one challenge is what things call themselves, another is who owns the things.
Michael: we need a means to describe the interaction model and also a means to describe the relationships between things at a semantic level
There is a lot of other categories we need to look at including security policies
Luca: we should exploit the work that has been done for the Semantic Web, why aren’t we using RDF rather than JSON?
Michael: we trying to use the framework of RDF but to avoid the need for developers to first become semantic web experts
We have some choices to explore for this
Dave: we need to keep distinct the serialisations from the underlying framework.
[break]
Presented by Juan Carlos Zuniga (Sigfox)
Juan introduces Sigfox. This is a company that focuses on low power wide area connectivity for IoT devices.
Key goals include low cost and low data rates
Sigfox is a connectivity provider that builds and operates the network with regional SNO operators
We charge for connecting devices to the Internet
Sigfox can be applied to a wide variety of domains, including assisted living, home alarms, smoke detectors, precision agriculture, tracking moving assets.
5 main business benefits.
Sigfox coverage in the USA, South America, Europe, South Africa, Japan and Australia
Sigfox is designed to scale to very large numbers of devices,
The sigfox foundation supports applications such as tracking protected species like rhino’s
Sigfox uses ultra narrow band and frequency hopping.
This relies on software defined radio technology, also know as cognitive radio
Messages are sent with multiple copies in different frequencies
Uplink messages have 12 byte payload, downlink 8 bytes
Up to 6 messages uplink per hour and 4 messages downlink
After sending, the device listens for a reply in a short window of time
Devices spend most of their time asleep with negligible power drain, allowing for years of battery operation.
Devices are pre-provisioned with their credentials. Standard APIs are provided for accessing data on common cloud platforms.
Keen on standards based interoperability.
Collaborative approach to security, and design for privacy
SCHC - static context header compression for sigfox and LoRa from LPWAN WG
Demos of IPv6/CoAP over LPWAN
Interoperability at the application layer - demos for IETF
Privacy focused on explicit personally identifiable information
Example: if a trash bin is used, you know that someone is in the house.
Proactive privacy by design principles.
Resilience to botnets and tempered with devices - blocking and blacklisting capabilities in the cloud
Different levels of security according to the criticality and type of application.
Michael_Koster: what do you mean by device autonomy?
Juan: devices can talk whenever they want, there is no need to synchronise clocks etc.
some discussion around IPv6 via header compression
<scribe> On-going work on layering CoAP on top of this.
We’re looking at supporting message fragmentation and reassembly
Matthias provides some additional context
Juan: our cloud APIs provide metadata that comes from the cloud for the device, but is not held on the device
IETF work as a collaboration across several technology groups, e.g. sigfox, LoRa and 2 others
Darko: what format are you using for metadata and how is it managed?
Juan: right now every device maker does their own thing. We are seeking ways to converge. We’re not pushing on a single approach, but want to encourge convergence
Presented by Stefan Schmid (Bosch).
The project started 18 months ago and is half way through
The project name is an acronym for bridging the interoperability gap of the Internet of Things
See: http://big-iot.eu/project/
Photo of busy city street with cars, trams and pedestrians, and many kind of IoT devices
Each of the IoT systems form independent silos
The objective is to enable interoperability across these silos
We want to foster and incentivize collaboration via a marketplace of services
The marketplace includes support for monetizing services.
The marketplace is aimed at developers not end users
Example for a smart parking service where street sensors report which spaces are not in use
This could involve a mix of technologies and communication standards
We need to support evolution of services and technologies. How can we enable applications to take advantage of new capabilities?
Service providers and consumers with authentication, registration, discovery, subscription and accounting
The service offering description specifies the access control policy
We use JSON-LD for the descriptions, based upon the work by the W3C Web of Things IG
Stefan talks us through the different kinds of information in the description.
We provide a simple API that abstracts away from the details of the underlying platform.
We can provide a gateway service for accessing non Big-IoT platforms.
Likewise, we support proxies when it isn’t appropriate for apps to directly access devices.
Big-IoT is working witg Eclipse IoT for our open source strategy
We plan to contribute semantic models to schema.org
We expect to very soon have approval from Eclipse for our proposed open source project.
Demo of the smart parking service in Barcelona
Stefan talks us through how a company could add its parking lot to the service.
You can query for parking space providers within a given radius of a given location.
A new provider needs to register its offering with the marketplace
This involves customizing some Java code …
The end user app shows available places and pays for the parking charge.
Juan: do you see a single market or multiple marketplaces?
Stefan: many marketplaces, first because of the amount of data, and secondly due to regional and domain specific variations of requirements
Kaz: are you interested in a standard API for payments from web browsers for web based applications?
Stefan: this is a research project with limited resources. There are many options for commercialising our work.
Philipp_Hoschka talks about the Compose EU project which also worked on marketplaces for IoT services.
Stefan notes there are already many IoT marketplaces.
Matthias: how did you survey the developers for the marketplace requirements?
Stefan: we learned that different developers prefer different programming languages, and that Java isn’t a universal solution.
<kaz> [ break ]
<kaz> scribenick: kaz
Lindsay: charing ETSI ISC CIM
... experience is very diverse
... [Audience Calibration: Hands up who knows of ...]
... SF book of "1984" and "Future Shock"
... also "Shockwave Rider"
... and then "General Data Protection Regulation" by EU
Parliament
... starting in May 2018
... smart city/parking would require much private data
... companies are not good at this kind of regulations
... organization in breach of GDPR can be fined up to 4% of annual
global revenue or 20M Euro
... [Audience Calibration: Hands up who knows of ...]
... manipulating genes
... changing DNA structure
... whole bunch of scratch pads
... like RFID embedded in cells
... [cell genome "recording of event histories"]
... transilation for "1984" and wiki-leaks readers
... cell genome could be made to inpact "your" cells...
... [Outline of this talk]
... ETSI ISG work
... main work is how to make exchange semantic data
... how to interpret it
... what would happen government set requirements for smart city
trials?
... [Digital Transformation for Wellington, New Zealand]
... half as NEC and half as ETSI
... measuring the quality of city
... how to improve comfort order
... sensing overcloud, etc.
... using video data, etc.
... tracking people
... [Digital Transformation for Christchurch, New Zealand]
... traffic jams
... tracking number of people
... [Smart Cities ... and standards]
... [Standards help all stakeholders]
... Standards help
... voluntary/dynamic
... creates an ecosystem of experts
... reduce risks
... governments/citizens need to ference standards
... issues with execution risks, cost explosions, obsolescence,
privacy, physical risks and liability
... have to worry how to record provenance
... need to know about your data
... license, quality, freshness, etc.
... [IoT-related SDOs & Fora: "Formal" overview]
... De Jure: ITU-T, ITU-R, ISO/IEC ETSI, ...
De Facto: W3C, oneM2M, ...
McCool: OCF as well
Lindsay: [Smart City related Groups
in ETSI]
... ISG CIM (Context Information Management)
... oneM2M here in the middle of the picture
... IoT systems are annotated
... problem from me is having a lot of stakeholders
... [Currently >300 EU IoT/SmartCity RnD projects]
... examples of A-B
... all those working on IoT and APIs
... [Work Item Scopes of ETSI ISG CIM]
... 6 different work items
... https://portal.etsi.org/tb.aspx?tbid=i54&SubTB=854
... ontology to describe information model
... no. 7 is security and privacy
... [Privacy Issues and Exploring Solution ...]
... [ETSI ISG CIM: Problem space and solution space]
... mind map
... goo.gl/1zFPRz
... [Context Information Management: Issues]
... enlarged mind map
... what kind of identifiers to use?
... privacy by design is a hot topic
... need to have some usage data
... what if including privacy information?
... [Context Information Management: Privacy]
... you can find these by visiting goo.gl/1zFPRz
... using blockchain to secure the data
... serialization of the data
... possible attack, e.g., by undermining
... de sur SDOs here
... CEN-CLS/JWG-8
... ISO/IEC 27550
... OASIS PMRMv1.0
... ISO/IEC 20547-4
... etc.
... [Links]
... [Help on ETSI ISG CIM Discussion Issues]
... 1. requirements for exchange of cross-cutting context
information, to be fit for purpose in Smart Cities, S,art
Agriculture and Smart Industry use cases
... 2. How to ensure ISG CIM API is flexible to cope with all
desirable types of context data and instance data
... 3. Requirements for ISG CIM API to express the important kinds
of queries for heterogeneous databases of context information for
cross-cutting domains
... 4. Managing the identifier(s) for entities and referencing them
in API queries, even across legacy databases
... Ensuring privacy protection (fine-grained access control,
encryption) on specific context data, efficiently!
... different identifiers based on various stakeholders
... most of the systems are walled garden
... usually not available by external parties
... [How to help]
... Ask an expert on any of the 5 Discussion Issues to contact
me
... Download the CIM-mindmap goo.gl/1zFPRz and suggest to me your
additions
... Email me about other events/organizations which I should
contact
... Recommend to your organization to join ETSI iSG CIM
... thank you!
Koster: question@@@
Benjamin: [Goals]
... Interest of WoT
... integrate data from the vehicle with external knowledge
bases
... adds a semantic enrichment layer
... can be linke with the work of the W3C AUtomotive WG (and
GENIVI)
... [General architecture and parts]
... WoT Servient on the left side
... OEM cloud on the right side
... HTTP between them
... and CoAP between cloud and car
... [Protocol binding: LwM2M]
... WoT methods -(Python snippet)- HTTP methods -(Leshan API)-
LwM2M methods
... [Demo setup]
... OBD dongle
... browser as a WoT client
... OEM cloud
... connected using HTTP
... protocol binding and finding the device
... [Thing description: context]
... need: sensor/actuator ontology, car ontology
... w3c-wot-td-context.jsonld
... w3c-wot-common-context.jsonld
... schema.org
... linked version of GENIVI's VSS
... [TD retrieval and parsing]
... the TD file is stored in the dame repo as the WoT server
... [Thing description: sequence diagram]
... changed from yesterday
... discovery -> consume TD -> read speed
... communication among browser, WoT server and LwM2M API
... [WoT communication]
... WoT server: python script with Flask
... WoT client
... [Final interface]
... API
... endpoint/consumed
... [Conclusion and future work]
... challenges faced
... remote access to vehicle data
... protocol binding between WoT and LwM2M
... link between W3C WoT and W3C Automotive
... future work
... questions?
McCool: translation to TD?
... automatically?
Benjamin: hand coded
kaz: using VISS or VIAS from the W3C Automotive?
Benjamin: VSS as the data model
Lindsay: subscribe the data?
Benjamin: can subscribe or get data at once as well
[ Everybody moves to the parking lot to see the demo]
[ PlugFest Day ends and everybody leaves for the social event ]
<inserted> scribenick: kaz
mk: welcome to the 3rd meeting of
the WG!
... would remind you of the W3C Patent Policy for the WG work
as Kaz mentioned yesterday
https://www.w3.org/2017/Talks/0710-w3c-pp-ka/
mk: you need to become an
official WG participant to make contribution
... we're taking minutes on IRC
... please help minutes taking
dsr: microphones are available
mk: agenda bashing
... would like to start with Mozilla's contribution
... they've just made a Member submission
... after the morning break
... TD serialization
... open-source strategy
... won't go into the detail but the proposed agenda is
available online
mm: maybe short summarization from the Osaka meeting?
mk: good to repeat what we
discussed in Osaka
... we should talk together
... we go for single slots this time
... and then Day2
... security use cases/scenarios
... security next steps
dsr: can contribute to serialization today and data types tomorrow
mk: data types
... Victor?
... status, etc.
victor: maybe shorter than 1h?
mk: and the last day, Jul
13th
... security, Elena will join remotely
mm: threat model, etc.
... would like more input
... online questionnaire
<inserted> scribenick: mjkoster
mccool: has a questionnaire for security requirements
please fill out in preparation for the meetings this week
<inserted> scribenick: kaz
mk: please give your input
... next LD
... and in the afternoon, marketing topics
... and then modularization of TF work
kaz: planning session?
mk: right. TPAC, security conf., etc.
mm: for next year
mk: will talk with McCool offline as well
https://lists.w3.org/Archives/Public/public-wot-ig/2017Jul/0000.html
mk: would impact our work
mm: important to consider
this
... and other input from Members
... this proposal is descriptive
... here we do action, event, etc.
... need gateway and other things
... our work is different
... we should take this proposal seriously and think about the
pros/cons
mk: let's look at this
... would have much more fruitful discussion from this
... could be discussed during TPAC as well
... straight description on what they want
... ideas on a possible default binding
mm: could be a default HTTP binding
koster: this is a concrete API
dsr: agree inviting them to give
talk on this
... very similar with what I'm proposing
seb: 80% of this proposal is
copied from what we've been doing
... related to the serialization discussion
... almost aligned with what we've been doing since 2 years
ago
... this is a JSON approach
mk: this shows developers'
hypothesis
... kind of JSON serialization option
mm: need some tweaks
mk: let's look at this
http://iot.mozilla.org/wot/#web-thing-description
mm: this is descriptive
... they're doing exposing thing
mk: we do both
expose/consume
... they're doing another side of consuming
mm: they're using only expose, so simple
mk: if you look at "actions" here...
[[
v
"actions": {
"reboot": {
"description": "Reboot the device"
}
},
]]
mk: there is no detail on how to
handle this yet
... it's a draft
dsr: good to have their proposal
mk: want to go through this
+1
mk: goes through 2.5-
... 3. Web Thing REST API
... defining resource type
scribe: example in JSON
mm: there is a "links"
section
... shouldn't be in the example
koster: design in progress
mk: individual URIs and fragments
to be concatenated
... 3.2 Property resource
http://iot.mozilla.org/wot/#property-resource
mk: doesn't really comply
seba: our approach is just using name-value pair
mk: would see RFC@@
... there are so many different IoT platforms
json interchange rfc
mk: we kind of got stuck with actions
mm: they have concrete idea
koster: expressing some intention
we should look at this
... to see what the main idea is
mm: scripting API
... you could expose different APIs
... and this could be a default API
... we already had discussion when we generated the Charter
mk: network API could be REST API
mm: not conflicting
mk: identify actions and retrieve them
mm: websocket is another option
mk: there is websocket proposal
as well
... goes down
... 3.4 Events resource
koster: our concept of "events" is a bit different
mk: 3.5 Things resource
... 3.6 Alternative Protocol Bindings
http://iot.mozilla.org/wot/#alternative-protocol-bindings
scribe: 4. Web Thing WebSocket API
http://iot.mozilla.org/wot/#web-thing-websocket-api
mk: easy coupling between the
server and the client
... need to talk about protocols for various vendors,
though
... how to open WebSocket, etc.
... establishing connection
... 4.2 setProperty message
http://iot.mozilla.org/wot/#setproperty-message
mk: here you have socket
connection
... and 4.3 requestAction message
http://iot.mozilla.org/wot/#requestaction-message
scribe: then 4.4 addEventSubscription
http://iot.mozilla.org/wot/#addeventsubscription-message
scribe: 4.7 event message
http://iot.mozilla.org/wot/#event-message
mk: equivalent to the REST
API
... wouldn't go deeper here
... 5. Web Thing Types
http://iot.mozilla.org/wot/#web-thing-types
mm: simple built-in vocabulary
mk: 5.4 Extensibility with JSON-LD
http://iot.mozilla.org/wot/#extensibility-with-json-ld
<dsr> Dave: we should also consider this from the perspective of what would be needed from a thing description to support the Mozilla IoT platform, given that the web of things needs to support a very broad range of IoT platforms
mm: having simple default Web
API
... mentions OCF approach
... RAML and Swagger
... Swagger more momentum these days
mk: RAML and Swagger are tightly
coupled to what the server is offering
... the key is loose-coupling
koster: big plus
mk: how should JSON serialization
should be?
... concise and developer friendly way
... so that we can convert it to another serialization
... we saw a parameter of "actions" here
... there are patterns of property, action and event
... may need some interaction pattern
dsr: we have metadata for
TD
... we have to live with driver model given existing various
devices
... simple interaction model
... TD just has minimal information for drivers
mk: you can't model that simple interaction model
lindsay: do you plan to enforce
some guideline?
... setting actions and write parameters, etc.
mk: there is a device with some
property
... the other thing has reset button, etc.
... think about interaction between them
... layering on top of discussion yesterday
victor: this is already
modeled
... e.g., for building automation services
... action on some property
... equivalent to changing property
mm: we need response from Mozilla
<mjkoster> victor: modeled in SAREF
mm: how to integrate with our document
mk: we have good questions about
this proposal
... it's a complicated theme
mm: having an analysis would be good
mk: we'll have activity on JSON
serialization
... and see gaps
... this is another IoT platform which we (WoT) would like to
describe
... any other opinions?
mm: the other possibility is
defining a simple default
... simple descriptive definition
mk: we won't create yet another
standard
... our description should be easily mapped
mm: there is a definition on
eventing
... could be a hybrid way
<dsr> mm: we should seek to make it really easy to provide a thing description for their platform.
kaz: this proposal is about interface between component, e.g., servient A and sevient B, with our context
mk: they don't have servient, so maybe gateway and client possibly
kaz: let's invite them to our telcos and TPAC f2f, etc.
<inserted> next
<inserted> mk: summarizes the discussion and defines the nest step
RESOLUTION: next step is (1) draft response
to them by Thursday, (2) get JSON serialization TF which
compare/integrate/extend Mozilla's proposal, (3) have a joint
call with them and (4) invite them to TPAC
... go through possible responses on Thursday and let's invite
them
[break]
dp: [TD Serialization
test-bed]
... on github:
github.com/w3c/wot-thing-description/tree/master/test-bed
... started to collect data from various sources: WoT CP
document, PlugFests, SDO mappings
... [Measurements Osaka PlugFest]
... shows graph including the data serialization variations:
JSON, CBOR, SMIL, EXI4JSON
... [Measurements Dusseldorf PlugFest]
... [Outlook]
... how can we improve even further?
... [Optimized JSON-LD Example]
... shows an example
(got a trouble with screen sharing...)
victor: devices are deployed somewhere not owned
carsten: shows his slides
<McCool> McCool: ways to reduce size: standard fields in fixed order; defaults; query parameters on API to get td (eg include semantic tagging only if asked)
carsten: [Objectives]
<McCool> McCool: regarding very small devices (eg SigFox) - might be best to return a simple identifier (eg a URL) rather than a TD; we want a TD to describe how to talk to small devices, but those devices don't necessarily need to generate or consume TDs themselves
carsten: represent TD
information
... what do we want optimize? - compactness/usefulness for
processing?
<McCool> McCool; BTW, defaults and multiple serializations also lead us to one possible way to align with the Mozilla/Evrything "prescriptive" network apis
carsten: what are our assumptions
about the devices - holding TDs?
... [Maximizing compactness]
... use traditional data compression
... e.g., deflate, LZ77
... need some memory for decompression
<McCool> McCool: eg one particular choice of serialization (and the defaults in that serialization...) could end up looking a lot like the Mozilla proposal... but still could be serialized in a more explicit, expanded serialization that make all the default values explicit could still be available.
carsten: [Choosing a
compressor]
... LZ77: sharing via <distance, length>
... need entropy encoder too
... classical algorithms: deflate (LZ77+Huffman), LZ4 (low
complexity)
... [Maximizing processability]
... [Experiment]
...
wot-thing-description/test-bed/data/plugfest/2017-05-osaka/MyLED_f.sonld
... JSON file: 3116
... JSON withoug whitespace: 1447
... deflate: 323, lz4: 415, lz4hc: 411
... CBOR: 1210
... deflate: 325, lz4: 416, lz4hc: 404
... CBOR packed (semantic sharing only): 793
... CBOR packd (prefix compression, too): 564
... 2 steps
... semantic sharin gonl vs prefix compression as well
... [Conclusion]
... packing (exploiting structural sharing)
... maintains processability, saves 1/3 (implementation not yet
complete)
... prefix sharing helps with URLs, another 20%
... but reduces processability
... could further improve by adding static dictionary?
... in the example: 119 bytes of mostly static data
... name, type, links, application/json, outputData, mediaType,
href, etc.
dp: ideas we can share
... get rid of static data
... different ways to achieve it
... questions?
mm: 3000 characters reduced
(Carsten goes back to [Experiment])
carsten: yes
mk: would go for easy processing, e.g., CBOR, EXI
seba: deflate-based compression
would be useless, I think
... quite heavy to install on small devices
... what can be the maximum compression ratio is not the best
question
... need some more clarification how it works
mk: TD includes set of property,
action, event
... same way of having a dictionary
dsr: could do compression on
Arduino, etc.
... but keeping battery down
dp: you need more memory for data
without compression
... processing may be ok
... on a powerful device, it's worth trying
mk: we have deep dive on JSON and
CBOR
... Mozilla proposal also mentioned JSON serialization
seba: what is the next step?
mk: we can collect examples
... people can present like Carsten too
... size of the representation, compression ratio,
ability/usefulness, etc.
dp: which data should be used as the basis?
dsr: have some material on GitHub
mm: can do the discussion offline
mk: let's put the items on a short list
zk: [WoT WG deliverables]
... normative specs: WoT Arch, TD, Scripting, Test cases
... [Implementation(s) as Deliverables]
... WG Charter says under "Success Criteria"
... requirement for implementation experience
... [W3C Software...]
... [node-wot]
... should node-wot be a WG oss implementation?
... if yes, need to apply W3C license
mk: we've been contacting eclipse
as well
... open source management in general
... possibly on eclipse foundation with W3C license
... we need 2 implementations anyway to make specs RECs
mm: do we need a
resolution?
... implementation deliverable
dsr: proposed resolution given not all of the participants are here
kaz: also suggested that to McCool
mk: do we need to update our Charter?
dsr: don't think so
kaz: agree
zk: also talked with Anssi about
this
... and the Chair can make decision
mm: the Chairs would recommend to make the wot-node implementation a deliverable of the WoT WG
dsr: [Developer Feedback]
... startups and SMEs
... [Current Practices]
... TD based on JSON-LD and JSON Schema
... some drawbacks
... [Mozilla Web Things]
... simple, obvious use of JSON for TD
... [My proposal]
... similar to Mozilla's proposal
... PoC server implemented with node.js
... tested against OCF, oneM2M, Echonet
... [Mapping JSON to Linked Data]
... property names treated as either predicates/names
... predicates mapped to RDF URIs via @context
... enumerations as JSON arrays
... short cut when you only need to state property type
... JSON object property reserved terms: types, properties,
actions, events
... names must not start with "@"
... (shows GitHub repo)
... w3c/wot/proposals/dsr-td/json-to-ld-dsr.md
... www.w3.org/WoT/demos/td2ttl
... would group's review
mk: this is an example serialization proposed by you
dsr: yes
... (shows jsonto-ld-dsr.md again)
... "properties" is metadata
... acceleration is a name
... shows spec on what I'm working on
mm: good to have multiple options
for serialization depending on the need
... could have a library for node.js
dsr: good idea
... so far quite flexible
seba: TD is generated
automatically by servient
... why do we need to think about non-semantic-based TD
serialization?
mk: we should think about
different serialization examples
... there are proposals for serialization
... actual data is semantic data
... we need tools for serialization
... essential building block is still TD
mm: agree we should handle core
TD model and serialization separately
... regarding another point that developers don't touch TD
seba: agree to need for easy structure for TD
mm: we need more concrete examples
mk: you have prototype
... some parts missing
dsr: idea here is extensible
support for Linked Data
... generic mechanism for mapping JSON to LD
mk: but seems like you're
reinventing JSON-LD...
... that is not good for WG discussion
dsr: the idea is that LD is
underlying data model
... simple JSON it's simpler than JSON as a possible
serialization
<mjkoster> matthias: how does protocol binding work with this?
victor: this is not 100%
corresponding to what we've been doing
... can try to link it to our spec?
dsr: depends on which predicate is used
victor: compatibility with our proposals so far?
mk: we have a problem
... this is a different proposal than Mozilla's proposal
... there is no connection at the moment
kaji: agree with Matthias
... as WG, we should fix the spec asap
... and as IG, this is a new input for v2
... so would ask Dave to split this proposal from WG work
... this should be an input for IG
... we should be careful how to handle this
lindsay: interested in the
problem space
... extensible exchange of metadata
... would be good to have a beauty contest (survey?)
mk: would wrap up
... we decide core model
... this is a model formally defined by semantic web
technology
... e.g., JSON-LD is already a standard
... we could do some beauty up things
... there is still constraints with JSON-LD of course
... there is no concrete specification on serialization
... as Kajimoto-san mentioned this could be an input for next
version
... concise serialization also possible
... let's continue the discussion tomorrow as well
kaz: purpose of this?
... who/how/where to use this?
dsr: consume thing and expose thin
kaz: e.g., between consume thing servient and expose thingg servient
[ lunch ]
<dsr> scribenick: dsr
Michael Koster presents some slides setting out the background to protocol binding
The protocol binding refers to the information needed for a driver for the chosen IoT platform/protoocol
Shows a JSON example with protocol binding within a “links” section
Introduction using OCF as an example platform
Michael shows how @type can be used in JSON-LD to identify the OCF type for each property
In addition, there are fields for href, content-format, method, resource type etc. as needed by OCF.
Michael displays a slide the depicts two ways to intergrate with OCF. One is where a WoT application acts as a client for a thing provided by an OCF device. Another is where a WoT application provides a thing that is exposed to clients as an OCF device.
In otherwords, both providing and consuming things using the OCF standards
Discovery: enabling apps to discover thing descriptions containing given semantic constraints
Discovery could be supported in terms of WoT thing descriptions as well as in terms of the OCF discovery protocols
Sebastian: are you assuming CBOR?
Michael: you could use CBOR, but this is not specific to CBOR
Matthias provides his personal summary
When mapping from the interaction by apps to the protocol level, the mapping depends on the protocol. This could be very simple for JSON based protocol payloads
Dave: where is the IoT platform identified?
I would expect a link to a platform identifier
Zkis: we have properties, actions and events for the interaction model, do you see a reason for exposing capabilities?
Matthias: I will let Michael respond to that one
The same capability could be exposed via different interaction models
Michael: we could refer to a shared vocabulary for the capabilities
It could be useful to include this directly
Dave: this is really part of the semantic models
Zoltan: do we need standard vocabularies for capabilities?
Matthias: this is something from groups that define domain specific vocabularies, and not something we will do in this group
Zoltan: an example is an on-off capability
Matthias: this could be used as part of a semantic query
Zoltan: how is this attached?
Matthis provides an explanation …
Darko: capabilities are essentially semantic annotations
<zkis> * DarkoAnicic please move closer to the mike
This is to be discussed
We need to look at how the annotation mechanisms
Dave: we need to distinguish interaction models and semantic models. The semantic models describe the capabilities and how a specific device implements these in its specific interaction model that may vary from one device to another
Not all apps will need the semantic models, so we shouldn’t require them to be included in the interaction model
Sebastian: such apps could ignore
the semantic annotations
... what is the status of the node-wot implementation in
respect to the OCF binding?
Kaz displays a slide by Kajimoto-san on a protocol binding building block
This has a protocol binding module that in turn binds to IoT platform specific modules.
Examples include oneM2M with JSON over HTTP, OCF with CBOR over CoAP, WoT with CBOR over CoAP, WoT with CBOR over HTTP, and WoT with JSON over HTTP.
Kajimoto-san describes his ideas for identifying the IoT platform, transport protocol, serialization format and security technology
He shows a slide with mapping from abstract operators to HTTP/CoAP Methods
Panasonic have been exploring some ideas for implementing this, along with the details for the thing description
Dave: the protocol and serialisation could be part of the platform identifier, and the operations could be implicit, resulting in considerable simplications in the thing description.
Matthias: yes, there is a choice
in how this is done
... there are many web platforms, where the transformations are
very simple
Michael_McCool: this could be a useful default, as a further means of simplifying the TD
Kajimoto-san: my approach is applicable to the Mozilla proposal
<inserted> kaz: right. that's why I also confirmed at the end of the morning session that Mozilla's proposal was about inter-component I/F
Sebastian: …
<kaz> scribenick: kaz
mm: [Outline]
... goal is working perfectly at TPAC
... [Goal]
... consume OCF metadata
... output a TD
... attempt *automatic* translation of metadata
... for better scalability
... [Prototypes]
... ocf-bridge, ocf-generator and ocf-client
... different project for ocf generator
... also testing
... issue on name collision
... [Architecture]
... issues come from multiple places
... need to extract OCF metadata from multiple sources
... integrate instance metadata, type metada and OCF standard
metadata
... how to get introspection
... which resource is actually useful?
... implicit in the spec
... most of them are currently encoded in my code
... some additinla hand-written metadata required per OCF
"resource type" still needed
... annotation metadata
... would make it (hand-written part) as small as
possible
... [Annotation Metadata]
... semantic tagging, which resourece types should be exposed?,
which combinations of interfaces make sense?, actions/events,
names and writable properties?
... [Annotation Example]
... currently doing some cheat and would like to gather
information automatically in the future
... a bit different from what Koster does
... protocolCOntent shows mapping between protocol and data
format
... [TD Example (one Interaction)]
... [Prototype Limitations]
... one complication
... extension mechanism of OCF
... doesn't handle multiple rt/if combinations
... including some unnecessary "OCF internal" resources in the
output
... [Issues]
... [TD Example (one Interaction) - revisit]
... offline device joins the network
... [Suggestions]
<dsr> OCF device identifiers are dynamically generated each time the device boots
mm: protocol binding templates as
strings
... separate template media type that can be converted to wire
media type
... alternatives: make template always be JSON, get rid o
template and make it equivalent to parameter map, e.g., make
generation of payload the full responsibility oof the
driver
... add additional "driver" parameter so that target device
ecosystem, e.g., OCF, can be identified
... [Next Steps]
... update to intercept protocol binding protocol
... implement protocol binding templates
... implement oocf-gather to ingest existing OCF type
metadata
... additional semantic annotation mechanisms
... pull request on node-wot
... try some other IoT standards
... [Conclusions]
... it's possible to do mapping automatically
... but OCF is relatively easy
... since webish
... need to repeat this exercise with additional standards
lindsay: would go back to some slide
mm: [Prototypes]
lindsay: have to have some software package?
mm: modular decision
... rather than implementing bridges
... you can use bridges
... consumes OCF TD
... generator is more online
<inserted> scribenick: dsr
Kaz: how to integrate this work with the plugfest?
Mm: ideally we would get this running with a variety of devices for the next plugfest
Matthias: we need to agree on the details for that
mm: more generally we need a translation, OCF is an easy case, so we need to look at a more challenging IoT platform
Matthias agrees
mm: we can say it is the driver’s responsibility to create the payload, so we can then drop the details in the protocol binding
Matthias describes how whether we use JSON or CBOR, we can keep the translation simple
mm: JSON over CBOR is straightforward, but for other cases the driver could transform from JSON to the on the wire format
mk: LwM2M is such an example
Dave: as we expand beyond REST, we will need a more general approach - an identifer for the platform and the associated metadata
mk: some of those platforms are migrating towards IP and REST
Sebastian: iot would be helpful to have a set of online devices that we can experiment with
mm: we can do that for OCF
using virtual devices.
Sebastian: we want this for a broad range of platforms
mm: if anyone wants to look at
code and has any questiions please contact me
... I am thinking now about other platforms
LwM2M is a good candidate as it also uses CoAP, as is oneM2M
<inserted> [ break ]
<kaz> scribenick: uday
Seba: Need standard way to deploy
IoT capabilities
... there is also an economic perspective to IoT
Marketplace
... describes the motivation and scope of IoT Marketplace
Philip: what other marketplaces out there?
Stefan: lots of marketplaces but none for IoT data
Matthias: should consider this while designing TD
Mccool: can distribute scripts,
thing and data
... Bid IoT mostly concentrates on data but can share other
oarameters to
parameters
stafan: cannot share code
Seba: need to setup a charter,
what to be in the charter, licensing info, pricing info
etc.,
... Describes the architecture
... marketplace to be aligned with WoT concepts, thing's
metadata ...
Dave: idea to allow people to design services and instantiate it with specific devices, discover and consume these services. Then what kind of APIs doe we need to support that?
Darko: Most will be covered with the idea of recipies
Lindsay: description of data in the project called "Inspire"
<dsr> I very much support starting work on this and will also do my best to channel the lessons learned on IoT marketplaces that we learned in the EU Compose project on highly scalable IoT cloud based platforms
Kajimoto-san: Marketplace is a good idea, can refer to advertisement technology
Seba: software not in scope. Idea is to have semantic description to setup and interact with a service
Mcool: to limit the scope, search which connects to linked data- discovery
Seba: Marketplace is just a href
Matthias: could use manager thing mechanism
<dsr> Dave: there is a business opportunity for installable services, e.g. to install them on a home hub, perhaps from the vendor’s websiite or in the case of native apps, from Google Play or the Apple app store etc.
<dsr> so I respectfully think it would be a mistake to preclude installable services
stefan: discovering things is linked to TD
Nimura-san: missing point would be related security. How do we deal with this and also the payment?
<mjkoster> sebastian: download a servient component in the process of receiving a service
<dsr> Sebastian: the metadata could list preconditions such as services or drivers that need to be installed. These could be referenced and hosted elsewhere
<McCool> McCool: I think that a marketplace that just includes existing services and data makes sense to START; but it naturally leads to installable services
Seba: consumer has always to request the thing to get the data
<McCool> however, there are some preconditions to installable services: a secure runtime implementation that can run untrusted third-party code
<McCool> accomplishing that will probably require some collaboration with eg. OpenFog, etc.
Seba: should be complete
independent of the protocol used
... who do we address: IoT Platforms, Cloud providers,
Infrastructure providers
Dave: also add search engine providers
Seba: is WoT the right place?
Mcool: falls in general category of discovery, so in scope
<dsr> Search engines will be interested in indexing services advertised via metadata on vendor’s websites
stefan: as long as open issues in TD it may be early, but if TD is done then this might be the right time
Matthias: might be implications on requirements, good startting point if Big IoT could share their findings
Stafan: decided not to limit to things, want to deal with data from many things
Seba: most of the content is the same as current TD
Matthias: good to have pointers form project working for the future
Seba: its a bit early now, might
meet after 6 months to move forward
... can invite e-commerce partner as well
<kaz> WoT Stack
Mcool: could a thing access interfaces of the device
Matthias: how to handle local
hardware is 1 year old discussion
... too big of a topic. Interaction to local hardware should
also go through the thing.
Mcool: should we define standard local things?
Dave: W3C has experience with APIs which can be used
Mcool: GPIO thing accessible to
the outside world is chaotic. Good to have it within the local
network
... Can I put in examples in node-wot folder?
Matthias: defining various API should be marked in a branch
<inserted> scribenick: dsr
Dave: we can provide some guidelines, but we can’t preclude IoT platforms from exposing their own APIs (e.g. Arduino modules) locally to application scripts.
<uday> Kaz need some help with scribing
Michael and Matthias discuss the idea of some standardised local things
<uday> thanks Dave, please add what you can!
Matthias: as Dave mentiioned we could consider adopting the browser APIs for local hardware and seeing what we can learn from their approach to security and privacy
<inserted> scribenick: kaz
Kajimoto-san: [WoT Model Description and APIs]
<inserted> scribenick: uday
Kajimoto-san: explains two API concept. one for physical world and one for cyber world
Mcool: treat both physical and cyber things same, so we can have a common API
<inserted> scribenick: dsr
mm: the conclusion from the Panasonic F2F was to use things and thing descriptions for both
<inserted> scribenick: uday
Dave: what about arduino, rasberri APIs
Mcool: can wrap them to have access to the hardware
Matthias: need the API available everywhere, gets hard with individual APIs
Mcool: we need to make a list of resources
<dsr> Dave: we need to clarify our messaging: things provide an elegant means to wrap access to local hardware, but platform specific APIs are also going to happen, and will require care with security
Matthias: more important to document the learnings
<dsr> Matthias: the thing approach offers greater portability
<kaz> [ Tech Day 1 ends]
<inserted> scribenick: kaz
elena: [WoT F2F Dusseldorf]
... Security Use Cases and Scenarios
<elena> https://github.com/ereshetova/wot/blob/master/security-privacy/SecurityScenarios.md
elena: shows MD page
... scenario 1 - Home environment
... user privacy is important
... what are the WoT security objectives?
... goes through the table of Threat name and Examples
... important to gather different use cases
... scenario 3 - Industrial/Critical infrastructure
environment
danbri: user privacy
elena: collecting first ideas so far
mm: general use cases on both
privacy and security
... medical is an important use case
... devices in hospitals communicate with each other
... and industrial
... 2 use cases
... full automation case
... and another case employees are included
... not sure about agreement between employees and employer
elena: medical use case require high privacy
mm: automation within industrial
environment
... 2 cases
... 1. not directly monitoring people, e.g., fully automated
factory
... 2. employee monitoring
mk: maybe more concentrate on
some core part?
... definition of privacy concern, etc.
... privacy and efficiency
danbri: small badge system?
(improving microphone setting...)
mm: repeats the industrial use case including 2 possible settings
mk: please don't combine the 2 use cases
mm: ok
... maybe can split out into 2 use cases
<dsr> Some differentiators: privacy when people are involved, safety when critical infrastrure is involved
<dsr> another is cost, e.g. when failure results in equipment damage and a cost to business
<dsr> smart cities may be interesting as it is a public environment with lots of people
mk: wondering about the goal and what to record here...
<dsr> mk: what is the goal for this exercise?
<dsr> scribenick: dsr
elena: the aim is to group security advice to make it easier for people to see what to apply
mk: it is worth looking at other IoT alliances and SDO’s to see how they are approaching this challenge
elena: sure, and we will want to see what security approaches are relevant to each layer in the comms architecture
mm: IIC is focusing on industrial use cases, as an example
the use cases are important as we are bridging different domains
mm: we may also want to consider mobile use cases
kaz: if the aim of this session is reporting the security TF's work to the group and getting feedback/advice from the group, maybe it would be more effective to do this in a break out session?
mm types in short descriptions of the broad kinds of use cases we should work on
Dave suggests adding law and order to the smart cities use case consideration
mm: also fire and emergency services
uday: we may want to consider coupling between use cases, e.g. smart homes and smart cities
mk: I like the idea of a decision tree as an outcome of ths study
elena: I agree
you usually extract the differentiators from the use cases
mm attempts to list some of the factors, e.g. different classes of people, whether the devices are personal or not, etc.
elena: we can think about what is the impact
mm: we can refer to existing materials, most of which are specific to a given domain
you might be unwilling to share information with insecure systems
danbri: devices in a home may be used to identify empty homes as targets for burglary
mm: personally identifiable information, e.g. for personal devices vs tracking people in a street in an anonymous approach
elena: confidential information may not be tied to people
mm asks elena if there are any standards we can refer to here?
the IIC security framework for instance, talks about several categories of risks
this could help us with scoping our discussion
kaz: maybe we need to look at both providers and consumers of services
mm: the flow of risk may be in the opposite direction
i.e. the risk could come from the consumer
zoltan: …
mm: fake data where false information is being propagated by an attacker
elena: that is a very different level of use case
Dave: fake data can compromise safety
mm: and physical security
... asks for a show of hands for people interested in brain
storming on use cases (Soumya and Dave raise their hands)
elena: we will continue with security tomorrow, right?
mk: Review of Existing/Proposed Security Architecture
elena: after that we will have a session on privacy
mm points to the security and privacy questionnaires that Elena has created.
<zkis> https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf
mm: this was inspired by IETF
work
... let’s give people a chance to review the email I just sent
on this
mm thanks Elena, who leaves …
<kaz> [break]
<inserted> McCool's Notes
<inserted> scribenick: kaz
mk: comment on next step for
security
... we ran into security discussion
... need to look at practical aspects
... let's clarify the next steps and roadmap
mm: think about relevant use
cases
... generate concrete document
... and think about APIs
... next step is working down use cases including
mitigation
... one category is existing mechanisms
... and then what kind of scripting API needed
... couple of recommendations for security APIs
mk: security vocabulary
... Panasonic was thinking about security for exposed
things
... let's see what is included in their implementations
... we also have some ideas
... then OCF as well
mm: next iteration of OCF binding
should include access control
... prioritized list of what to do
... third category is kind of bottom-up
mk: right progress with the Security TF so far?
mm: individuals are liaison
communities
... bubble up during the security tf calls
zkis: based on case by case
... in order to have security use cases
... should get members' input
... also OCF network
... deployment is out of Charter
... but we can describe requirements
... and have demo deployment
<zkis> proposal: WG and IG members should describe typical deployment scenarios
<zkis> we should solve security issues cases by case, for those deployment scenarios
<zkis> for instance, in OCF, a WoT bridge is needed that undergoes the OCF security provisioning
mk: would like to encourage people to think about how to transfer this
mm: making issues on GitHub
... discussion during the main call as well
mk: presentation by IETF
ACE
... Ari and Carsten
... OCF want to reuse IETF idea
<dsr> scribenick: dsr
<kaz> scribenick: kaz
nimura: review the discussion from the Osaka f2f
... [Conclusions and Proposals]
<kaz> https://www.w3.org/2017/05/wot-f2f/slides/Sync-WoT-Servient-170517.pdf
<kaz> https://github.com/w3c/wot-scripting-api/issues/28#issuecomment-308526421
<kaz> https://github.com/knimura/wot-scripting-api/blob/master/ReverseProxy.md
<inserted> scribenick: dsr
presented by Nimura-san
<kaz> nimura: discussion during the scripting calls
This relates to use cases for synchronising proxies, e.g. a proxy in the cloud for a thing behind a firewall
Nimura-san leads us through the reverse proxy use cases
This covers the use of a cache for operation when there are connectivity problems
This may involve republishing a thing description in the cloud when creating a cloud-based proxy for a thing hosted behind a firewall
<McCool> couple of questions - first, is the TD repo a Thing with a TD? second, what about security? Access to the proxy should require the same credentials as access to the device, and what about encrypted connections and/or payloads?
<McCool> also, can TD repo and/or TD recognize when something is a proxy for another thing?
Nimura-san: we will need to think about that
Michael_Koster: we should talk about the details of the design pattern
<McCool> koster is noting we are working on some related design patterns for links
and related work we’ve been doing
<McCool> I actually think "proxy" should be built into the scripting API so it can be done in a consistent way...
<McCool> perhaps with some controls, eg. to override or hide specific resources
mk: we could learn from the web architecture, e.g. the proxy looks like an origin server to the client
If a client (consumed thing) is not connected to the network, the state can be accessed from a cache
<mjkoster> zoltan: this is an application pattern
mm: should proxies be built into the architecture or treated as an add on - there is a case for the former to promote re-use
mk: I would advise against standardising this
mm: a library would promote consistency
<McCool> having a utility library at least would promote consistency
Zoltan: I agree with Matthias on this, but wonder about necessary network elements such as the TD Repository ...
<McCool> having standard proxies as services is similar to having particular system services... can be adopted or deployed if required...
mk talks about repositories …
<mkovatsc> +1 to Zoltan's comment over WebEx
<mjkoster> matthias: td repo and CoRE resource directory are similar patterns
mm: we could support this via open source implementations of the pattern
Nimura-san: this is an application layer, right (checking with Zoltan)
Zoltan: I am more interested in this kind of caching and synchronisation
mk: this is a good test of whether our scripting API is sufficient
mm: we should be documenting design patterns
perhaps on the wiki?
<McCool> where do we document these "design patterns"
mk: prefer to use the wot github repository
<McCool> matthias suggests putting in architecture repo
<McCool> kaz how does this relate to specification? appendix?
Kaz: I would like to find a way to publlish Nimura-san’s work
mk: perhaps as an appendix?
<McCool> matthias: should go into architecture document...
mk: my main point is that it is premature to decide where to put it
mm: we need to clearly mark it as informative
<McCool> early break for lunch...
<kaz> [ lunch ]
<kaz> Nimura-san's write-up
presented by Nimura-san
<scribe> scribenick: dsr
WoT ManagerThing as a thing for managing servients
Commands include script installation and uninstallation, script execution (start and stop).
A set of optional commands.
The ManagerThing can be used by clients to remotely manage the servient.
Nimura-san leads us through the document (see link above).
<McCool> Wondering: if device reboots, and is running a script, is it restarted automatically? In other words, how do the managerThing verbs map onto systemd-like installation semantics? (stop/start vs enable/disable).
<McCool> idea is that start (eg run) is only for the current instance of a running device, but "enable" implies it starts automatically at boot
Zoltan: why are you using CoAP for the manager thing?
Nimura-san: this is just an example
Zoltan: do we have any requirements, e.g. for the use of HTTPS or a standard port etc.?
mk: I don’t think we need to standardise the choice of a port or HTTPS etc.
We should advise the use of a secure connection though
Zoltan: do you want to standardise the manager thing?
mk: no, as there are many choices people could make, it would be good to establish the design pattern though
Zoltan: this is not only the application space as it also impacts the system space
mk: it is good to provide a design pattern, but other ideas may come along, so we shouldn’t be prescriptive here
mm: I want to +1 the idea of the example using a secure connection
we may want to discuss whether we want to recommend a port
mm: is running persistent across restart of a server machine?
Dave: we need to make this clear and to provide use cases to back this up
<McCool> to consider: should there be an "update" verb?
<McCool> so install creates a new thing, but update only works on existing things
<zkis> +1 for update command
Zoltan: we also need to consider the vocabulary implications
<zkis> We need help from the TD taskforce for defining vocabulary and TD for Script Management Thing
<McCool> also: decomissioning. I assume "uninstall" should also delete all data associate with the Thing instance
Sebastian: should we define a standard vocabulary for management actions etc.?
mk: we should defer standardising the vocabulary until there is plenty of experience
<McCool> another set of verbs: debugging...
Zoltan: I agree we should distinguish from the core TD vocabulary and we should continue our work on exploring the space of management services
mk: we should use these experiments to verify that the core vocabulary and APIs are adequate
mm: we may also want to work on exploring logging and debugging services
<uday> Should we couple manager thing with Discovery?
The manager thing is a back door and the security needs to be well thought through
mm: the question is whether we have a front door for debugging or some back end solution
the former would seem preferable
mm: I am raising this for future discussion
Zoltan: this is a separate functionality from the management services and we should open this as a separate github issue
<McCool> where should I post issues? Can create two: update; debugging
<McCool> should issues go here? https://github.com/w3c/wot-scripting-api/issues
Nimura-san talks about associating scripts with a handle for identification purposes
Zoltan: we need to experiment with how to identify scripts
mk: we could use URIs and look for inspiration from hypermedia controls
we could then define a REST API for alignment with how the Web works
Kaz: these mandatory and optional commands are for managing the state of the servient
we should clarify how the management vocabulary relates to the servient state
Darko: do we need metadata for scripts?
e.g. for versions of scripts
Zoltan: we could re-use ideas from the web app manifest for this
<zkis> https://github.com/w3c/wot-scripting-api/issues/29
Dave: do we want set some expectations for using a ManagerThing in the next plugfest?
<mjkoster> mkovatsc: HATEOAS pattern for script management
mk: I want to set out some ideas for hypermedia controls based approach
Sebastian: I would prefer to see further demos before we bring it to a plugfest
<mjkoster> zoltan: expose OCF resources in wot thing and add scripts
Zoltan: we could create a demo of dynamically installing and running scripts for some OCF devices
mm: this could be quite challenging, e.g. as it involves discovery, I would think that small technical demos would be fine.
<mjkoster> mkovatsc: sensor fusion like pattern
Zoltan: we can indeed do some demos but still have lots of things to work on
mk: we can use the main call to coordinate ideas and converge on a common understanding
<zkis> please add use cases to https://github.com/w3c/wot-scripting-api/issues/23
Michael_Koster: I don’t see a clear explanation of the script handle
We need a semantic explanation …
Zoltan: yes, this is work in progress
Nimura-san: how should we handle this topic going forward?
Sebastian: we need to gather idea for the TD vocabulary for managment services
Zoltan: we can use the scripting repo in the interim
mk: we need to make it easy for people to find this information
Kaz: may be a subdirectory?
mk: yes
Nimura-san: I will make pull request with the updates from today’s discussion
<Victor> http://w3c.github.io/wot/current-practices/wot-practices.html#type-system
<Victor> Dave's demo: https://www.w3.org/WoT/demos/td2ttl/
<Victor> data type comparison: https://github.com/vcharpenay/wot/blob/master/proposals/dsr-td/td-type-system-comparison.md
<kaz> scribenick: kaz
dsr: [Formal Basis as Linked
Data]
... where the type systems come from?
... properties, actions, events and metadata
... core types: boolean, number, integer, string,
enumeration
... compound types: can be nested
... object, collection (array), vector
... thing meaning URI to TD
... univons of types for flexibility
... basic constraints: ranges, patterns, readonly/writeable,
optional/required
mm: existing ontology on type systems
dsr: if there is something we can use
seb: something missing
... max/min
dsr: that's included in range
seb: schema or json.schema
<McCool> is there an existing ontology we can adopt; an example would be SCRO
<McCool> http://www.indiana.edu/~awny/index.php/research/ontologies/10-scro
<McCool> but dsr did make the point that we conversely don't want to adopt extra baggage (and SCRO has a lot...)
seb: maybe we could complete this list in accordance of those existing mechanism
dsr: number depends on platforms
mk: what is the goal and to
achieve?
... how to represent the type on the other side of the
system?
... most of them could be modeled by JSON types
<McCool> comment - we could define our own system, but still associate it with an external ontology, such as SCRO, for reference
mk: you could reshuffle this list
and make it in order
... could you see simplified types in JS?
... and see how to model this
... basically we want to use JS as the basis, why do you want
to consider types?
dsr: probably would better match with objects from OCF, etc.
mk: special kind of array?
dsr: typedef is common for
programming
... some of programming languages only have core types
mk: this would require something that JS doesn't have...
koster: not comfortable with these types
<soumya> +1 for koster's comment on vectors
<mjkoster> mkoster: seems like number types and structure types may need to be handled differently
<McCool> kaz: resolution of numbers important
koster: we should think about UC...
danbri: Google has started to
participate in WoT
... important area but way too much for W3C
dsr: we can incrementally work based on experiments
mm: how do we specify what the
data type system is?
... clear specification is needed
... we should narrow the focus based on our need
... we don't have to think about this until we have specific
use cases
... think we should see minimum set
<mjkoster> mkoster: structures are needed to describe payloads, value constraints are needed to describe instances of interactions
dsr: e.g., CSS, started with minimum set of features (and now has various features)
mk: this would help our discussion on scripting API but you don't have to jump into the details of extension of type set for JSON/JSON-LD
<mjkoster> mkovatsc: the type system is decoupled from the semantics and makes it hard to do some filters like units
taki: working on creating new
type systems would take much time
... would see if json.schema is really not enough
... choice could be better fit for union mechanism
vic: there is choice in
json.schema
... just saw examples from OCF. can show them.
<mjkoster> mkoster: "oneOf"
dsr: e.g., new features of CSS would allow you easier styling
<danbri> some related experiments from ericp at w3c: https://www.w3.org/WoT/demos/shrl/test.html http://tinyurl.com/y9fm2zsy http://tinyurl.com/yay2xzjd (using Shex over the RDF graph data model).
seba: why we need vectors, for example?
<McCool> sebastian: is there an example for vectors?
<McCool> McCool: RGBcolor uses a 3-tuple
<McCool> used in lighting, of course
<McCool> RGBled in our OCF demo used it
<McCool> of course we could also use an array, but it was also a specific length
<mjkoster> mkoster: a map is suitable for RGB or RGBW
<mjkoster> else you would need 2 types, etc...
<McCool> true, and basically that is how it is done in JSON
<McCool> and was done in the OCF example
mm: very complicated data
cases
... jpeg, png, etc.
... we should work case-driven
<mjkoster> jpeg and png are mediatypes
<mjkoster> not datatypes
<Zakim> kaz, you wanted to wonder if we want to make JS yet another mathematica
<inserted> kaz: do we really need to extend JS to make it yet another mathematica? we should clarify use cases based on plugfest demos, etc.
<McCool> what I meant, was that we should only define what we need for OUR scripting API, not for all possible scripting APIs
<Zakim> danbri, you wanted to ask if there is an explicit list of usecases for the type system (e.g. validation? codegen? ...)
<McCool> defining a mechanism for defining all possible scripting APIs is beyond the scope of this particular WG (not that it would not be useful, it just is not in scope here)
<McCool> let's just define our scripting API and introduce definitions only for the types we need
<mjkoster_> danbri: need to be explicit about what the type system is used for
mk: we should start with some
initial set
... not sure what the blocking point is
... from different data models
<mjkoster_> mkovatsc: define how data are presented to the application
mk: need schema information and semantic annotation
<mjkoster_> ...it seems like the json types are sufficient to get started and build upon
<mjkoster_> dsr: we gain convenience
<danbri> (for the notes - dsr responded to my request for usecases for the type system, by pointing to the introduction of https://github.com/w3c/wot/blob/master/proposals/dsr-td/td-draft-spec-dsr.md)
<danbri> ... including code generation (if I understand right), definitions for actions/events/properties, and also validation.
mk: seems to be too ambitious...
seb: would be helpful to show us why we need these additional types
<mjkoster_> sebastian: +1 what Matthias said, the json types seem sufficient
<danbri> Maybe these can be requirements and SHACL or SHEX can be taken as candidate ways of meeting those?
<mjkoster_> dsr: if we use low level constraints, there is a lot unspecified
<mjkoster_> dsr: numbers mean different things in differnent programming languages
<danbri> on screen: comparison of OWL and JSON Schema from (somewhere in https://github.com/w3c/wot/tree/master/proposals)
<mjkoster_> victor: presents json-schema vs. owl chart, including OCF resource type examples
https://github.com/vcharpenay/wot/blob/master/proposals/dsr-td/td-type-system-comparison.md
dape: you can reuse json.schema if it works
vic: schema.org also?
danbri: schema.org is declarative
not validator
... btw, how deep this group work on SHACL?
<mjkoster_> victor: it amy be difficult to map OCF using SHACL, for example
vic: need for concrete examples
of each feature
... your listed additional features of type systemss
... myself will continue this way of comprison (e.g., JSON vs
OWL)
mk: feel as if we were back to
Montreal...
... we looked at json schema, etc.
... could use metadata for modeling linked data with some
restriction
<McCool> time check... we are well into the break. Can we wrap up?
<mjkoster_> mkovatsc: mapping from json-schema types to linked data, with additional constraints added using linked data
<mjkoster_> danbri: look at what is done in json-schema and express in RDF rather than referencing json-schema directly
<danbri> danbri: "my advice would be not to normatively reference JSON Schema, but take its actual use for IoT as driving requirements for something similar but on top of the Linked Data (i.e. RDF) data model. I'd predict SHACL/Shex will be the main focus, but RDFS/OWL used for basic term declarations too."
[ break ]
<scribe> scribenick: McCool
victor: presenting what did for plugfest
wrapping SSN in things
use links to get values
or invoke actions
for now links are abstract
but we might (want to) make them more concrete
SSN/SOSA model
important classes are observable properties and feature of interest
sensors can make observations
observations are events where properties are associated with values
values are string, number, or more complex structure
made an alignment with our resource model
feature or interest -> Thing; observable -> Property; observation -> Event
but association is not exact
maybe we could use links to model the whole thing
SSN dataset usually has several observations
cannot have this in a TD; cannot have histories
servient can subscribe to an event to get a result, but cannot get previous events
so... what if we had a history, or previous, or client
also, uri templates
we haven't done anything with those
relation types that are already registered for CoAP, etc
already have some interesting semantics, such as collections
presented a TD eample with an SSN dataset
had mechanism to get latest, but also history
proposal: add a relation type to each link
so you can ask for the latest, or older observations using a timestamp
using relation type history
some alternatives here: queue like in the Mozilla proposal; or query to search over timestamps
matthias: rel is used for something else, doesn't think semantics
michael (k) may have some comments
dsr: can we connect to linked data model
victor: normally made links with URI templates
but may be tricky to do validation
but if use JSON-LD features...
either we have a predefined set of relation types are define as properties
validation may be hard
matthias: alt to rel property would be to have two related properties
victor: could distinguish links with different @type
questions about mapping
Darko: should both event and property be observable properties since they produce data?
victor: if you look at other systems, can have complex input data to queries
but did not think of this, should experiment in this direction
mk: been looking at a lot of use cases for linking
not even sure about rel
but if are using links only to point to endpoints, don't need rel
if want to build a td that points to other tds as an index, for instance, then we might want to use rel
it does things that attributes don't do
dsr: don't think we need this;
can use an API
... also think timestamps should come explictly as part of the
data
... no need to expose that as part of the TD
... did example with electrocardiogram data
victor: understand argument that we could have simpler solution
<mjkoster> (comment) We should not be too focused on this one use case for linking, and this one link term "rel"
matthias: going back to mk's comment
how rel was used in this example makes things more complicated
mk pointed out where it would make sense
where one thing is related to something else, eg composition
when we have to express HOW things are related
<mjkoster> mkovatsc: showing how things are related does make sense in some cases, but not this case
URI template should be considered in protocol bindings
<mjkoster> mkovatsc: should consider this mechanism also in the binding templates
McCool: looks similar to the issue we have with multiple if types eg in OCF bindings
would be nice to solve this and that the same way
<mjkoster> mccool: could use links to express/select query parameters at the protocol level
started with serialization
we have discussed compression using shared knowledge, we have an enhanced data set, and then we have the proposal from Mozilla
<soumya> Benjamin and I will participate in the future TD works regularly
seb: it would be very good to involve Ben from Mozilla in this discussion
Matthias: have drafted quick response to Mozilla, sent to team-wot for review
will invite him to give a presentation to group, probably in two weeks or four weeks
26 July or 9 Aug
we have discussed JSON serialization before; Mozilla proposal may bump up the priority
we have a baseline using JSON-LD that works for now though; but would be fine to look at additional serializations
<mjkoster> (comment) danbri may have some input to the JSON serialization question
iot.schema.org - next Plugfest would be interesting to actively use, but maybe not so easy
mk: no showstoppers, but there is work to do
need to arrange for access, and have some experimental vocabularies
next, we want to enhance the core vocabulary
need for instance we might want a "method" (POST, PUT, etc); may need URI template
<mjkoster> sebastian: protocol binding is priority 1
<mjkoster> ... semantic annotation is priority 2
who is on the team?
matthias: this IS a new TF, since it is associated with a deliverable
<mjkoster> mkovatsc: protocol binding is a new task force and a new deliverable
<soumya> I will join this as well
also uday
matthias: unfortunately, still in IG as a proposal
maybe can resolve with matthias making another proposal
then we can start populating the wg
next, managerthing
will have a deep discussion
will define a set of vocabularies to support it
then look at a set of examples, aim for some demos in the next f2f
show some managed things
next, data types
dave to provide some concrete use cases
then define mapping between linked data and JSON schema
use ShEx and/or SHACL for validation
victor: define mapping using OWL and JSON-Schema; equivalent
correction: ShEx and/or SHACL for validation; OWL and RDFS
matthias: have to avoid referencing JSON-Schema
instead we will model features using RDF so things are formally defined in an equivalent way
dsr: use cases from Echonet, oneM2M, etc. that can support each of these features
matthias: start with core definitions that come from JSON-Schema for instance; it would be good to establish that we CAN extend to more abstract types, but we may not use them right away
let's start with a core that we can use right away
dsr: worth having some plain prose descriptions
mccool: formal is normative, prose description to be informative
next, links
victor: proposal to use IANA rel for links
but, based on feedback, will look more at using this for relations
darko: this is a recipe idea (relations)
example, a group of lamps can be related to each other
or a room could be a collection of things
McCool: I think we need to do more work on events and actions
<mjkoster> mccool: example ROS functionality for long running actions, check status, cancel, etc.
matthias: we can treat the Mozilla proposal as a prescriptive proposal we can try to describe
mccool: we can look at other things as well, such as MQTT/ROS for events, and ROS for actins
mkoster: in proposals folder there is something for events
for events, who can work on it?
nakasan
mccool: my use case is ROS, which has both events and actions
kaz: example td, possible relation between manager things and action/event discussion
mkoster: simple actions are already there, just need more definition
move to adjourn...
<kaz> [ Tech Day 2 ends ]
<dsr> scribenick: dsr
mm: reads out Elena’s slide
There’s multiple places where security matters, internal and external
When we are using security mechanisms for particular protocols we need to reflect this in the thing description
For external security mechanisms, yesterday we decided to create a separate security github repository
<elena> guys the line has no audio
We need to work with external organisations to document their security mechanisms
mm: any volunteers …
... I can work with Zoltan and Elena for OCF.
Dave: any IETF experts?
mk: Panasonic could document what they’ve done with HTTPS
mm: we want to describe existing security mechanisms
<soumya> i can look at oneM2M
mk: Siemens can contribute, I can’t say exactly and need to talk with Oliver. It is likely to focus on IETF work
mm: We should review what the IETF recommend
Soumya: I can look at what oneM2M are doing on security and also OMA’s security for LwM2M
mm: for HTTPS, I also want to consider OAuth, and to see what Amazon IoT is doing.
Michael asks Elena for guidance
<inserted> Privacy questionnaire
Elena presents
mk: unique identifiers, e.g. for a device may be important for some use cases, but not for others
The challenge is how to restrict access to this
mk: so far we haven’t define any vocabulary terms for this. Panasonic’s work on lifecycle is relevant, but nothing is set in stone as yet
Sebastian: the JSON-LD @id feature is relevant
Dave thinks that the RDF node for a thing description for a specific instance of a device is such an identifier
mm: the issue is to whom the id’s are exposed
This gets us back to the question of whether you can control what you get back when requesting a thing description, e.g. based upon an authentication and access control mechanism
OCF has a device identifier (“di”). We can look at the OCF approach, and I believe that the device identifier is only available after you’ve being authenticated with the relevant credentials
Elena: you’re describing the OCF perspective, but we need to look at the WoT layer
mm: the OCF device id is freshly coined each time the device boots
mk: we want to provide core building
blocks, e.g. the life cycle management
... we have a tight schedule in our charter
so we can’t expect to solve everything in that time frame
Elena: we need to ensure that we (WoT WG) don’t make matters worse …
mm: we shouldn’t propagate publicly information that is supposed to be private, we need some privacy principles, we need to consider bridges and what information should/shouldn’t pass over it
mk summaries
<kaz> dsr: maybe we have to introduce mechanism to identify sessions
Dave: RDF relies of URIs for naming things for describing them and their relationships. This implies a degree of persistance. We should introduce the notion of session so that the descriptions are only valid for that session.
mk: RDF is about knowledge management, and typically for longer lived descriptions
We need a way to provide shorter lived information subject to access control
mm: IPSO have struggled with this, we could talk with them
Dave: we need to consider access control to RDF graphs and the life cycle for such graphs
mm: RDF id’s for people are privacy threating
Dave: only if shared, so we need to
deal with restricting sharing such ids
... this brings back to discovery and ensuring that the URI for a
thing description is only shared with entities that are authorised
to see it
mm: we could look at proxies with temporary ids (personae) with persistent ids hidden behind them
Victor: RDF blank nodes could be relevant as they are restricted to a given context
Elena: we need a small group of us to brainstorm on the principles
mm: any volunteers?
Michael McCool, Elena, Dave put themselves forward
<inserted> scribenick: kaz
kaz: wanted to mention 2 points
... 1. it seems to me that
there is a need to handle several levels of lifecycle, e.g.,
static/eternal lifecycle, hardware-dependent lifecycle,
software-dependent lifecycle, session-dependent lifecycle. so we
might want to think about those possible levels of lifecycle based
on concrete usecases from our plugfests/
... 2. there had been similar discussion on identification within
the Web&TV IG's GGIE TF, and now they're working with some IETF
group, so we might want to refer to their work as well
<inserted> scribenick: dsr
Taki-san: to whom you provide an id is a means to protect privacy
<victor> I can also participate in this discussion about IDs
mm: what over standards groups have Ids we need to consider, LwM2M. for instance
Michael_Koster: the IETF work on resource directories is relevant (CoAP)
<mjkoster> in IETF, it is the resource directory specification that describes the persistent endpoint identifier ("ep")
<mjkoster> This mechanism is reused by LWM2M
mk: we shouldn’t attempt to standardise identifiers, but rather to work with what vendors and SDOs already support
Elena reitterates the principle of being careful not to make thing worse
<mjkoster> The other identifiers in LWM2M, i.e. object IDs and resource IDs are just number codes for the same class ID as e.g. OCF resource types
Private information shouldn’t be made public, for instance
mm: the privacy work should be part of the IG
We need to work with existing approaches, and we can work on guidelines
<mjkoster> mccool: "privacy proxy" is an example pattern
mm: we need to explore use cases to mature our understanding
<inserted> [There is a question on use cases on the page 5 of the questionnaire.]
Elena: we need to provide clear guidance to implementers
mm: we need to consider what capabilities are required by legal constraints
This merits a further question for the questionnaire
mm: the EU GDPR is one thing we need to look at
Elena: this could be hard to answer in a questionnaire
Different countries’ law will vary considerably
mm: I care more about the implications of legal requirements on the technical requirements
Kaz: I was worrying about the regulations in different countries
mm: there is a lot of variation, so the challenge is to boil these down to a set of technical requirements, this may have already been done, so we should look for that
Kaz: I would suggest moving this use case question from page 5 to page 1
mm: we should make a stab at trying to answer the questionnaire ourselves
<kaz> [so far McCool, Elena, Dave, Victor, Kaz]
<kaz> [possibly start the initial call the week after, and will hold a doodle poll for that]
<inserted> -> @@@ McCool's note
<kaz> [ break ]
<elena> The privacy form is updated with the changes discussed
<kaz> scribenick: kaz
dsr: will talk about general
things
... Darko will give details on recipe
... [Benefits of Semantic Models]
... interaction models describe the properties, actions,
events
... interaction model provide what the property means
... semantic models describe the meaning and relationships between
things
... allows providers/consumers to agree on the meaning
... idscovery based on the purpose of things
... designing compositions of services with the confidence that
they will work as intended
... adapting the UI and service logic to deal with variations in
capabilities from one device vendor/sdo to another
... [Semantic Models]
... thing as an instance of the class of things
... things may be declared as instances of other more specific
kinds of things using rdf:type predicate (or subclass with
rdfs:subClassOf)
... for properties, actions and events
... number of possibility about the solutions
... there is a scaling issue
... OCF, oneM2M, Echonet (etc.) cover smart home area
... how to relate with different standards?
... [Bridging Communities]
... OCF ontology-bridging ontology-oneM2M ontology
mccool: might want to talk with Alan
from Qualcomm as well
... OCF looking at oneM2M as well
dsr: how about you, Soumya?
soumya: Yongjing would be the best
person
... can talk with Orange guys as well
mm: Alan is working on bridging between OCF and oneM2M
dsr: great
... [Exploring the Design Space]
... generated linked data interaction models for OCF and
oneM2M
... in the process of doing this for ECHONET
... plan to follow on with Bluetooth and LwM2M
... next step will be to craft the corresponding semantic models
for each IoT standard suite
mm: should consider not bridging between SDOs but bridging up to some standard/common concept
dsr: proposing we try some experimental work
kaz: we've been doing PlugFests as
interactive experiments
... so this sounds like an improvement of PlugFest and think about
how to connect/bridge some std-based device and another std-based
device
seb: seems good idea but think it's
very difficult
... we're working on TD ontology and we could upload information
there
dsr: bridging ontology would be
enough
... we don't have to standardize everything
<McCool> in fact, we just want to standardize the hooks to support semantic models, not (necessarily) (all) the semantic models themselves
darko: part of the LD TF work
... [Thing Description Recipes]
... problem statement: how to easily enable thing interactions,
thereby creating WoT applications?
... proposal: interop client creates a WoT application based on a
Recipe.
... discovery of Things is automated thanks to the semantic
specification of TD and the recipe
... recipe interactions are implemented with WoT API
... propose a recipe format base don TD and capabilities from
iot.schema
... [Current Situation: Discovery with TD Repository]
... 1. WoT Servient (on the left side) register/update/delete
TD
... 2. WoT Servient (on the right side)
search/querying/lookup
... 3. and gets TD/subset of TD content from the TD repo
... [Recipe Example 1]
... simple example
... turn a light on when motion is detected in a room
... recipe consists of ingredients and interactions
... e.g., MotionStatus Property - SUBSCRIBE MotionStatus
... could also graphically represent this
... Motion Sensor (including MotionStatus property)
<-status-> LightSwitch(including TurnOn Action/TurnOff
Action)
... Ingredients are TD Interaction patterns & iot.schema.org
capability
... Interactions implemented by Scripting API
... (shows some UI on this idea)
... (and TD example)
mm: you have multiple different roles
for an action
... success/failure kind of status
... multiple links linked to multiple roles
<mjkoster> ...could use multiple links in TD using link relations for which "role" e.g. invoke, cancel
darko: (shows TD example again)
... metadata kind of recipe here
... first Ingredient, second Ingredient
... motion detecting for turning on or off
... one more slide
... [Recipe Example II]
... search for a think on some repo or marketplace
... if there is not the expected Thing available, there is a recipe
(temp sensor, air temp controller)
<inserted> discover things that implement the recipe
darko: discover things that implement
that recipe
... temperature sensor TD, air temp controller TD
mm: recipe could be a hook
<mjkoster> ... the recipe could contain a hook to the application logic
darko: [Benefits of Recipes]
... recipes offer the following
... discovery of recipes for various applications
... easy implementation of applications with recipes
<McCool> to clarify: my thought is that the "process" part could be another component, referenced by URL, that implements the "algorithm" part of the recipe.. but the ingredients are found as described, separate from the process
darko: efficient discovery of things
required for recipe apps
... easy creation of recipes based on existing apps
... easy sharing of recipes on a marketplace/repository
... easy extensions of existing recipes on a
marketplace/repository
... Web links of an app in TD
... sematnic dosumentation easies maintenance of application
lifecycle
dsr: recipe is declarative
mechanism
... doesn't have to be a code
darko: maybe a good idea to build
procedural part on the top of recipe
... e.g., control the switch for lights
dsr: also security aspects
mm: how the actual processing
happens?
... linking to urls
... similar procedure like the one built in the recipe
... can imagine some simple tags
... nice to separate discovery from process
... don't have to install scripts
darko: interaction between ingredients
<Zakim> kaz, you wanted to mention the need for thinking about states corresponding to the ingredient and to ask about the relationship between recipe and management thing
[discussion based on "Current Situation: Discovery with TD Repository"]
kaz: given your clarification, I think the main purpose of this "recipe" proposal is providing syntactic sugar kind of help for developers so that developers can generate WoT apps easily. on the other hand, the capabilities mentioned here are quite related to ManagementThing, so I'd suggest you collaborate with TD guys (esp. ManagementThings guy).
dsr: trying discovery on the semantic layer would be complicated
<McCool> mccool: the way I see this: recipes are an application layer that uses wot. you find a recipe you want in a marketplace and want to instantiate it using your devices. One step of that is the discovery of local things that match the necessary ingredients for the recipe. but in addition to discovery of local services, you may also have to instantiate (a thing), install (a script), or find (eg on the cloud) processing services
dsr: and maybe should be done on the application layer
darko: how to know what devices are
online, etc.
... would be good to provide this kind of "recipe"
dsr: would continue the
discussion
... how to handle change of the things
mm: regarding collaboration
... what's the plan of the prototype?
darko: continue to work on open source
mm: on the thingweb
mk: we can have some more local chats before lunch (if you want)
[ lunch and chat ]
(naomi joins)
mk: generated some rough sketch
here
... landing page is the overall information
... it's a lot of work to maintain this
... (shows several examples)
... also updated the whitepaper page
... link for developers
dsr: should put as an agenda item for the Chairs meeting
koster: calendar!
mm: 2 large categories
... f2f meeting
... presentations
mk: so much to do
<naomi_> kaz: there is a specific calendar page
<naomi_> ... we might be able to pick up wot events to link here
mk: need for calendar: easy for
people to get information and easy maintenance
... and then Charter, ML, participants, join the group
dsr: maybe could start with some intermediate page
mk: would update step by step
... that is the starting point
... for www.w3.org/WoT
dsr: outreach point of view?
mk: we should make better
impression
... but don't have enough time for blogging
dape: thre should be something up-to-date
dsr: blog post is some story on each
event
... could add a link to the blog page
dape: missing community group
dsr: trying to reboot the CG
... need a link to the CG
mk: what's the status?
koster: IoT vocabulary?
... probably as related work?
mk: should clarify the purpose,
etc.
... we have too many MLs, etc.
dsr: could simply add a link
(some more discussion)
mk: would add icon for vocabulary work?
<naomi_> kaz: we need to specify what kind of page should be linked
<img>
mk: will update the initial draft pages
mm: [Messaging]
... [Key Message Components]
... [Existing Key Value Message]
... What is the WoT and What is its value?
... need to sharpen the Charter text up
... essential difference between WoT and OCF
... [Proposed Key Value Messages]
... longer version
... 1. The Web of Things extends Web technologies to the IoT. It
enhances interoperability by providing a standardized descripton of
IoT network interfaces so that everyone can use everything
easily.
dsr: how to fit people's business?
mm: related to the #3
... The Web of Things approach enables a larger ecosystem of
things. IoT devices can use Web of Things standardized descriptions
to adapt to and communicate with devices from multiple IoT
ecosystems
... #2
... These standardized descriptions are based on standard web
technologies in common use such as JSON. An extension point to
support W3C semantic technologies provides powerful tools for
semantic interoperability.
... avoid using tech term, "protocol binding", etc.
... #4. Horizontal building blocks that span ...
... [Proposed Differentiation Messages]
... How is the WoT different from otehr IoT standards?
<mjkoster> (comment) need to focus more on delivered value in the value points page
mm: powerful
... 1. The Web of Things describes how to interact with things. It
does not prescribe specific network interfaces for things. Because
it can describe how to interact with many different standards it
can be used as a basis for a common ecosystem of things without
mandating how those things operate or communicate.
... 2. The W3C standards process is open and royalty-free. W3C
standards can be used by anyone and all specifications are
public.
... 3, 4, ...
... [Planning]
... online presence
... other collateral
... presentation material
... images and diagrams
... datasheet/brocure
... webex
... white papers
... tutorials
... executive summary
... online demos
... books
... executive summary for business people
kaz: proposals for the landing page?
mm: mostly
koster: 2 things
... historical stuff
... best practice
mk: meaning current practice?
koster: no, what we have doing
mk: working group lists drafts
... IG also lists notes
mm: use cases are important
... references for security as well
... links as kind of footnotes
dsr: sometimes better to describe
keywords?
... should work with the BusDev Team
kaz: already working with the MarComm
Team
... and Coralie Mercier, the MarComm head agrees
mm: should have joint calls with
them
... maybe in 2 weeks or so
<scribe> ACTION: kaz to talk with MarComm/BusDev Teams about the expected joint calls [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action01]
<trackbot> Created ACTION-108 - Talk with marcomm/busdev teams about the expected joint calls [on Kazuyuki Ashimura - due 2017-07-20].
matsu: we had some missing functions
during the PlugFest on Monday...
... so would propose something
... [DONE until Dusseldorf meeting]
... [Next step of plugfest]
... consider more practical use cases for the next plugfest
... cooperation of two/more WoT Servients
... entegraton of scripting apps and WoT devices
... e.g., the diagram at "5.4.2 Smart home" from the Architecture
draft
... [Some requirements for the next step]
... how to exchange TD between WoT servients
... how to manage TD among WoT servients
... how to connect WoT servients via firewall
... how to manage data of the devices to cache on the
Internet/Cloud
... should refine the Architecture draft and make spec!
kaz: you want to define "WoT interface" as the inter-servient interface. right?
matsu: yes.
mm: next plugfest would include
bridge between wot and ocf
... and possibly use recipe for automatic bridging
kaz: what do you mean by "recipe"?
mm: some kind of additional semantics
mk: we can look into the "WoT
interface" here
... e.g., oneM2M ones
... and wondering if it's possible to have yet another servient
matsu: possible
mk: local servient's capability mirrored by firewall gateway
mm: have to sort out how it
works
... with untrusted network
mk: part of other proposal on
security mechanism
... in addition to that viewpoint, various interfaces to be
connected
... HTTPS can be something related to authentication
soumya: @@@
mk: specific scenario or technical scenario?
soumya: technical scenario
mk: everybody doesn't have to do
everything
... we can share
mm: consider expected technical
infrastructure
... cloud, local network, firewall, etc.
mk: can provide cloud side in Munich, etc.
matsu: [Overview of our demonstration
in Osaka]
... smarthouse demo
... in Kanazawa far from Osaka
... also Nagoya
... HTTPS is one of the possible secure connections
kaz: so you want to try some other security mechanisms?
mk: e.g., CoAPS
... and proxying
mm: patterns we discussed regarding
node-wot
... single servient as a proxy
... can take on and make it work
kaz: will generate a wiki for TPAC
f2f
... so please put your scenario on the wiki asap :)
mk: need to talk about the next
f2f
... will be held during TPAC
... update on the preparation?
kaz: to be confirmed
mk: need confirmation for
Sunday
... and Wednesday demo
(like we did in Lisbon)
soumya: what for Sunday?
mk: preparation for plugfest
... need more preparation for smooth plugfest
... maybe full weekend (=2 days)?
mm: happy with 2 days during
weekend
... we could split plugfest into 2 pieces
... demo and presentation
mk: we don't really have "openday"
during TPAC
... Wed is the plenary day
... with several breakouts
... last week we talked with the Eclipse Foundation
mm: do we want to talk with others, e.g., Amazon?
mk: maybe weekend or maybe
Wednesday
... Mon/Tue we have our meeting
... because some people need to leave on Wed
mm: maybe some others of us can make
presentation, etc.
... Amazon has a (separate) hackathon place (Amazon Lab26)
... maybe kind of open
... in downtown SF area
... great way to get an engaged venue for plugfest prep
mk: Koster, could you please reach out them?
kaz: please let me check within the W3C Team about that as well
[note: we mean Nov. 4-5 by "during weekend"]
mk: PlugFest possibly on Nov.
4-5
... and WoT demo on Wednesday
<scribe> ACTION: kaz to talk with mtgplanner about WoT demo on Wed, Nov. 8 [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action02]
<trackbot> Created ACTION-109 - Talk with mtgplanner about wot demo on wed, nov. 8 [on Kazuyuki Ashimura - due 2017-07-20].
koster: possible a WoT hackathon?
mk: maybe too ambitious
kaz: do we want to invite non-Members to this PlugFest during the weekend?
mk: that's my expectation
... then
... after TPAC
... collocated with the Security Conf
... Spring 2018, USA?
... we should outreach them
mm: IEEE conference may be more appropriate
mk: waiting until May for the IEEE
one?
... you can discuss this internally
... not sure about CfP about this one (IEEE)
... also collocating with IETF
... same week?
... goes through the lists
... USA in spring, China and Lyon?
... regarding the spring one, not sure about the logistics
mm: was thinking mainly about San
Jose
... maybe Qualcomm is active on the February one
mk: we're still quite flexible
... spring and summer
... collocation with related conferences would guarantee people for
longer stay
... possibility in Princeton?
dsr: maybe MIT in Boston
mm: OCF has no information yet (for summer)
mk: TPAC in Lyon, France in
Oct.
... would continue discussion on spring in US/summer in Asia
... WG roadmap
... this is the original one
... the red part is where we are
... Architecture is high priority
... we have nice picture on the building block
... Kaz's figure as well
... device directly vs on cloud
... also Matsukura-san's work
... design patterns on proxy, etc.
mm: we can split design pattern from the Architecture spec
mk: regarding security review
... the questionnaire is not really appropriate tool for "security
review"
mm: architecture definition is not
yet completed
... we have to move faster
... the questionnaire is rather information gathering
... limited scope for security review
... still gathering requirements
mk: and something after Dussedorf
kaz: wonders about the concrete
publication date for the deliverables
... we could publish the Architecture document as a FPWD shortly, for
example
mm: need to define the minimal requirements for security review here
mk: would ask all the Editors for opinions
kaz: could ask the security tf to review the documents as an initial review
mk: Zoltan is one of the key persons
for scripting
... Kajimoto-san, Nimura-san for Architecture?
... Koster for binding
dape: we should keep the exploratory parts as well
mk: need to distinguish them from stable parts
kaz: we can distinguish unstable parts using, e.g., "Editor's Note"
zkis: regarding scripting, please
right an email or issue
... and let myself, Johannes and Nimura-san know
mk: would like to talk with Editors
kaz: tx
mm: we need test suites as well
kaz: would be better to have a table of progress on our deliverables
<scribe> ACTION: kaz to generate table of deliverable status to manage the progress [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action03]
<trackbot> Created ACTION-110 - Generate table of deliverable status to manage the progress [on Kazuyuki Ashimura - due 2017-07-20].
<scribe> ACTION: kaz to generate a doodle for the Chairs/Editors call to see the updated publication plan [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action04]
<trackbot> Created ACTION-111 - Generate a doodle for the chairs/editors call to see the updated publication plan [on Kazuyuki Ashimura - due 2017-07-20].
<scribe> ACTION: kaz to create a GitHub repo for the Security TF [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action05]
<trackbot> Created ACTION-112 - Create a github repo for the security tf [on Kazuyuki Ashimura - due 2017-07-20].
[break]
mk: possibility in Asia at Keio or Beihang
<scribe> ACTION: kaz to ask Keio and Beihang about possible WoT meeting in Asia in spring or summer [recorded in http://www.w3.org/2017/07/13-wot-minutes.html#action06]
<trackbot> Created ACTION-113 - Ask keio and beihang about possible wot meeting in asia in spring or summer [on Kazuyuki Ashimura - due 2017-07-20].
mk: we have so many calls
... (shows slides)
... [Binding Templates TF]
mm: OCF Liaison TF might be able to shutdown at the moment given we're doing discussion on binding
mk: WG (delivery deadline 2018)
... vocabulary proposals for TD TF (under "link")
... targets: HTTP, CoAP, OCF, oneM2M
... [Scripting API TF]
... [Security TF]
... have to change some hybrid approach, top-down and
bottom-up
... for security review
mm: review Editor's drafts
... creating a new GH repo for the TF
... security sections for other deliverables
... need coordination
mk: is that all?
dsr: semantic part of the LD TF would
go for part of TD
... there is an overlap
mk: let's do a doodle for the binding
template tf call
... TD TF
... WG: TD core model and JSON-LD serialization
... IG (validation): JSON serialization
... Binding Templates TF
... default interactions
mm: secure connection, e.g., HTTPS, CoAPS
mk: IG (validation): WebSockets
... IG (explorative): MQTT
... Panasonic is using WebSocket for event handling
... what's the difference with Mozilla's proposal?
... (WebSockets goes to WG)
... OMA LwM2M goes to IG (validation)
... SSE added to IG (explorative)
(discussion on how to deal with ECHONET, BACnet, etc.)
(binding template implementations)
mk: have an implementation in node-wot
mm: mentions web storage kind of mechanism
mk: have local communication in
node-wot
... local communication added to IG (explorative)
... check with Web APIs
... Scripting API TF
zk: we made a decision for a device
expose capability as service rather than api
... WG: scriptin gAPI, servient architecture
dsr: semantic annotation
mk: how semantic annotation would
appear within scripting api
... (adds "support for semantic annotations and other TD
customization")
... [LD and Semantics TF]
... (asks Zoltan to review the Scripting API part)
zk: ok
mk: [Security TF]
... WG: review all the Editor's drafts
mm: who is in charge of which?
... can we securely connected with WoT?
[ network disconnected ]
[ some more discussion based on Matthias's slides ]
Note:
At the end of the meeting, Matsukura-san suggested the following regarding the Architecture work:
- We publish the Archtecture document as the initial draft asap.
- We reboot the Architecture TF and start detailed discussion on inter-servient interface and its security.
- We update the Architecture draft based on the feedback of that discussion.
- If it's OK, Matsukura-san is happy to join the Architecture TF to make contribution.
And Matthias updates his slides based on that suggestion.
See Matthias's slides for the record.
[ Dusseldorf F2F adjourned ]