<kaz> scribe for today: Kaz, Dave, Kajiwara, Daniel
<inserted> scribenick: kaz
-> https://www.w3.org/WoT/IG/wiki/images/3/3e/2018_W3C_WoT_F2F_Prague_Welcome.pdf
<kaz> next f2f in korea 30 june - 5 july 2018
<inserted> Matthias' Slides
Matthias: [Thing Description Sapporo
2015]
... (shows the TD 2015 version)
... [Thing Desription Montreal 2016]
... and then 2016 version
... domain-specific vocabulary, security metadata,
property/action/event, array
... entry points for interaction
... sapporo version had a single entry point
... montreal version multiple points
... hrefs there
... [Thing Description Now (1/3)]
... TD validator available now
... security work ongoing
... single entry point for interaction again
... new thing is data schema here
... semantic data schema
... e.g., iot:BinarySwitch
... discussion tomorrow
... annotate semantic information as well as syntax
... the other part is protocol binding
... [Thing Description Now (2/3)]
... some default approach here
... basics to build the request using "form" with "href"
... if you use some additional invocation
... deviation from defaults
... e.g., vocabulary for CoAP
... basically coap and also some OCF/CBOR content format
... can be understood by OCF implementation
... invoke action, write action, etc.
... pick up information
... [Thing Description Now (3/3)
... link from one thing to another
... web linking support within TD
... target will be another TD resource
... "rel": "controlledBy"
... e.g., motion detector
... how things are related with each other
... commercial building automation
McCool: possibly orchestration in addition to point-to-point connection
Zoltan: OCF has support for
containers
... wondering about relationship to that
... interaction would be different
Matthias: detailed discussion to be done during the tech days :)
(some more discussion)
Matthias: JSON representation for linking
by IETF
... text version link converted to JSON
McCool: anybody working on this?
... IoT use cases
Johannes: target is thing or interaction
Matthias: [JSON-LD 1.1]
... proposed Charter for a WG
... successor of JSON 1.0 by CG
... AC review until 29 Apr 2018
... we should clarify what our requirements are
... JSON 1.1 does have merits
... but we should focus on the AC review
... to get proper review
... detail to be done tomorrow
... proposed period 1 June 2018-31 December 2019
... should be aware of the reference for CR
... features we need to be kept in
... we should have strict use cases
... mandate from our viewpoint:
... make JSON-LD even more like idiomatic JSON
... using keys not arrays
... [@context #103]
... issue on the TD repo
... discussion with Mozilla
... very active though not participating in the WG
... we need to think about how to simplify TD
... one example is issue 103
-> https://github.com/w3c/wot-thing-description/issues/103 issue 103
Matthias: semantic annotations fully
optional
... we can easily handle this
... register TD-specific media type
... e.g., application/td+json
... preprocessing based on that
... how to convert TD to triples
... and also no restrictive conventions
... e.g., always arrays where possible
Sebastian: wondering about media type registration and versioning
Matthias: you can define td+json
... and then manage versions
Kaz: we should think about that
... there was version attribute in XML-based formats, though
Kajimoto: compatibility question
... currently using JSON-LD 1.0
... compatibility with the parser?
Kaz: how to use "@version"?
... to identify TD version?
Matthias: no, "@version" is to identify JSON-LD version
(some more discussion)
detail for tomorrow
Matthias: [Objects vs Arrays #111]
-> https://github.com/w3c/wot-thing-description/issues/111 issue 111
Matthias: triple representation
inside
... [base #106]
-> https://github.com/w3c/wot-thing-description/issues/106 issue 106
Matthias: lack of interoperability
... need for base URL in addition to TD URL as the base
... [@id/id #105]
-> https://github.com/w3c/wot-thing-description/issues/105 issue 105
Matthias: need for additional urn
... @id mandatory?
<inserted> Matthias: important to match security metadata in runtime
dsr: core model of WoT by RDF
McCool: default URI and additional URI
Matthias: all the tooling is there in semantic web
Danh: you don't need referenceable ID
everytime
... you can identify things using, e.g., Amazon id
Matthias: possibly from multiple
networks
... [schema #107]
-> https://github.com/w3c/wot-thing-description/issues/107 issue 107
Matthias: JSON Schema syntax
... some of the things could be simplified
... e.g., recursive properties
... schema information directly here
... how the semantic annotation needed for this?
McCool: reusing the existing mechanism
Matthias: reusing the modeling work
... [@type #104]
-> https://github.com/w3c/wot-thing-description/issues/104 issue 104
Matthias: type: boolean
... a bit inline with what can be simplified
McCool: similar capability with OCF data model
Matthias: [link vs forms #88, #108]
-> https://github.com/w3c/wot-thing-description/issues/108 issue 108
Matthias: discussion during the OCF joint
meeting as well
... relation from one resource to another
McCool: related to binary payload
... link is one way
Matthias: a bit different
... input data and output data
... could send binary image for action
... one of the concerns
... where is the convergence
... what are the properties?
... properties have links, actions have forms, event have
what?
... a bit more costly
... what are the events or resources?
... [Scripting API]
... entity description within TD and sub entity description
<dsr> Referring back to the discussion on @id, I would advise people look at W3C’s Best Practices for Publishing Linked Data, see http://www.w3.org/TR/ld-bp/ and the section on the role of good URIs in particular
Matthias: (TD example on the left side;
Scripting API example on the right side)
... thing.properties.on.get
... how to deal with TD
Zoltan: we already have an issue about that (on the scripting side)
Matthias: [SImplified THing Description
with JSON-LD 1.1]
... proposal (work in progress)
-> @@@simplified-td under td repo
Johannes: used to be active within the WoT
WG
... established EcoG last year
... Electoric Mobility is coming and the pace is increasing
... [Fragmentation is the biggest challenges for a global
interoperable Infrastructure]
... electric power charging is getting more and more
important
... auto-OEBm charging HW manufacturer, shopping mall, charging
operator, fleet, utility, ...
... API-enable approach for that purpose
... [EcoG brings the App Economy to Charging]
... [Inspired by Android]
... [The API for EV Charging]
... API for various charging providers
... [Builiding Blocks of the Hardware Agnostic EcoG Software
Solution]
... SW-stack, OpenAPI, Platform
... EcoG: Bringing together the relavant
Expertise&Experience
... 3 experts
... [We figured out how to monetize EV Charging]
... [Today EV Charging is just Power Transfer]
... e.g., just 2 dollars
... [The Paradigm SHift in E-Mobility: Every Business becomes a
Filling Station]
... traditional gas station to EV filling station
... With the EcoG API every Business turns the Time to charge into
Extra...]
... [Integrated Customer Journey]
... with an EcoG API enabled Charge and Mobiel Phone App
... charging structure with users
... [Unlocking NEW Revenue Streams with the EcoG API business
integration]
... 2 dollars for each => 110 dollars for a super market, 80
dollars for a fleet operation, 12 dollars for a coffee shop
... [EcoG is moving the infrastructure business from boxes to
services]
... [EcoG Traction covers Pilot Customers across
different...]
... [EcoG API Business Architecture]
... ecosystem diagram
... integrating smartphones, smart wathces, etc.
... [Open IoT^h^h^h WoT API to integrate EV Charging]
... [Using Web Technologies for IoT & API Service
Development]
... broaden developer base
... enable the "long tail" market
... maybe there could be some killer-app for the main 80%
... but interested in the 20% long-tail part
... [Using Web Technologies to Secure IoT & API Services]
... web-grade security
... simplified integration
... [Expected Developer Experience make EcoG eeasy to use]
... low entry barrier
... broad community
... rich tooling
... [Two EcoG Demonstrator Sites for testing and project
implementations]
... EcoG Munich, GER
... EcoG Detroit, US
... based on WoT
... also proxy exposed for IoT
... bunch of customers
... Ford, Bosch, VW, ...
... very interested in feedback
Zoltan: reminded me of pysical web
Johannes: several stakeholders from
business owners as well
... running station at supermarkets
... multi-stakeholders there
... we provide/maintain the runtime
Milan: question missed
Johannes: rental cars, family cars
... public charging depending on the charging network
... make it simple for people to use
... possibly free charge based on the car manufacturers
McCool: key area for Web payments as well
[morning break till 11am]
<dsr> scribenick: dsr
We resume after the coffee break …
Matthias introduces Michael Lagally, Oracle
Michael works in the Oracle IoT group
I will review AWS, Azure, and Oracle (IoT Cloud service) in respect to the high level concepts, device descriptions, device models and so forth
Some definitions of terms for a common understanding …
Things, device descriptions, device models (device types/templates), properties, and events
First let’s look at Microsoft Azure IoT Hub
Shows a list of links for the background information
Device Twin is an abstraction of the device state. Actions and events are not part of the Microsoft model. Messages are lightweight. The device twin model does not support templates or aggregating multiple devices into a virtual device
Twins have tags and properties. There are 3 kinds of properties, desired, reported and device identity
Actions could be modelled in terms of posting a payload to a method endpoint
Actions can take arbitrary number of parameters
No dedicate event mechanism, but can be modelled as device to cloud messages.
Shows a slide with an example using JSON as a serialisation format.
Tags are metadata, e.g. the device location
Moving on to Amazon IoT Device Shadows.
Similar in creating cloud based representations of device state
Devices report their state using JSON messages over MQTT
Amazon device shadows have a version, a thing name, a thing type, and a set of attributes.
There is a registry to manage things. They have concepts for thing types and groups
Groups may include other groups
Attribute values are limited to 800 bytes in JSON, probably due to the MQTT protocol
The spec only offers simple types for attributes
However, you can use a rule engine that supports JSON arrays and objects
Actions are similar to Microsoft’s digital twins
Likewise for events.
Moving to Oracle’s IoT approach
Oracle IoT Cloud Service platform manages devices, messages and events
Device models are a blueprint for defining devices, and support simulations without the need for physical devices.
You can create virtual devices as aggregations of other devices.
A device instance is created by registering a device that implements one or more device models (registering with the IoT Cloud Service).
The IoT cloud service can be used to manage device models and device descriptions. We use JSON, but not Linked Data
A simple WoT TD to Oracle device models demo is available
Device models describe metadata, attributes, actions, formats and links
Devices are uniquely identifiable.
Attributes can have a range of types, excluding arrays and objects. Attributes can be read-only.
Our database analytics tools expect flat data, and don’t currently support compound data types
Oracle actions can only take a single parameter, if you need more, format them as a JSON string.
Binary data is a challenge for JSON based messages.
Formats define message payloads and are uniquely identifiable via URNs
Formats are classified as either data or alerts
Human readable descriptions are valuable
Names may include spaces, but that isn’t recommended
Shows an example of a device model in JSON
At the Plugfest, I showed a demo that provides a gateway between the Oracle IoT Cloud Service and the Web of Things Node-wot implementation.
IoT gateways provide a means to connect via MQTT, CoAP, etc.
Can support manual or automatic transformation between device models and WoT thing descriptions
The gateway can expose and consume things …
AWS and Azure only define a data model with no actions and events. The serialization formats are incompatible, none of the solutions define a protocol binding mechanism, this forces device manufacturers to create code for 3 different environments
A unified device model would simplify integration across different platforms and accelerate market adoption
Sebastian: are the plans to add support for compound data types to device models for Azure, AWS, Oracle?
Michael: don’t know about Microsoft and Amazon, but no customer demand for Oracle IoT Cloud Service
The resource limitations are relaxed for apps running on gateways as opposed to resource constrained IoT devices
Dave: can you say anything about Oracle’s support for graph databases, and processing for Linked Data for greater flexibility?
Michael: no
Darko: why haven’t manufacturers driven work on shared models?
Michael: I would say that everyone has developed their own approach independently
Dave: do you see the likelihood of convergence for Web protocols (gateway to cloud, cloud to cloud) as proposed by Mozilla and EVRYTHNG?
Michael: that is the likely evolution, yes
Johannes: what would motivate cloud platform providers to adopt the Web of things?
Michael: Platform providers will adopt what their industrial customers ask for
<Zakim> kaz, you wanted to ask if there are any specific requirements for TD
<kaz> ml: some idea but detail to be discussed later
<inserted> Soumya's slides
Presented by Soumya Kanti Datta, EURECOM
Soumya introduces Eurecom and F-Interop, and their work on testing for the IoT
Interoperability is key for achieving the full potential of the IoT
Semantic interoperability is a way to solve interoperability across heterogeneous data sources, formats and models
SemTest, an industrial extension of the H2020 F-Interop project for work on testing semantic interoperability
This covers lexical, syntactic and semantic checks on messages
Checks at the communication level, lexical/format checks, and data processing checks
SUT = system under test
Question: are there any examples of commercial systems that embody semantic interoperabilty?
Soumya: there are several EU projects that claim to do this
Dave: I want to mention the work by the AIOTI on white papers on semantic interoperability, with a paper from 2 years ago and a new one aimed at developers in preparation - contact me if you want to get involved
Soumya shows a diagram with two connected systems under test
Some discussion about semantic processing involving SPARQL queries
<scribe> New diagram with a Query server positioned in between the two communicating systems under test.
n.b. in regards to the previous talk - RDF Semantic Graph is a W3C standards-based, full-featured graph store in Oracle Database for Linked Data and Social Networks applications.
Soumya: the key is to demonstrate semantic interoperability through explicit semantic modelling
We’ve done some work with oneM2m (see slide 11)
MichaelKoster: applications can interoperate through using the same terms, or through adapting to differences between models
Dave: one approach is to use abstract upper ontologies to relate different models, but this is expensive due to mapping terms to abstract atomic terms, another is to map models at a peer level, this involves conditional rule based transformations
Souyma invites us to fill out his survey (see slide 15)
As of know we (Eurecom) are implementing the tests within the F-Interop platform
Dave: F-Interop is funding a relatively short term effort on testing for the Web of Things, and I would like to talk to people here at the Prague meeting for their ideas on how to proceed
<Ege> Can you repost the survey link
https://goo.gl/forms/h3wgsyOpztxA3lSG2
Matthias encourages work on testing
<inserted> [lunch till 2pm]
<kaz> Milan's slides
<inserted> scribenick: ryo-k
Session: Semantic Annotation and Handling of (meta)Data in IoT Information Models
<inserted> Milan Milenkovic gives his talk
examples to be shown are taken from actual examples
digital transformation is needed, but current IoT standards are inadequate
what and why, not how
Commercial buildings (having 10s of thousands of sensors)
multiple systems, but not interoperable / not reusable semantics
<inserted> scribenick: ryo-k_
Problems and IoT Solution?: pre-internet... error prone (up to 30% error rate!)
very cryptic, only very people know how it works
need/want: portable services, attribute-based searches
"you can't do searches on IoT without semantics"
semantic annotations provides how the thing links to another things, relations to others
[Sensor data and meta-data use]
Haystack notation example
dis stands for display
One thing to like about Haystack: tags are crowdsourced (in the building management community
list of available tags -> pick as many of them that are useful
Rich metadata allows to add new sensors and integrate it without rewriting script
"Enables" attribute-based search (you can't do without it
How to handle metadata?
[Some Learnings and Observations]
Some of the metadata are static, rarely changing
variable metadata key value pairs in info models / separate APIs/queries to fetch static metadata as overlay
Descriptive, not Prescriptive
dsr: This analysis may help to convince people of different domains to standardize metadata
Example app: Finding rogue zones (too hot or too cold)
BMSs generally do not install rogue zone detection
(algorithm) Get all zone IDs, get zone sensor for zone, get setpoint, if difference > threshold then it is a rogue zone
sometimes 10%-50% rogue zones are found (actual results in Berkeley
What do you need to have in Metadata schema? -> looked at published smart-building apps, classified them, find relationships among entities
User input is important
Some applications only use part of the relationship. the parts are different among types of apps
Uncertainty in the metadata
compared Haystack, IFC, Semantic
Semantic sensor networks: (+) Flexibility, (-) Completeness
Take actual applications, analyze them and find what is needed
dsr: There are things can't know in advance, but can we use AI (predictive) technology? -> works maybe for historical data
BIM describes the design intent
----
iot.schema.org
Motivation: many standardization organizations, many cloud providers with their own notation -> we need some sort of semantic interoperability
What needs to be built? -> well known formats to describe semantics
"capability"
= set of affordances needed to interact with a device
Feature of Interest pattern
IoT needs to interact with physical objects
FoI largely overlaps with schema.org
example: LightControl capability
iot: providesInteractionPattern
all interactions are optional (= not prescriptive)
Lagally: : Q: How do you describe relations between interaction patterns, eg. TurnOff should not be with SetColour? -> The schema does not forbid those settings, this is implementation dependent
Can put restrictions on top of this schema
These restrictions can go into thing description
<kaz> (discussion on "Example: LightControl Capability")
State machine to describe state -> can also be used to forbid certain actions. / but not part of iot.schema.org
@3: How many domains are targeted? -> few. tens, not hundreds
Can mix other capabilities into a capability
Example: SetDimmer Interaction
data level is optional too
thing descriptions mostly differ in data level
(eg: Air conditioners having different temperature range / units)
<kaz> Darko's slides
What's new
schema contains more terms, has more users
proposal of how to use shape constraints
Events are being specified
<kaz> (slides 11)
attributes "writable", "observable"
How you are supposed to use iot.schema.org: example: discovery
How to ask ThingDescription Directory to find "an" air conditioner, not a "specific" air conditioner?
If well-known term exists, then it can be used -> that's what iotschema tries to do
search a term on iotschema.org, find a capability
"Air conditioner Capability"
2nd use case: automatically generate TD Templates
Pick certain terms that our thing should implement (shape constraints for thing) -> generate TD
such tools already exist for schema.org -> let's make one for iotschema
Why shapes are needed? -> they allow us to create variations between things with same capability
Example: one smart light has only "SwitchStatus", other smart light has "CurrentDimmer" "TurnOn" etc.
Shape templates provides a "fill-in-the-blank"-like template
<kaz> [[
<kaz> http://www.w3.org/2018/03/wot-f2f/slides/2018-03-26-W3C-WoT-F2F-Prague-iotschema-v2.pdf
<kaz> Light-SmartThings-TDTemplate.jsonld
<kaz> ]]
3rd use: TD recipes
Recipes = semantic templates for mashup applications
also JSON-LD documents
they allow automatic discovery of thing descriptions, they allow script generation
All steps except implementing application logic is automated with a "recipe"
<kaz> Matthias: asks Darko for explanation on what the objective of the Reccipes, what it provides, etc.
[Demo: OverflowProtection] -> What is the recipe in this case?
Recipes are declarative
(the parts in yellow is the recipe; thing 1 and thing 2 has functions implemented; the discovery provides the "arrows" in the diagram)
<kaz> fyi, minutes from the Mar-16 LD call
<inserted> Kaz: I also asked you to clarify what the "Recipe" was like during the LD call on March 16, but today's main point is not recipe itself, so please move ahead and talk about the main point (semantic interoperability using iotschema.org)
Work plan:
restructuring of iotschema.org, online version of TD generator, demo of applicability in other models like IPSO smart objects/Amazon IoT/TD from Mozilla and EVRYTHNG etc
McCool: Similarities with OCF and Amazon IoT(Alexa skills) are interesting
Toru: : Applicability to ECHONET. how to participate in development?
Darko: We still need to clear process to contribute, but can start contributing on GitHub (github.com/iot-schema-collab)
<kaz> Kaz: as put on the wide sheet on the wall, some of the PlugFest participants already tried semantic annotation using iotschema.org, so you should work with them
Danh: How to add concept like in schema.org?
Darko: If existing concepts not working: find concepts in other specs like OCF, take their resource type/concepts
Feature of Interest may make things worse, they may be arbitrarily implemented/defined
ThingDescription is also influenced by other specs (like in iotschema.org
<kaz> Kaz: given the purpose of this work is semantic interoperability, we might want to think about one specific scenario including multiple vendors, one from OCF, another from oneM2M and yet another from ECHONET, and think about how to use semantic annotation by iot.schema.org for interoperability
(discussion on how to correspond concepts in OCF/iotschema/ECHONET/etc.
<kaz> ari: wonders about the threshold to add entries to iot.schema.org
example: Presence sensor: one uses motion, but others may not use motion, how to describe them?
short answer: make one
but still needs an abstract term ("occupancy"? that is independent of motion, etc)
<kaz> scribenick: kaz
Kaz: many people are interested in
this topic (semantic interoperability), so how to continue the
discussion?
... main call, LD call, PlugFest call?
darko: already discussion within the LD call but need to report back to the main group
Matthias: need some executive summary as well
milan: ask about the work within WoT WG
Matthias: explains the WoT Charter mentions
the mechanism
... e.g., Schema.org
danh: we should have one "place" for the discussion
darko: we want to have definition of simple feature of interest with iotschema.org
[break till 4:30pm]
-> https://github.com/w3c/wot/tree/master/plugfest/2018-prague/PlugfestSlides PlugFest slides
<dape> scribe: dape
<scribe> scribenick: dape
<inserted> -> slides tbd@@@
Jose: work for FIWARE
foundations
... ETSI API specification
... ETSI ISG has mandate to establish info exchange layer
... smart cities is main domain
... there are many mores
... IoT is very important but not only source of information
... Mission: link all data sources
... to make it easier for end users/databases/.. to exchange
information
... idea is to create common API ... in "Context Information
Management"
... does not mean that there is single instance
... extra metadata can be exchanged in different systems
... Example: multi-modal transport ... for example google
maps
... there are other applications/formats
... how to enable such open systems (from different sources)
... goal: keep it simple and achieve:
... * API for developers
... * minimal complexity
... * breaking silos
... * enable data sharing
... Work on Information Model
... core concepts: Entities, relationships having properties
... also have query language
... example: Police report an accident
... car damages lamp
... involved are vehicle and LegalUnity
... ids for vehicle and legalEnitity (police)
... moreover, the damaged lamppost belongs to the municipal with
additional information
... information are published, can be subscribed, consumed
etc
... how are these elements represented?
... JSON-LD is used
... we defined context
... additional terms can be added
... 2 types of nodes
... type "Property" and "Relationship"
Lagally: Who manages IDs?
Jose: Should be managed by each entity (data owner)
Ari: How to discover those IDs?
Jose: query system at certain
location.. et cetera
... Assumptions
... * API is agnostic
... * use URIs to identify
... Possible architectures: Centralised, Distributed,
Federated
... Information model has 3 main concepts: Entity, Relationship,
Property
Lagally: Question, where is clock?
Jose: time for "observedAt" is
example provided by source of data
... Queries, why don't use SQL, SPARQL, ..?
... every database has different approach
... we have flexible subset of queries
Sebastian: Wonder why SQL for example does not suffice needs...
Jose: Do not want to be bound to
SQL...
... want to be flexible
... there are some pre-defined queries (by id, by equality,
...)
... nice to have also queries by geo locations
... API also allows to so Subscription
... similar to query... get informed if a certain condition is
met
Victor: is there RDF representation behind context? File does not seem to exist
Jose: Correct, is not there yet but
can be retrieved from XXXX
... Also ask for formal feedback from working group
... plan to finalize API specification within this year
... work on API introduction for developers
... also tackle security and privacy
Kaz: There is already official
relation between the 2 groups
... want to do a more concrete one between the 2 groups
<kaz> W3C Liaison table
Matthias: 2 things I see
... w.r.t. query I would like to know how powerful the language
is
... e.g. pointer to thing directory, also used in OCF
... in IETF it is registering web things
... SPARQL could be one of this complex query languages
Dave: interested in graph model
... lead of data activity... includes looking at model
... can talk about this later
Matthias: Also you specify data that gets
send around..
... could be good test for WoT
Daniel: Wonder whether there is practical exploration
Jose: There can be many issues, need
to solve security issues
... also there is previous work..
... document database vs graph models
Matthias: Did you look into how to scale this solution?
Jose: we have research experience in
distributed deployment
... no "real" experience...
... centralized approach can work but the goal is distributed
approach
Lagally: Is the assumption to use GSM network?
Jose: no. it is network
agnostic
... Next steps: 1. queries. 2. is time
... also resource directory pointer
Kaz: also possible to join PlugFest
demonstration
... beginning of July Korea, October TPAC
Matthias/Kaz: will look into liaison
<kaz> [procedure for liaison and actual collaboration]
Jose: collaboration would be desirable
McCool: would like to mention what we
are doing for security
... Issue:
... * many different sec auth schemes
... * interactions may have multiple forms with different
protocols
... Basic Example:
... have basic configuration section
... we also look at OCF, what standards do they use
... do we need all that is used there?
Milan: what is meant with "security" in TD?
McCool: security metadata
... put minimum we can
Matthias: Also telling you where to get auth token
McCool: Please look at .../wot-security/ directory
<kaz> PlugFest slides
MR: 5 demonstrations
... first of all thank you to all PlugFest participants and Oracle
hosting PlugFest
... we had more than 20 peoples
... many servients (yellow: application servients, blue: device
servients) [see slides]
... red boxes show support of iot schema
... please check also on github whether figure is correct
... various viewpoints:connect with remote/local proxy
... security, Scripting API
... device simulators
McCool: eventing is yet another thing we might want to add
Soumya: Two connected cars
... accessibility scenario
... 2nd demo: smart home and connected car scenario
... <showing video>
Johannes: Servient running on car?
Soumya: external device...
SANO/MR: servient in 3 locations: Cloud, Japan, Prague
scribe: showed long polling and event
handling
... NodeRED (application) controlled device in Japan
Nimura-san: Scripting API
... LED lamp has on/off only
... script adds capability fadeIn/fadeOut
... also worked with Siemens
... injecting scripts is possible
Panasonic: smart house demo
... worked also with Fujitsu
... Echonet gateway
Matthias: Fest plant with small CoAP
devices
...
... valve can be opened ... goes to tank ... there is also pump
from lower to upper tank
... have sensors watching water levels
... in Munich we had proxy... connected to Oracle IoT Cloud
<Darko shows script talking to Oracle cloud and acting on Fest plant>
Lagally: <showing Oracle IoT
simulators>
... created digital twin based on provided TDs
McCool: I had several things
... OCF smart home instances wired up
... gateway talks CoAP
... make generated TDs available on the fly
... OCF devices available as WoT devices
... also used web camera... with eventing... changing
exposures
... binary data (images) was use case
... long polling was implemented
... voice service was implemented also (Amazon alexa)