Second W3C Workshop on the Web of Things
The Open Web to Challenge IoT Fragmentation

Day 1: Tuesday, June 4

<inserted> scribenick: taki1

Welcome and Scene Setting

Sebastian: I also say to hello to everyone.
... I would like to intriduce Michael Lagally.
... we have two chairs.

Lagally: I am very pleased to be here.
... I worked on Architecture, TD, etc. Joined over a year ago.
... we want to discuss next step, gather new ideas.
... Kaz wored really hard.

Kaz: I am the team contact for WoT WG.
... Thank you very much for coming.

Lagally: welcome Matthias Kovasch.
... Welcome Michael McCool.
... Welcome Zontan.
... Welcome Michael Koster.

Sebastian: you are aware that they are main players.
... I give you some thoughts.
... who joined the first workshop?
... it appears half of the audience joined
... it was 4-5 years ago.
... it was a great event.
... we reached the first milestone.
... this workshop should create new roadmaps.

lagally explains the timeline slide...

Lagally: there are two groups.
... IG and WG.
... we had a demo session. there is demo next room today too.
... working group is working on specifications.
... now we are here in 2nd workshop.
... to get things compiled, how TD can be useful in new scenarios.
... and define charter for the next 2 years.
... we are planning new task forces depending on new ideas.

Kaz explains workshop statistics.

Kaz: Participants, open day 140, workshop 61
... organizations 60 adn 46.
... new comers 25 and 14.
... new comers are very important.

Sebastian talk about logistics...

<rzr> http://irc.w3.org/?channels=#wotws is the right link

<rzr> not w3c.org

Lagally is talking about agenda...

Lagally: morning, welcome session. briefing from Jeff.
... then usecases deployments.
... and tooling and implementations.
... afternoon contines, coffee break. then security and provacy.
... wrapup at the end of the day.
... seond day. keynote speech from Mr. Chinn Hwa Lim
... Future work, collaboration with SDO in afternoon.
... next step and wrap up at the end of 2nd day again.

Sebastian: social event tonight.
... we can go to beer garden.
... it is *not* sponsored.
... Where we go, I will let you know later.
... thank you again. yesterday was great, and let's continue.

Jeff: Good morning.
... thank you Sebastian.
... WoT made progress.
... yesterday was a celebration.
... congratulations.
... today is about doing some hard work.
... to figure out what to do next.
... please take agenda seriously.
... learn from each other.
... what are most important for us to work next.
... and learn what people are doing.
... including liaisons with IoT-oriented organzations.
... thank you.

Matthias: thank you

Matthias explains what WoT has achieved...

Matthias: there were many IoT eco-systems.
... unfortunately there were IoT silos.
... could not interoperate even when they used the same protocols.
... WoT enables applications.
... by simplifying integration.
... there was internet, and applications on top. This is analogy. WWW did good job to interconnect applications.
... IoT is in similar situation.
... IP is common, but on top IP, IoT eco-systems are different.
... We wanted to use Web technology.
... we defined building blocks.
... to interconnect silos.
... Web Thing has interaction model with narrow waist model.
... Thing description is the centerpiece.
... scripting api is working note.
... we should gather more experiences.
... security concerns. security and privacy guidance for secure WoT.
... This is high overview.

Lagally talks about WoT architecture...

Lagally: cloud service can be a Thing.
... edge can be a Thing. mobile devices can be a Thing.
... Things can be used/exposed,
... Zigbee, etc. many protocols can be used.
... appliances, fridges, lamps. industry devices.
... virtual device can be a Thing.
... as long as it can be described by TD.
... There is Interaction affordances. properties, actions and events.
... event notifies events.
... Hypermedia control. Can relate things by links.
... forms can describe how to submit requests to Things.
... architecture consists of several building blocks.
... TD contains information model, vocabulary, JSON-LD representation.
... Binding Templates is for integrating various protocols.
... Scripting API. ECMAScript-based API
... security and privacy guidelines. cross-cutting security guidelines.

Lagally explains what is TD...

Lagally explains what is protocol bindings are...

Lagally talks on communcations model between Thing and Consumer...

Lagally: TD is the lingua franca.

Lagally talks on indirect communications through intermediary...

Lagally: typically it is a proxy. home network has firewall.
... servient in the middle can also aggregate many things.
... architecture itself is flexible.

Sebastian introduces Thing Description...

Sebastian talk on motivation behind TD...

Sebastian: automation devices are often accompanied with paper documentation.
... you have webpage manual.
... and also code-snippets.
... what is the name, URI? Functionality, what kind of data? Engineers need to know.
... protocols, serialization, security requirements... Engineers need to know.
... TD should provide those information.
... People start with landing HTML page and can interact with Web application.
... TD is the same for WoT.
... TD can describe many kinds of devices.
... TD is based on JSON, consistent with JSON-LD.
... TD spec defines very small set of terms.
... title, id, created time, and other metadata.
... TD contains security schemes.
... TD has property, action and events.
... TD has datatype system borrowed from JSON-LD.
... TD provides context extension.
... If you want, you can add additional term definitons such as iot.schema.org.
... This is a powerful constructs, and allows to use existing knowledge.
... TD allows use of links.
... This was TD internal.

Question: addition of context, isn't it metadata?

Matthias: whole TD is metadata.

Question: you can plugin additioal semantics.

Sebastian: Yes, exactly.
... e.g. industry-specific terms.

McCool: we use extension for protocol binding as well.

Question: agreement is necessary for semantics.

Sebastian: Yes.

Joshue modular accessibility semantics, for example.

McCool: we should incubate semantic modules.
... for now core vocabulary is very slim.

Matthias: bottom-up semantics and top-level semantics.

Sebastian continues on explaining protocol binding...

Sebastian: we are open to using other protocols.
... context extention can play a role here as well for changing parameters of protocols.
... It was a brief introduction to TD.

Zoltan starts introducing Scripting API...

Zoltan: the work started in IG.
... in Working group, used GitHub to develop working group Note.
... it is API for node.js. Not really for browser. This is an issue.
... Web has scripting API. It is easy to use for everyone.
... half of all web develpers develops JavaScript programs.
... webpage, URL, HTML. Thing, URI, WoT Scripts. there are analogies.

Zoltan explains Scripting API's role in architecture.

Zoltan: Scripting API is for describing behaviours.
... scripts can run on cloud, gateway or on devices.

Zoltan explains three approaches....

