<inserted> scribenick: taki1
Sebastian: I also say to hello to
... I would like to intriduce Michael Lagally.
... we have two chairs.
Lagally: I am very pleased to be
... 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
... Thank you very much for coming.
Lagally: welcome Matthias
... 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,
... 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
... 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.
... 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
... 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
... 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.
Joshue modular accessibility semantics, for example.
McCool: we should incubate semantic
... 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
... 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.
... webpage, URL, HTML. Thing, URI, WoT Scripts. there are analogies.
Zoltan explains Scripting API's role in architecture.
Zoltan: Scripting API is for
... 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
... 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
... 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.
Dom: web of all other things. CPG,
... 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
... Building bridges for all the things!
... use cases to merge the two world.
... we can print sensors. it is happening.
McCool: privacy concerns?
Dom: One million dollar
... 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.
... 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
... 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: I was active in this
... 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
... 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
... 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
... we are NPO.
... we are working on emerging technologies including IoT.
... and WoT implementation.
Ben shows mizilla IoT team...
Ben: WebThings is an open
... 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
... 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...
... 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
... 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
... 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
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).
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.
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.
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.
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.
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.
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.
<kaz> [till 14:40]
<soumya> scribenick: soumya
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] 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
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)
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
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)
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.
... # 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://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
... 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
... 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
... how to discover a directory, bootstrapping a system
Sebastian: there was already discussions on that
Matthias: I had called it a rat hole
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
... 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
... we needed collections, we had to add it ourselves
Ben: onboarding new members -> making the group more approachable
Sebastian: how to trust the td
<kawaguch> scribenick: kawaguch
Lagally: We have keynote from singapore
... 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
... gather input to possible work items
... and incorporating to new charter
Sebastian: Please send your presentation to organizers if note yet sent
Chinn: Introduce Singapore smart
... 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.
... 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
... 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
... 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
... 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
Zoltan: Diving into small
... 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 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.
Aparna: IoT schema is an extension of
... 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.
... 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.
... 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.
<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: Thank you
Zoltan: I have some idea about this
... 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?
... management system using a Thing Directory.
Ben: a bit skeptical about
... 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.
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?
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
... please come back in 15 minutes.
<taki> Sebastian: lunch is 1pm
<kaz> scribenick: McCool
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
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
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
... is it based on the context type, etc?
answer: not indexed, but would be interesting to integrate with a discovery service
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
... how would you prove they are equivalent?
answer: there probably is not a 1:1
... 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
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
... 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
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
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
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
... 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
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
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?)
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
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
<taki1> scribenick: taki
Andrei: WWW - Hypermedia environment
... 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
Andrei: I get notification when my
goal was achieved.
... first hypermedia multi agent systems was held May 13.
... please check web site.
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
... 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
... 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
... 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
... 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
... without geolocation information, searching in directory is not easy.
Matthias: it is a good
... 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
... 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
... 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
... Protocol binding to Mozilla is another approach.
Ben: TD's hypermedia is not powerful
... How many protocols should client support?
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?
Matthias: please open issues.
... let's discuss together.
Kathy: profiles. is it use case?
McCool: limiting features.
McCool: we start discuss new WG
... IG is for incubation.
... for gaps in TD, please create issues.
... does anybody has particular theme?
Zoltan: For scripting, WG or CG are
... Discovery may be for WG.
Matthias: first we experiment in
... 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
... 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
... 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
... 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
... F2F is at TUM. It is not hosted by Siemens.
Ege: location information is WoT IG
... 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