Zoltan: no exposed API, simple API (e.g. Dave Ragget's proposal) and current API.
... current API follows TD specification closely.
... we will discuss more tomorrow.
... I also like simple API as well.
... Ege tried other languages.
... we documented everything.

Jeff: is it a matter of fashion? plus and minuses. what is the fasion? how do you decide what is best?

Zoltan: we listen to people.

Matthias: people prefer different approaches depending on who you ask.

Jeff: we can describe which community should use which styles.

Matthias: some people also say they do not need scripting API, some others suggest simplification.

Zoltan: you need to be aware of other languages.
... time will tell.

Kaz: possible impact on e.g. NHK broadcasting company. They used updated scripting.
... we also need to talk with those industry guys.

McCool talk on security and provacy guidelines...

McCool: WoT is descriptive. we are not defining new security mechanism.
... each document has security and privacy section.
... TD spec has one section as well.
... we created security and provacy guideline document.
... there is also security testing plan document.
... best guideline is evolving.
... we need to constantly update this separate guideline document.
... TD can describe insecure devices as well.

Kathy: security is out of band of TD.
... secure-wiress connection, for example.
... therefore, very confusing.

McCool: We call it security schemes. TD is about describing how to access a Thing.
... to help developers.

Kathy: why we need it?

McCool: We had discussion.

Kathy: security is somewhere else.

McCool: TD should describe some information.

Lagally: we have dedicated security discussion. FYI.

Matthias: we aee also following IETF work.

Lagally explains subsequent agendas.

Lagally: Please observe time.
... we are 37 minutes late.

Dominique Guinard's presentation.

Dom: web of all other things. CPG, apparel, etc.
... I write "building the web of things".
... IoT came from researcher presentation at P&G .
... company connects billion things.
... majority is everyday thing. CPG goods, bluetooth devices, etc.
... every thing can have digital identity.
... the other end there is enterprise.
... in apparel, counterfits are problems.
... samsung worked on washing machine that understands what it is washing.
... there are now smart closet, etc.
... transportation. what tracks are carrying.
... Amazon Go need to understand everything in store.
... it requires standardization.
... our company undersands needs for standardizing CPG, Apparel, Pharma.
... GS1 well known for barcodes.
... Digital Link and EPCIS. Web identity and tracking. those two standards are important.
... GS1 Digital Link standard. I chair this group.
... fastest standard in GS1 ever.
... it gives identity to everything.
... can fetch information from URI.
... Coca Cola produces billions of items a year. it was not possible a couple of years.
... Now technologies changed to make it possible.
... transform dumb number into URL.
... NFC tag, for example. can carry URI.
... user resolver delivers web content for digital links.

Dom shows WOMI as GS1 DIgital link.

Dom: is it for salmon.
... QRCode structure. base url, product category, GTON, batch number...
... If you click, it shows salmon information. where it was born, it was put into sea, how it was harvested.
... nice story about salmon.
... this was just an example.
... There are open source tools.
... next one is EPCIS 2.0 for making track and trace first class citizen of the Web.
... EPCIS 1.0 exists already.
... 2.0 is moving information system into the Web.
... movement of goods cab be described.
... 1.1 was based on SoAP.
... 2.0 is REST and JSON-LD.

Dom shows an example of EPCIS...

Dom: Back to W3C WoT building bridges.
... Building bridges for all the things!
... use cases to merge the two world.
... we can print sensors. it is happening.
... questions?

McCool: privacy concerns?

Dom: One million dollar question.
... same as smart things.
... we need framework in place.

McCool: QRCode and smart things are different in nature.

Dom: QRCode does not cause problem unless it becomes active.
... we are working on it.

Victor: content negotiation. is it machine-readable from the URI?

Dom: Yes. JSON-LD.
... You can also use link-type. two formats are mandatory. JSON and JSON-LD.

Victor: Bottle interact with other smart thing. How is it so?

Dom: pack of straeberry and the track. the temperature need to be set accordingly.

Zoltan: trucks have energy source.

Dom: exactly.
... Tag can be destroyed at checkout.

Question: bluetooth can do what extra?

Dom: not really.

Jeff: Did you use TD?

Dom: I have not. But it is the intention.

Question: How can we pilot?

<inserted> scribenick: taki

Kathy: SmartThing already does that.

Dom: we are waiting for WoT Recommendation ratification.

<inserted> scribenick: taki2

Dom: tag printing pricing is shrinking.
... NFC 5 cents tag. UHF tag 1 cent. bluetooth tag is a bit expensive.

Zoltan: NFC readers are expensive.

Dom: Every phone has one.

Lagally: Thank you.

Johannes Hund's presentation on EV charging

Johannes: I was active in this group.
... Now working in EcoG
... FTP, NNTP... survival of fittest.
... Java Applets are extinct.
... mail is now read and write in web mailer.
... Occam's razor of green field IT
... web front end, API is REST api. This is how people do now.
... IIoT space. Web is pushed by people in this room.
... domain of silos. OPC-UA. Bacnet, ...
... vendor platform silos. gRPC, AWS IoT...
... EV charging domain: OCPP
... current version 1.6 switched to JSON over websocket.
... monitor and controls charging station.
... extension can be used.
... there are many parties involved.
... multi-stake holders
... field charging HW manufacturer automotive, site owner, utility...
... Highly complex game. Charing car use more electricity than a home.
... there are fleets of buses for example.
... web enables multi-stake holder system.
... promises of web.
... seamless IT integration. single signon.
... integration of payment, calendar, maps ...
... field-level integration into web is necessary.
... parking sensors. cashier, the vehicle's IVI requires that.
... web-ecosystem. 75% of all developers are web developers.
... you want to tap into those developers.
... long-tail market. Web was about niches that everyone can come up with.
... that makes break-through happen.
... WoT and IIoT. cross-domain integration crossing boundaries.
... aonyone use React.js. we have react-wot implementation.
... including scripting API.
... Thank you.

Zoltan: TD. WHo writes it?

Johannes: REST API, WoT runtime. Mobilephone uses bluetooth LE. Binding should be simple.
... It should be an effort of an hour.

Zoltan: do you plan to publish TD?

Johannes: sometimes we use internal API. other time we use public API.

Alan_B: transportation workshop. transportation and WoT. I encourage to submit position pater.

Alan: will be in September.

McCool: different of WoT vs openapi.

Johannes: we do not have TD yet.
... I currently use swagger. WoT is similar.
... establising pattern is special in WoT.

Milan: why you need new OS?

Johannes: it is more about software for charging.
... powerline communcation, charging station safety-oriented protocols, every vehicles are different.
... our model is software as service.

Lagally: thank you.

Kathy: I will make demo after Ben's presentation.

Ben: I and Kathy are from Mozilla.
... we are NPO.
... we are working on emerging technologies including IoT.
... and WoT implementation.

Ben shows mizilla IoT team...

Ben: WebThings is an open source.
... there are gateway and framework.
... there are smart home use cases...
... different vendors, different proticols.

Ben shows gateway architecture...

Ben: front-end, back-end and adapters.
... TLS tunneling service.
... We have pre-built images for gateways.

Ben shows gateway UI...

Ben: there us a rule engine.
... it can show logs.
... experimental voice feature.
... there is add-on for browsers.
... 30K downloads so far.
... goal is to put directly into routers.

Ben shows framework example...

Ben: challenges.
... HTTPs in local networks.
... self-signed certificate is not secure.
... there are workarounds but not ideal solution.
... W3C group HTTP on local network is working on this.
... Chalkenge 2 is HTTP on resource constrained devices.
... use of gateway. websocket is still heavyweight. CoAP is not native supported by browsers.
... challenge 3. autentication.
... it relies on gateway.
... challenge 4. Scripting API.
... client side mimned mainly at Java Script.
... framework implement different APIs fpr each languages.
... challenge 5. declarative protocol bindings.
... in practice, WoT protocol binding is not felxible enough.
... but making TD more complex is not good.
... we recommend to use gateway.
... we provide Web Thing Description, REST API, Websocket API. Those three documents.
... We propose to simplify TD spec, and create Thing protocol spec for each binding.

Ben suggests charter proposal...

Ben: TD spec should be usable without need for binding template.
... add protocol binding as another deliverable.

McCool: What should be included?

Ben: REST API should be separate.

Sebastian: TD supports the use of RDF definition of HTTP.
... you are expecting the same for other protocols.
... they should be done in same way as HTTP.

Ben: REST support was not flexible enough in our experiment.

Sebastian: multiple resouce. what is it?

Ben: action queue. action resource, and delete or cancel it.
... there is no way defined right now.

Kathy: desk in mountain view.
... turn on kitchen.
... you can see them turned on.

Kathy is demonstrating Mozilla WebOfThing.

Kathy: there are add-ons.
... I have a light, door-sensor, open weather map.

Kathy shows log information...

Kathy: that was my demo.

Johannes: collections are not expressable right now. we can publish a note. We can dicuss what are missing.

Ben: need for describing existing protocols. TD gets more complex.
... we should come up with compromise.

Jeff: we cannot reach a conclusion today. we need to dicuss charter with chairs.

Matthias: we skipped some features to see convergence.
... HATEOAS for example.
... we needed to publish core standard first.
... I hope we can settle the differences.

Ben: We tried to bridge real devices but it did not work. what is why we are making this proposal.

Lagally: ready for coffee break?
... if you have requirements, please put them together and submit.

McCool: we can incubate in IG.
... compromise can be the use of defaults to bridge the gap in two approaches.

<kaz> [break till 12:25]

<zkis> scribenick: zkis

Realizing "Lifestyle Update" through WoT

Panasonic home IoT: connected, SW defined, upgradeable.

Intend to support already connected devices in WoT abstract architecture.

Using a local/home gateway to support existing devices.

Panasonic presented a demo with a Smart home room, virtual things (simulator), a WoT client in a browser and a WoT client on Node-RED.

Panasonic exposed APIs based on WoT interaction model

One such application is HomeX which leverage Panasonic "touchpoints" in the home (all things controllable).

Showing a concept video, presenting use cases, e.g. assisted laundry program, notifying about favorite TV programs + switching on TV, multi-room music playback with user presence sensing, tips about food preparation.

Expectations on standardization: align with existing standards as much as possible, using WoT interaction model. For APIs we need domain specific vocabularies.

Some of them are covered (home appliances), others are not (audio-visual, outside home, etc).

Questions.

Question about the own API vs TD + bindings. Answer: open API and TD are complementing each other.

Question: the Panasonic API was presented, in previous presentation a REST API was mentioned; what is the similarity? Answer: yes, it's a RESTful API.

Abstracting and Interacting with Vehicles in the Web of Things (BMW)

The demo yesterday was a BMW i3 connected to the cloud with a WoT connector.

Goals: abstracting vehicles, semantic annotaions on parts, interact with the many automotive domains, etc.

Today there are a lot of solutions, fragmentation is a problem.

Requirements: be able to deal with safety, complexity, legacy.

Presenting the WoT ontology used.

Data model to represent Vehicle Signal Specification (VSS) by Genivi consortium working together with W3C Automotive WG.

Semantic Sensor Network ontology, SOSA pattern / to model what is a car signal. For instance SOSA Sensor, ObservableSignal, ObservableProperty etc.

SOSA provides the classes, VSS ontology provides the signals.

A vehicle is a Thing. Signals are Properties. Actuable signals are Actions. DataSchema uses the domain Units.

SOSA does not support events, so WoT Events are not supported ATM.

Event modeling pattern is mapped to Event Ontology.

Presenting demos about TD.

Demo architecture: using the vehicle web API backend, created a TD, exposed as Thing, made simple demo Node-RED flows.

Example: when the user moved far enough from the unlocked vehicle, the lock is activated.

Lessons learned: safety-security-privacy adapted to the vehicle. Complexity needs breaking down into subdomains (each with separate TDs instead of one huge TD) with separate security aspects.

For instance infotainment, engine, HVAC, etc.

Different experts can work on each part.

All parts might have their own security scheme.

Questions.

Question: are there open issues with the security schemes described in WoT?

Answer: yes, found that out late, so you can define different schemes and then use it. But in this case splitting up the TDs makes more sense.

Question: TD for each car manufacturer; how do car manufacturers benefit from doing that?

Answer: there is no common data model or API. VSS is one solution. In the end, open specifications would help. They should agree in a core set of interactions in all APIs.

Question: what the level of maturity there is about the vehicle description (which is proprietary ATM)

Answer: it's quite early now, VSS is about 2 years now, divinding into domains is an old idea, but using the WoT TD is a relatively new thing.

Question: BMW, JLR, VW are in the same room here - encouraging there. Answer: the need is seen in the industry, pushing for WoT.

Question: on the main alignment pattern slide, what was the "mental state". Answer: stress level, mental load while driving.

a WoT Gateway with device virtualization (Fujitsu)

Usually applications integrate devices one by one, each with separate interface. A gateway provides one integrated interface to applications.

A gateway encapsulates complexity and provides adaptors for each device type.

The integrated interface can be done using WoT interactions.

Protocol bindings can be used for the adaptors.

Also, a special adapter can be used by the protocol bindings.

Based on adapters, virtual devices can be created out of physical devices.

It might employ TD conversion, protocol convertion, device management.

All this is part of an Adapter runtime.

A tree of gateways could be deployed, where the root works as directory for devices and adapters

A large scal system requires multiple multi-layered gateways deployment

Experiment: 1400 devices connected in 3 fields, a) smart home, b) smart factory, c) smart agriculture.

Application handles all fields, based on cloud gateway.

Toward zero configuration: this integration enables building the system with zero configuration.

Describing Legacy Data in Thing Descriptions (Fujitsu)

WoT allows a common glue between IoT platforms, instead of bridging each platform to each other platform.

Will concentrate on the data format. JSON and CBOR are accepted, but what about others?

When a Thing is WoT compliant, the client can get the TD and interact right away.

However, with legacy devices, this is not possible.

This is similar experience to web browsers being the entry point to access served content of various types.

Most of available data is in CSV format. TD supports CSV natively.

Proposes native type annotation for CSV

The second example is TLV (type-length-value) data format.

TLV, notably ASN.1 is used everywhere. TD should natively support ASN.1

Call for TD being more versatile.

Questions.

Thomas: there is already work on CSV-JSON conversion. Answer: that is one way to do it.

Question: now we use JSON Schema, which is not a full standard now, we could extend it, so what is the minimal delta that is needed

Kathy: we came across the same problems and solved with adapters as well.

Ari: this is a broad problem that is looked upon elsewhere too, so we should work on this together.

Lunch break.

<kaz> [till 14:40]

<soumya> scribenick: soumya

Research and survey of use case for wot

Tomoaki: presenting customers use cases

Tomoaki: showing the motivation behind the talk. it is important to note how customers use such technologies

Tomoaki: there is a need for research on use cases, need to consider both manufacturer and customer perspectives

Tomoaki: showing some details of the attitude survey of IoT from Japan

Tomoaki: result is interesting, about 66% has heard of IoT but only 60% of the respondants can explain IoT.

Tomoaki: JP Govt. has plans to use IoT from 2020

Tomoaki: shows a more detailed survey for IoT appliances in bedroom, living room, entrance etc.

Tomoaki: shows some conclusions for results of survey

Tomoaki: concludes his lightening talk.

Tomoaki: it is necessary to help the customer to bridge the gap between understanding and use of IoT

sebastian opens floor to question.

Sebastian: ponders on the importance for users to know about IoT

Tomoaki: customers should know what is IoT and that might have influence on buying IoT products, services.

moving to next speaker

MIoT Platform

[MIoT Platform] targeted for connecting people and home

[MIoT Platform] statistics about their platform

[MIoT Platform] smarphone & smart speaker centric functions

[MIoT Platform] timeline with different connectivity modules

[MIoT Platform] provides rich sdks - RTOS, Android, Linux and many coonective solutions

[MIoT Platform] provides multiple access or control of iot devices

[MIoT Platform] shows the smart voice control - device status, device control, continuos update etc

[MIoT Platform] provides rich trigger conditions like human body sensor, light sensor, water sensor etc

[MIoT Platform] 1.98 Million users have over 5 iot devices

[MIoT Platform] works with traditional BlueTooth solution

[MIoT Platform] creating a BlueTooth Mesh as well

[MIoT Platform] shows an example of BLE-Wi-Fi mesh

[MIoT Platform] mentions that whole platform capability is open to share

[MIoT Platform] shows an architecture of the platform

[MIoT Platform] is built using layered model

[MIoT Platform] shows its functional model for smart home application profile

[MIoT Platform] is operational with gateway and cloud-only scenarios

[MIoT Platform] works with other vendors (CLoud to CLoud, module level integration..)

[MIoT Platform] concludes the talk

[MIoT Platform] resembles WoT deployment scenario 6

[MIoT Platform] using own standards, yet to be there

Virtual-Thing: TD based Virtualization

Jeff - asks about interoperability

Hassib: introducing their work

Hassib: lists problems - no easy way to simulate a thing based on its TD, hard to test a mashup with physical access to the devices, rynning tests might overwhelm iot devices

Hassib: solution is to simulate a thing based only on its TD

Hassib: it uses original TD and node-wot servient

Hassib: virtual thing is available in npm repository and is easy to start

Hassib: as a future work, create a digital twin

Hassib: digital twin acts as a reverse proxy

Hassib: showing some limitations (some are inherited from node-wot)

Hassib: concludes his talk

question - is it a standalone module?

Hassib: it is an npm package and open source

Matthias: nice tooling, will be valuable in future. what is the meaning behind digital twin here.

Hassib: not defining what is a digital twin, in this context, the digital twin is like a reverse proxy not just a digital representation.

Klotz: are you working with other partners?

Hassib: outlines his motivation and describes his intention to look into partnerships

Taki: usage of virtual thing in test purpose (comment)

WoT Store

Luca: wot store is a generic software platform for the management of W3C-compliant things and applications of the WoT SECO

Luca: wot store has a modular architecture with things manager, applications manager, data manager

Luca: things manager performs things discovery, TD etc

Luca: there is a web & CLI for this

Luca: provided in github

Luca: application manager allows sharing, update, visualization etc

Luca: application manager performs semantic discovery of applications as well.

Luca: data manager is doing data filtering, flow aggregation, plotting

Luca: market service - it is a rest api

Luca: implementation benefits from node.js ecosystem

Luca: use cases - industry 4.0 (update all, data analysis), home automation (new thing integration, UI, mashup application), smart agriculture (update all, data analytsis)

Luca: future works on control access mechanism, digital twin.

lucus - dependencies like if some applications depends on properties of other thing applications?

Luca: code and libraries can be used and system will download and install them

zoltan - what is an application in the talk?

Luca: Thing application is same as Thing behavior (properties, events, actions).

Zoltan: it might lead to confusion

Rapid IoT App Development

Kunihiko: talking about node red based development

Kunihiko: current issues include many barriers like ambigious documentation, limited capability of some SDKs

Kunihiko: wot TD can be used as open specification in this context

Kunihiko: node red is widely used for its intuitive aspect

Kunihiko: combined node red with wot which results into a tool called node generator

<kaz> scribenick: ege

<kaz> (ege takes notes locally for a while)

Siemens: Security from Oliver Pfaff

lifecycle of a thing, bootstrapping of security

# Common Practices
... Security should be easy and secure
... Not done:
... Site -> Trust the device,
... Device -> Know the site = not done yet and difficult
... Relevant initiatives:
... * Anima: have manufacturer install a service on site that does the authentication for the device when the device is installed
... # Questions

Ari: Recommending IETF group on this

Lagally: Companies working on this?

McCool: How to trust the service as the site owner?

Matthias: The service can change owner, doesn't have to be the manufacturer.

Web of Twins from Philippe Coval

Philippe:
... # What is Digital Twins (DTs)?
... Connectivity between real device and digital representation
... DTs are model driven
... Privacy by design
... IoT.js is a language for the emb. devices
... # Robot arm
... We can think what a robot can be and program a DT
... Video on Youtube: Using the DT on a VR glass in order to control a real device in the end
... Architecture overview for the Robot arm but any other thing in general
... # Color Sensor
... Reading the color of an object and changing the DT color on webthing
... # Summary
... We can create DTs using js and displaying them on browser for different devices

<kaz> (ege starts taking notes online)

<rzr> https://www.youtube.com/watch?v=sUayRsjV1Ys

<rzr> https://github.com/rzr/twins source code of robot twins if anyone want to test them

<akeranen> Securing TD delivery was out of charter but something that could be worked on next. Standardization on security and provisioning would be helpful to users. DNS-SD, CoRE Resource Directory, etc relevant here. In IIC whole group on trustworthiness of IoT.

Discovery: mozilla: mdns where you publish the URI of the TD to the network

Accesibility: How devices can accomodate the needs of the users, depending on the user

a lot of people seem to be motivated about accesibility, lots of hands raised

Matthias: verifiable claims can be a building block
... thing directory is an item in the working group
... should we start it now or get fb and do it a bit later

Hassib: what about a google search for wot?
... global search

Matthias: before there was also directories for web, no search
... ietf is doing that, through core link format
... local search doesn't make too much sense

Hassib: but what about IP cameras or weather data providing sensors

McCool: mdns is sort of obsolete
... how to discover a directory, bootstrapping a system

Sebastian: there was already discussions on that

Matthias: I had called it a rat hole

(audience giggles)

Sebastian: one topic is then certainly discovery then

Matthias: gs1 standard have new patterns that we should explore
... eventing is still not (clear)
... multiplexing multiple interactions into a single connection

Sebastian: considering passive things

McCool: new metadata?

ben francis: schema.org?

McCool: what schema then?
... who is interested in scripting
... standardizing it

Matthias: what about more complex interactions
... I believe that web has solutions for it

Jeff: not to add these directly
... what is in the edge of what we are doing but not in the spec yet
... the collection of things we are putting together, can they be done in a timeframe that fits the market needs

Kaz: I put a long list of possible topics

Johannes: how to do onboarding, helping on how to choose solutions/technologies

Ari: join forces (ietf and w3c) since this is a common problem

Dom: all the pieces are here but "how do you put them together"

McCool: it is not just putting up a website

Dom: it has to come from the community
... we needed collections, we had to add it ourselves

Ben: onboarding new members -> making the group more approachable

Sebastian: how to trust the td

Day 2: Wednesday, June 5

<kawaguch> scribenick: kawaguch

Agenda Overview of Day 2

Lagally: We have keynote from singapore government
... in the morning we have Extension for WoT Standardization
... in the afternoon we have Future Work / Collaboration with other SDOs

Kaz: In the last we have another wrap up session.
... gather input to possible work items
... and incorporating to new charter

Sebastian: Please send your presentation to organizers if note yet sent

Keynote: Standardization Needs for the Smart City

Chinn: Introduce Singapore smart city
... Have many awareness from worldwide.
... Started Smart Nation in May 1st, 2017
... 5 ministery oversees the project
... Singapore digitalisation started in 1980
... GovTech evolution such as Citizen centric, common platform, etc.
... We have 3 plans to drive smart nation forward.
... Smart Nation covers areas such as Digital identity, E-Payments, Sensor Platform, Smart Urban Mobility, Moments of Life and so on
... Elevator changed real estate business. Likewise, autonomous vehicle changes what city looks like.
... Singapore is tiny, 740 km2
... Sensor Characteristics
... Smart lancos
... You have passive and active sensors.
... SNSP layers
... Sensors & IOT --> Decada (device management and data acquisition) -> SDX (Sensor data exchange)
... SDX -> Sensor-surround
... We have whole govenment connectivity.
... Potential Threats to Platform
... Backdoor, malware comes from open source.
... We need to put in place robust opensource environment.
... Then run devops.
... IoT Data
... We need standards.
... We can deploy from country perspective.
... We can ask very specific questions.
... WoT brings what can we do with data.
... Platform approach.
... We believe in API economy.
... Privacy is one of concern.
... If you have a passport government has information.
... If you travel the data is collected.
... (video: Robot testing at Takenaka Corp. construction site)
... How do you keep the data fresh?
... The robot can move to construction site, take photos of there.
... We also deploy autonomous underwater vehicles.
... ERP2
... Congestion is biggest problem in the city.
... Give car owners smartphone equivalent devices.
... If you are contributing to traffic needs to pay.
... Information is pushed to drivers.
... We also have BUS on demand.
... It's autonomous bus without driver.
... I'll explain Pungol digital district.
... University in a residential area.
... It's already started construction.
... train station connected to the area.
... traffic goes under ground.
... delivery is done by robotics.
... We already have national digital identity.
... We have security based on biometrics.
... Intended to be showcase of smart nation vision.
... Use cases include identify and access management, autonomous, footfall
... Architecture includes Open Digital Platform.
... We intend to connect every physical things to digital.
... Thing Description can describe such things.
... Certainly standards need to exists.
... Can WoT standards and implementation make iot data more secure and interoperable?
...

Lagally: question: are you working for simulation model such as digital twin?

Chinn: yes, building information model, infrastructure model, using BIM, Geospacial info
... We have smart glass for AR, for representation.
... idea is to model bunch of environment.

Lagally: is there any plan to apply the experience other than singapore?

Chinn: Yes, we are part of ASEAN Smart city network.
... Encouraging to share use cases.
... Also with Japan, Australia and Thailand.

McCool: How did you wrap all the requirements?

Chinn: We are open to anyone for ideas.
... We prepare multi billion dollar budget.
... We want innovators talk to us what is the idea and how can we fund them.
... Sandbox is prepared for them.
... Plan is before 2023.

Jose: What is related to open source and open api?

Chinn: We use lot of open sources and contribute back.
... Because lot of ideas can be shared.
... We believe API economy drives lot of business.
... Quality of life of citizens changes.

Alan: Interoperability of data issue?

Chinn: yes, it's issue.
... Data is extremely critical and interoperability is important.

Cathy: Privacy invocation?

Chinn: There is a dedicated team who work for privacy of citizens.
... We give the connectivity between government and citizens.
... There is already connection between government and citizens.
... Bus on demand rather than bus on schedule.

Zoltan: Metadata get out of sync.

Chinn: Disaster recovery question.
... We have robustness with back ups.
... For the data we have thousands of people working on this.
... If WoT becomes global how would you want make contribution?
... Also you can bring user requirement systems.

Session 4: Extension for WoT Standardization / Semantics / Linked Data

Scripting API for the Web of Things

Zoltan: Diving into small segments.
... Scripting is a routing to Web.
... It describes behavior of a thing and controls thing interaction.
... If you have a scripting runtime there is security consideration.
... How do you run those scripts?
... Can there be one of more scripts?
... Can there be more stakeholders in one place?
... I took some of notions regarding security from there and still applies.
... Alternative to scripting is native implementation.
... You can also have visual rules like Mozilla or flows like node-red.
... Benefits of scripting APIs.
... It makes Web of Things modular.
... It simplifies application developments.
... Reuse business logic again.
... Opportunity for scripting is in the cloud.
... It can be run in the Web browser client.
... Or sensor or sensor hub in the gateway.\
... One deployment has 60 kilo bytes of codes.
... Security talks.
... The point is when you have a isolated context you can represent multiple things.
... WoT runtime provides OS functionality through the APIs and it has security configuration.
... It can be a virtual machine, docker container or javascript runtime.
... It has functionality load as cript, reload a script and so on.
... Script execution context.
... There is also Special things in WoT Stack, such as Script Manager Thing, System Access Things.
... About standardization process
... latest working draft released on 2018/11/29
... Current API uses promises as a callback.
... We have reference implementation Node-WoT.
... Approaches to the Scripting API
... Choice: No externally exposed API, Simple API, Current API based on TD spec.
... difference between simple and current is interaction name is explicit.
... one thing simple API cannot do is readmultiple properties.
... The spec has discovery, expose thing and consume thing.
... Overview of API specification.
... You can introspec things based on thing description
... You have two kinds of observing.
... Obverve property and subscribe event.
... We have an example of ConsumedThing.
... We also have an example of ExposedThing.
... (showing examples)
... We also have discovery API.
... Node-WoT is an implementation.

Ben: Standalone module for client and server, client side can be reference parser.

Zoltan: You can find two packages in Node-WoT.

McCool: (sorry couldn't capture)

Josh: How things state can be captured and fed in the interfaces on the fly?

Zoltan: You can have instance object and can be live object.
... include event in the thing, subscribe to event.

Schema.org extensions for IoT

Aparna: IoT schema is an extension of schema.org
... To enable description of physical things.
... It is a community process for domain experts.
... Normalize device definitions from OCF, oneM2M
... Reuse property and relation types from SSN, SOSA, SAREF, QUDT.
... Annotate Thing Description for domain specific vocabulary.
... It is for different IoT Actors.
... Device vendors can use iotschema to describe platforms.
... iotschema Semantic Definitions.
... Capability, Interaction, Data Item
... Feature Of Interest Pattern.
... Conceptual integration with other ontologies.
... Example.
... Capability Door Lock is associated with Thing Door
... How to use?
... Main focus is to annotate Thing Description.
... Thing can be described as capability.
... Interactions are annotated with interaction pattern.
... Data Schema can be annotated.
... At the iotschema.org page you can find example.
... Capability example: TemperatureSensing
... Corresponding interaction pattern is Temperature
... Corresponding Data Schema is TemperatureData
... Thing Description Example.
... This is a TD of Temperature Sensor

McCool: for clarity "unit" is not a TD built in vocabrary.

Aparna: iotschema.org is a domain specific for Thing Description.
... iotschema Node-RED
... you can use multiple semantic configuration nodes.
... Status
... Please provide feedback through GitHub

Milan: Question: You should separate event/action/property from semantics.
... example temperature has minimum and maximum values.
... My suggestion is to separate those two.
... What makes the feature of interest?

Aparna: It is important to know what is the feature measured by the sensor.
... capability is temperature itself and FOI is outside temperature.

Victor: Now there is overlap b/w TD ontology and iotschema.
... I see the another term in TD ontology.

McCool: We cannot change terms.

Victor: We should sit together again.

??: What is the process submitting domain specific schema?

Aparna: We have an intermediate schema

Sebastian: We need some clear guideline.

??: How to process really done how to select from different ontologies?

Aparna: We try to normalize it.
... It is done by manually.

Jose: Challenge is using existing ontology how to properly annotate TDs.

Aparna: Sometime it is difficult. It is exactly iotschema want to address.
... We want to provide tools like Node-RED.

Standard Behavior Descriptions for the Web of Things

<kaz> scribenick: taki

Victor: presentation is about "behaviour" building block of WoT
... objective is scale up WoT applications.
... challenge is scaling up to more than 1000 devices in a building for example.
... describing behavioural agents is important
... three ways to implement thermostat
... monitor and control sensor and furnice
... there are two more implementation cases
... differences are where scripts are run.
... use case is IIoT. want to reuse software module as much as possible.
... scalability is for deployment. deployment automation requires software modularization.
... kuberneti and dockers, for example.
... or redeploy applications.
... deployment-specific part should be parameterized.
... input requirements can be TD templates or shapes or frames
... contextualization. semantic relation between Things. this should be specified.
... Input ca be TD frame with no forms.
... contexextualization. furnace and sensor must be in the same rooom.
... relationship can be speficied using JSON-LD frame

<taki1> scribenick: taki2

<taki1> Victor: there are existing tools. Node-Red and Eclipse 4diac (IEC 61499)

Victor: behaviour description languages. should be process-oriented.
... it can also be numeric.
... or rule-based & knowledgement-based
... lastly it can use statistic approach.
... all approaches can be subsumed turing machine.
... exchanging scripts have not relly been tried.
... we need to focus on usability of ECMAscript
... We should not compete with Node-RED
... instead we should complement it.
... node-red's capability to exchange flow is not perfect.
... I would like to propose WoT WG to work on exchanging and packaging WoT scripts.
... we need to integrate JSON-LD framews into WoT Scripting API

Victor cites Jeff Atword's saying "Any application that can be written in JavaScript..."

Victor: Thank you

Zoltan: I have some idea about this already.
... This is one way forward I can work on.
... Hhat would be your approach.

Victor: We just need ECMAScript.

Zoltan: should be part of runtime?

Victor: yes.
... management system using a Thing Directory.

Ben: a bit skeptical about standardizing this.
... packaging format in another WG did not succeed.
... what is the need for standard?

Victor: standard about addons. there is a de-facto standard in browsers.
... what I propose is similar
... docker container is another de-facto standard.
... There should be a specification.
... I am not very ambitious.
... we need a way to describe semantics for scripts.

Ege: example slide shows message flow, can be used to create JavaScript?

Victor: sequence diagram still s missing conditions.

Ege: scripts should not do what is not expected.

Victor: diagrams can be generated from scripting API.

Zoltan: are you looking for execution environments such as container?

Victor: yes

Sebastian: should not we relate this work with iotschema capability?

Victor: I am more interested in client side.

Kaz: we should first discuss use cases.

Sebastian: it is now photo session.
... please come back in 15 minutes.

<taki> Sebastian: lunch is 1pm

<kaz> scribenick: McCool

Towards Semantic Interoperability in WoT Ecosystems - Andrea Cimmino, María Poveda-Villalón and Raúl García-Castro (Universidad Politécnica de Madrid)

ontology overview

developed ontology for WoT

vicinity core, vicinity adapters

adapters used to access and translate data

store tds in a description repository

along with additional metadata and mappings

then implemented discovery services

discovery uses sparql queries to filter results

some queries don't need to access the data, just TDs

but queries can also access actual data from payloads

if endpoints don't have RDF, can use mappings to translate into RDF and enter into database

vicinity is an EU project, also now working a project called Delta which is about energy

summary, provides discovery and distributed access

also can specify various privacy policies

use WoT and WoT-mappings

also core and saref

interop is not only about describing, also discovery and access

question: approach is that all use same information and data model?

answer: yes, but if need to use several ontologies can use query rewriting

question: what about privacy wrt what data can be seen?

answer: use access controls to limit what can be discovered
... run policy at client level
... clients says what things are available to who

Zoltan: but clients are not good enforcement points

answer: can also use a centralized approach

Zoltan: so have to distribute policies as well as data?

mccool (comment, not asked): equivalent to multiple databases, not sure it would scale to many different kinds of users or complex access

Linked Data in the Web of Things - Gerald Haesendonck, Anastasia Dimou, Ruben Verborgh and Ben De Meester (Ghent University)

gerald: speaker

in order for a switch to control a lamp, needs to read a TD, so it knows how to act on a lamp

but... state and semantic description are two things

need concise data represenation

have limited processing power on the things

what if the data model changes? how do we process offline data? how do we combine states?

may need to keep TDs, many need to describe relationships between things

so can consider a linked data version of the state

so if data model changes, then reflected in the state

historical data would still refer to the old data schema

and the data contains links to things or other linked data sets

how to do this?

we have some software, RML streamer, that reads state and converts it to RDF

by combining it with information from the TD, i.e. semantic annotation and data schema

could also add additional semantics using manual rules

RML is the "RDF Mapping Language"

then the resulting linked data can be used by applications able to process linked data

can add a form to the original TD as well to define how linked data can be accessed

see https://github.com/RMLio/RMLStreamer

question (matthias): how much complexity is there in RML?

scribe: may want to store only those parts that are relevant?
... in many settings there is a datalake, and the metadata is out-of-band
... what is the benefit of doing things this way?

answer: benefits are that it is rule-based

Matthias: it seems to need a rule-based system; but TD is already modular, do you really need the rules?

answer: but if you store this data, and need to pick the parts you need
... preconverting the data to RDF before storing ensure that the semantics valid when the data was stored is captured
... this makes it easier to process historical data
... if the TDs or data schema changes

question (victor): reusability. Do you have a collection of rules for well-known schemas?

answer: do we have rules available; yes, for a few cases
... for data formats that is the main applications of RML to do this conversion
... and we have a lot of examples available

Victor: how do I find the right examples?
... is it based on the context type, etc?

answer: not indexed, but would be interesting to integrate with a discovery service

Increase WoT impact using transferable validation - Ben De Meester, Gerald Haesendonck, Ruben Verborgh and Anastasia Dimou (Ghent University)

speaker: same

validation for WoT; consider a TD data schema

can validate the payload or the state

but can also include semantic annotations and linked data sets

for the latter there are additional tools, eg SHACL

at first sight there seems to be a mismatch between validating TDs and validating other linked data sources

but there is a large overlap

both TDs and SHACL are mechanisms to describe similar things

so if we want to validate linked data sets, may want to map between TD data schemas and SHACL

there is definitely an overlap for at least some features

then can validate both

is a tool: https:/idlabresearch.github.io/validatrr/

this gives complementary validation

provides translations between one mechanism and another

question (victor): in which context are you using the mapping?

answer: at this moment, not using it is WoT, but for data schema validation, similar problem
... and also existing linked data sets

Victor: why would you need a mapping? We do actually use SHACL... they are however not exactly right
... how would you prove they are equivalent?

answer: there probably is not a 1:1 mapping
... this is more about mapping parts of the constraints

question (sebastian): nice to combine two validations in one step

scribe: both structural and semantic validation

answer: yes and no
... if have JSON data schema, can use to validate non-JSON data
... as long as the other data can also be converted to linked data
... can check if two datasets are compatible, for example

question (coval): you said there is no 1:1 mapping, but is there a reversible mapping?

answer: the things you CAN map, can be mapped in both directions

session: future work and collaboration with other SDOs

Making IoT useful for Fueling and Convenience Retail - David Ezell (Conexxus)

industry perspective on why this work is important

think WoT has some very far-reaching impact

brief description of industry, who Conexxus are, past W3C standards, IoT-sized hole in our strategy

industry is in US, "Fuel-Convenience-Retail"

165M customers/day, $654/year in 2018, 154,000 store locations

effective product control is crucial

ownership tend to be in groups of 1 and 2... eg NOT big companies, but individuals

Conexxus is a trade consortium, do write standards, but at a different level

do advocate for semantics

aim to improve profitability

example: have POS and back office
... had a standard

but then found wanted to do direct store delivery

used EDI... recommend avoiding

but W3C fixed, since could use XML instead

the shift was transformative

gave a list of semantic areas

most important relate to POS and payments

but did not have cloud APIs

rather than back office, replace with cloud

but need to integrate IoT data

where to put it?

felt that WoT allows us to integrate IoT data

example: gas pump, doors on pumps

doors are sensored

if they open when they do not, may indicate a security hazard

cooler: recognize humans, doors open and close, can figure out dwell time
... can then understand better how to place products

another example: company grew by acquisition

have 44 different product lines using different IoT standards!

5 year outlook

baseline: POS -> cloud

but soon, control of the plant (cooling, security, etc) will be important

scribe: then AI checkout, but also barcode scanning

aka AmazonGo; just recognize product

robotic process automation

logistics and delivery

augmented employees

food safety

iot tracking

many many use cases

question (kathy): at iot fuze, target stores, talking about iot

have interally implemented Web Thing

but... small stores, don't have an IT infrastructure

so can this be provided as a service?

but also want some things to be local

Dom: have you considered "all the other things": tracking products, etc

answer: tracking is in fact important, but might be overtaken by camera identification
... tracking individual paths through the stores
... keeping up with paths through the store will become more and more difficult
... many issues with keeping up with standards
... have to also deal with legal compliance, e.g. taking food stamps for things that are not eligible

WoT Graph as Multiscale Digital-Twin for Cyber-Physical Systems-of-Systems - Gilles Privat, Thierry Coupaye, Sebastien Bolle and Philippe Raipin (Orange)

speaker: Dr. Privat

view WoT as a a graph to capture complex systems

rather than looking at single devices

similar to what happened with the web: pages -> system

known as web science; web graph as an object of research; scale-free graphs, etc.

WoT graph is interesting since it is a description of physical systems, not just information

3 foundations...

first, hyperlinks

second, nodes as digital twins of both connected and non-connected entities

third: structural CPS description as a graph and as a digital twin of the entire system

note: CPS = cyber-physical system

simple example... streets and crossings, related to cameras

using property graphs rather than RDF graph

arcs stand for actual physical connections

is a model of a physical environment

there are both smart things and non-smart entities, eg roads

then have a system composition as an overlay graph

show decomposition into subsystems

also, devices often part of a larger system, eg traffic lights are not stand-alone, but are parts of a larger system

can have nested systems and subsystems and the way they depend on each other

dependencies are NOT just a knowledge graph, but represent actual physical dependencies

but... will have knowledge and semantics annotations as an overlay on a CPS graph

in general, have physical entities, have things twins, have systems, and then have ontology graph

question: which applications are enabled by this graph?

answer: can break technical silos
... want to address JOINT technical system in a single graph

that can bridge how they are represented now in each silo

not one particular use case, but all potential applications

question: in theory, a graph for a BMS should allow adaptation to any particular building

answer: more than that, can bridge systems that currently are in silos

question (victor): who would actually define the relations in the graph?

scribe: and who would be paying for it?

answer: key issue, economics
... so far, actors do not have an incentive to have an overaching system
... can "make do" with silos
... but we are working on a system, but need to surface incentives

for example, governments can require it

would also have to prove that can improve working of entire system

scribe: for example, can have use cases that share information between multiple systems

e.g. traffic management and parking

occupancy could be used for security or energy management

<kaz> [lunch till 13:45]

<kaz> scribenick: mkovatsc

WoT and IoT - What's the difference? (Oracle)

Lagally: WoT Architecture and new application scenarios and use cases
... is there an overlap of domains?
... need to talk about other, real products
... WoT Plugfest scenario at TPAC
... what when scaling up to 100k Things
... cost of natural disaster events
... disaster control a use case?
... airplanes a use case?
... questions if WoT can model complex use cases
... help with better interface descriptions (unit mistake disasters etc.)
... 4 most important TD terms (for the author): title, description, version, support
... should all be mandatory

Sebastian: Highest interest in WoT for critical systems?

Lagally: Mainly to check if we covered everything

Kathy: Complex descriptions sometimes have their value, but sometimes simple is valuable
... optional is good
... version is maybe not well-defined

Lagally: I propose mandatory, but one could put dummy data to fulfill
... WoT is for humans and machines, IoT only machines

Benjamin: airplaines actually consist of 100k Things

Lagally: Examples were mainly given to broaden our minds

Next Steps for the Web of Things (Intel)

McCool: crossing the chasm - how to scale from early adopters to early majority
... IoT abou 10 years old, a lot of hype
... we are now before the chasm
... key challenges in smart cities
... what can W3C WoT do to cross the chasm?
... focus on one application (vertical) and a platform (horizontal)
... WoT charter needs to focus on impact
... identified gap of data interoperability
... 4 types of "interoperability"
... data srouce to cloud and cloud-to-cloud good for ROI
... other two farther down the road
... also now fulfill the requirements for the first two (description, data model)
... IoT data / metadata standards map
... target: one data model (semantic)
... ultimately "W3C Resource Descriptions"
... short-term "W3C Data Schema" unifying JSON Schema and XSD, OPC UA, ...
... needs to cover more formats other than JSON
... other long-term: management framework, abstract APIs, discovery
... conclusion: focus on data interoperability next

<mkovatsc_> mccool: ?

<inserted> scribenick: mkovatsc_

Jose: ? (short vs long?)

McCool: we need this timeline plan to improve success

Ari: Like the timeline

McCool: one data model as a first step can keep individual models but describe with RDF, converge in another step

Ben: in smart homes interoperability exists around concrete protocols etc. (ZigBee, Alexa, Google Home, ...)
... concerend, since this is not concrete

McCool: smart home companies are in One Data Model initiative and are asking for semantic support
... smart home covered in short-term timeline

Kathy: ZigBee smart home hubs could expose TDs?

McCool: hard to convince existing ecosystems to switch to something new, but possible to slowly transform their models to converge

Gilles: some merge paths in the timeline are strange

McCool: ? (focused on some specific aspects?)

WoT Simplifies Industry Applications (Siemens)

Christian: this is about our research group's strategy, not company like on Monday
... need to spread the word (got press coverage on Monday)
... internal communication
... new interfaces not fragmented as usual, but following W3C WoT with a TD etc.
... open source at the Eclipse Foundation: Eclipse Thingweb
... need to join the community
... great tools from universities (see TUM talks)
... unfortunately no WoT standard for scripting
... need to remind everyone about "existing ecosystem PLUS W3C WoT", not "versus W3C WoT"
... need complex/other Events (alarms, timeseries)
... need TDs in products
... W3C WoT helps industrial cross-domain scenarios
... thingweb.io also has tutorials

Ari: what have been your biggest challenges within the company?

Christian: getting business units on board

Matthias: act like a startup, do marketing, gain trust through quality collaborations, recommend the new technology where it solves current challenges the business unit is facing

Towards interworking between NGSI-LD and WoT (ETSI/FIWARE)

Jose: recently published API spec and have been collaborating with W3C WoT
... mission is to ease information exchange
... context information management
... using property graphs
... relationships can also have properties
... graphs represented in JSON-LD
... additional blank nodes to represent relation properties
... geoJSON for location information
... RESTful API to create, update, delete entities, multiple query features, subscriptions
... information about assets come from IoT devices, hence use W3C WoT
... Intermediaries map Things to our entities
... TDs need to be annotated, but should use standard ontologies
... Intermediary combines TD metadata and transferred data into NGSI-LD information
... W3C WoT is very promising and flexible for our use cases
... need more work on consolidation, more standards around Thing Templates and Protocol Binding vocabulary

Victor: in the TD example, why is the Event annotated with Observation?

Jose: need to combine feature of interest and property, but feedback is welcome to improve

Victor: we added annotation example(s) to the TD spec

Jose: maybe some annotations could be standardized, because Intermediaries will always have to do the same

Ben: there are lines to say no security

McCool: we are working to reduce verbosity

Matthias: it is in there to bother people who do not put security into their Things

Exploiting Interaction Affordances

<taki1> scribenick: taki

Andrei: WWW - Hypermedia environment for people
... which provides local guidance.
... goal is to provide global guidance
... WoT is an internet scale hypermedia environment
... How to privide global guidance?
... want to created automated consumer
... MAOP - multi-agent oriented programming
... is a world of humans
... agents have desires, etc.
... how can we program such systems?
... agent perceives and act on environment
... different from object which is passive
... different from actor, which is reactive
... how to balabce active and reactive is a challenge
... reactive - e.g. node-red
... static mashup cannot adapt to dynamic environment
... for automatic planning, need to balance proactive and reactive.
... BDI model has interpreter and events, done in late 80s
... less computing power that time.

Andrei showing agent programming language BDI

Andrei: similar to prolog
... is a script of behaviour.
... starts with belief, goal
... MAOP is more recent work.
... early 2000s, many multi-agent research was done.
... new class of multi agent system using hypermedia
... heterogenious data foemat, identification, autehtications are problems
... interaction protocols, wot can help.
... what about policies? regulations?
... discovery, searching
... has prototype search engine
... consumer needs to be autonomous
... we discussed this before
... world-wide manufacturing. autonomous marketplace. we can levegrage web architecture for those.
... about prototypes now.
... manufacturing lines are expensive.
... autonomy. 0% production engeeers define configuration.
... WoT, semantic descriptions. abstractions on top of that for agents.
... we can deploy multi agent system on top of WoT
... "belief" comes from sensor. and so forth
... benefit - reusability of components, automated planning + high-level programming
... BDI agents amd planning for Web-based artifacts

<taki1> scribenick: taki2

Andrei: agent achieves goal by selecting a plan.

Andrei shows demo video...

Andrei: graphics are not very important

<rzr> https://youtu.be/tfAVDpYn_ow

Andrei: I get notification when my goal was achieved.
... first hypermedia multi agent systems was held May 13.
... please check web site.

<rzr> http://www.hyperagents.org/

Andrei: interaction as a first class abstraction. TD provides this.
... declarative specification and enactment were Studied to large extent in MAS research.
... regulation as a first class abstraction. licensing policies, etc. this is an issue.
... conclusion. interaction afforances are important/ it will motivate hypermedia multi agent systems.
... Thank you/

Matthias: policies are challenges. is it funcamental problem?

Andrei: depends on level of autonomy.
... access card for door. is too restrictive. there are other ways. Those are polcies.
... how can an agent reason policies? This is another level.

Matthias: policy. both lawer understanable and machine underestandable.

McCool: There are contracts and outgoing contracts.

Andrei: restriction and sactioning of clients are supported.

Lagally: Thank you.
... last talk is from OGC.

Michael: WoT and OGC SensotThings API
... free, open web-based API. sensors amd observations.
... previous work. SWE, SOS, O&M.
... many open source implementations.
... visibility in sensing and smart city communities.

Michael shows STA Data Model.

Michael talks about STA basics...

Michael: accessing entities using STA
... Thing has location and datastream

Michael shows how to use links...

Michael shows how to use filtering ...

Michael shows pagenated results...

Michael: how WoT and STA relate?
... WoT is meta-level description, protocol-agnostic. state-based paradigm.
... STA is more concrete for sensing and actuation. state-based and observation-based.
... two are complementary, not in competition.
... STA as use case for TD.
... there are new requirements for TD. such as linking between collection of things, and recursive datatypes.

Victor: we may already have supported those.

Michael: WoT can benefit from geospatial nature of data.
... is it part of WoT? need to consider pattern for historic values.
... WoT can benefit from resource discovery and resource access
... sensorthings's query API is very powerful.
... STA's $expand keyword is powerful.

Michael shows an example of STA entity as WoT TD...

Michael: In TD form, URL is for getting the latest value.
... STA can benefit from TD.
... Semantic web technologies.
... can benefit from domain-specific data models.
... interoperability is a benefit.

Sebastian: ontology is existing. TD is based on JSON-LD.

Michael: proposal is about directory.
... without geolocation information, searching in directory is not easy.

Matthias: it is a good checklist.
... we have lots of extension points.
... we can experiment more in WoT IG.
... there are lots of choices for geolocation.

McCool: location, we do not have to pick one.
... General wrap-up.
... We discussed W3C and Mozilla alignment. we discuss this first.
... Web Thing alignment.
... Mozilla Web Thing not fully compatible with W3C WoT.
... key gap is misalignment of use cases.
... W3C use cases are broader.
... TD can describe services and devices.
... brownfield device use case.
... Gateway vs ability to describe interfaces to constrained devices directly.
... prescriptive and finite vs. descriptive and open. This is difference.
... How can we resolve those?

McCool shows possible solutions...

Ben: devices should use its interface.

McCool shows candidate solutions...

McCool: 1. prescriptive, 2 defaults, 3 fork, 4. profile, 5. other

Zoltan: Web-RPC specification had similar issue.
... it defaults to Web.

Lagally: no customization is desirable.

Ben: how do you achieve out-of-the box interoperability?

Lagally: through profiles.

Ege: protocol, application level? or HTTP level?

Ben: We can use WebSocket, too.
... we can consider extension to HTTP.

McCool: trickiest is the handling of WebSocket.

Sebastian: we have protocol templates.
... Protocol binding to Mozilla is another approach.

Ben: TD's hypermedia is not powerful enough.
... How many protocols should client support?

Question: How is it different from JavaScript version?

Ben: If we do not specify default, it is as if we are not recommending anything.

McCool: Things evolve. IoT devices surivivies for 10-20 years.

Ben: For the time being, We support HTML and CoaP.
... future HTTP versions should be friendly to contsrained devices.

Matthias: HTTP methods, WebSocket, etc. everything is in place.

Ben: Get for read properties, etc. are the only thing currently described.
... HTTP is the default.

Matthias: defaults are there. give users incentive to converge.

Ben: you do not want to create separate WebSocketfor all events.

Matthias: there is a RFC that provides solution.

Ben: we suggest to make TD spec simpler and smaller.

Lagally: TD 1.0 is powerful enough?

Ben: no

Matthias: please open issues.
... let's discuss together.

Kathy: profiles. is it use case?

McCool: limiting features.

Wrap-Up

McCool: we start discuss new WG charter soon.
... IG is for incubation.
... for gaps in TD, please create issues.
... does anybody has particular theme?

Zoltan: For scripting, WG or CG are good.
... Discovery may be for WG.

Matthias: first we experiment in IG.
... WG needs to maintain documents. We can enter maintenance mode.

McCool: maintenance and incubaton.

Zoltan: scripting is not browser API

Jeff: re-charter for maintenace was discussed at TPAC.
... there are lots pf ideas. good thing
... need to boil down on priority.
... how to triage?
... tangible and concrete items first.
... how big is each gap?

Jeff explains how CG and IG work together in W3C...

Jeff: IG does not have IP policy.

Lagally: we can consolidate calls into smaller number of calls.

Matthias: we cannot achieve anything if it is too broad.

Kaz: We had about 200 suggestions during Workshop.
... We can discuss those in WG F2F.

Spreadsheet including 200 suggestions and meta-categories

Lagally: can we clean and send this list to WG mailing list?

Jeff: what would the summer look like? TPAC is coming soon.
... July and August.
... we need to think about clear strategy.

Sebastian: what other silent people think about?

Andrei: offline things can have TD.

Ben: we needed more discussion time. Time keeping was challenging.

Kaz: was everyone happy?
... we can invite people to WG F2F if chairs agree.

Matthias: PR transition part of discussion may be boring for people.

McCool: people fly back, and Friday they can call in.
... Kaz to arrange WebEx.

Sebastian: we have done it!

everyone clapping hands...

Sebastian: It was great three days.
... we could setup mashup scenarios quickly.
... good job.

Kathy: thank you to all you guys.

Kaz: thank you very much for all your contributions!

Lagally: so many great ideas and brains.
... I enjoyed the whole thing so much!

Kaz: Minutes talkers, thank you.

Lagally: thank you for people for all the logistics

Sebastian: Enjoy the night, close the workshopp.
... F2F is at TUM. It is not hosted by Siemens.

Ege: location information is WoT IG wikipage.
... if any questions, please contact me.

Lagally: Presentation will be posted.

<mjkoster> A potential solution for profiles is to define them as a mediatypes

<mjkoster> it could address the websocket subprotocol issue also