(Some more photos are available online.)
w
Today, we achied following cross interaciton:
KDDI-Siemens-Panasonic-Fujitsu
[ PlugFest Day ends ]
remote: Michael_Koster, Yingying_Chen
<inserted> scribenick: kaz
[Slides]
[Slides]
[Slides]
naka: explains today's
schedule
... and provide logistics information
... coffee and lunch will be served at the HUB space
... demo available at the presentation room during coffee
breaks
... wifi available
... demo tour and social dinner in the evening
... leaving here at 16:40
... ISO rep not available, so Naka-san will give brief
explanation
naka: [ISO/IEC JTC1 SC41 work]
... scope and standardskaz: notes that IRC is available at #wot
[Slides]
naka: Getting Started with WoT Project
kaji: [ Conceptual Architecture
and Objective ]
... [ Practical viewpoint of Silo vs WoT ]
... one-stop universal platform
... [ WoT Framework example ]
... [ Usage of Semantics on WoT ]
... global identical vocabulary needs to be defined
... regardless of languages, etc.
... attribute for discovery
... [ WoT Framework example ]
... WoT client and WoT server
... [ WoT Servient building block ]
... servient has both the capabilities of server and
client
... [ WoT server in device itself ]
... [ WoT server for constraint device ]
... [ WoT interoperability PoC in Panasonic ]
... 5 different services included in Panasonic demo
yesterday
... smart apps platform
... smart home platform
... IRKit platform
... Hue platform
... Alexa platform
<naomi> kaji: [ Cross Interaction Demo ]
kaji: KDDI tmp sensor and Siemens
app
... Siemens app controls Panasonic light
... Fujitsu app also controls Panasonic light
... [ Standardization process in WoT ]
... Yongjing mentioned the story during the AC meeting in
Beijing
... please join WoT IG/WG!
... questions/comments?
(no specific questions/comments)
kaji: shows photos
... from Santa Clara meeting
... and video from Osaka
... and then video from Santa Clara again
naka: IRC channel: #wot
... can join using http://irc.w3.org/?channels=#wot
[Slides]
koji: tx for inviting me
... 3 main products
... automatic lathes, small printers, precision products
... legacy POS printer
... 2nd top world share
... also mobile POS printer
... 1st world share
... various partners
... POS market pyramid
... mobile POS market is our focus
... why Star is No.1?
... keeping up with the trend of smartphone/tablet market
... many innovative solutions
... MFi certified
... multiple lineups
... easy-to-use SDK freely available
... so easy setup
... original software services like WebPRNT, PassPRNT and
AllReceipts
... that's why Star's printers are de-facto
... software solutions including Star SDK
... both for iOS and Android
... not only APIs but also source codes
... Star WebPRNT
... from iOS, Android and Surface
... HTML/JS + StarLine XML/HTTP over wifi
... web bridge function for Bluetooth
... Star PassPRNT as software-based printer server
... driver application
remote+ Sam
scribe: Star AllReceipts
... digital receipt is provided by AllReceipts service
... current situation
... our printer supports this kind of multiple I/F
... USB-A, USB-B, LAN and another USB-A
... tx
kaz: ok to upload this presentation?
koji: let me check
mccool: printer driver as a web
service?
... payload as XML?
koji: yes
<inserted> scribenick: naomi
kaz: koji mentioned a difficulty
of basic printer which restricts sizes
... in this case any data is available, the slide says
... do you have any specific problems?
... w3c wot group has difficulty of streaming data
... we need some method on it
... how to specify data
koji: BoS printer market we need
to have 100% guarantee
... streaming idea works but not perfect solution for 100%
guraantee
... we have to set data links inside of Thing Description
... client have to count data
mm; JSON market
scribe: tickets
... are you looking that market?
koji: we might sell ticket service
kaz: mm, you mean online store?
mccool: no, my point is point of
sale
... we have IoT application to log in
koji: we support multipul
language
... and right to left, left to right
... this is not for wot but we focus Thing Description
kaz: another question
... do you have usual http and @2 style of printing?
... W3C CSS writing mode spec
... do you use that kind of specs on printing?
koji: yes
... it'll fit our concerning point
... this software idea can fit as well
... inside of apps to generate convert commands
... it can easy to generate receipt
kaz: interesting point
... relationship between semantics and CSS style
koji: any questions?
<kaz> [ morning break ]
[Slides]
<inserted> scribenick: kaz
mccool: [Outline]
... OCF history, background and markets
... OCF architecture and principles
... working on diagrams
... changes between OIC 1.1 and OCF 1.0 draft candidate
... [OCF - High Level Goals]
... easy for developers
... common data model
... initial target is smart home
... [OCF&IoTivity]
... , open source implementation
... budget under Linux Foundation
... C++ implementation and now Node implementation
... primary focus on CoAP
... [OCF - Conceptual Framework]
... profiles, core framework and transports
... core framework is standard mechanism
... interaction/data model, resource model
... discovery, data transmission, data management, device
management
... transports: bluetooth, wifi, lte, ...
... [OCF - Resource Model]
... common properties and resource specific properties
... interfaces basically provide views
... sensor view, etc.
... [Resource Model - examples]
... resource URI: /a/light1 and /a/fan1
... /a/light1 - rt: oic.ex.light; if: oic.if.rw; prop:
discoverable, observable; n: myHallWayLight; State: 0 (off);
Dim Level: 0
... [Common Interaction Model - Transport Agnostic]
... Create, Retrieve, Update, Delete, Notify
... [Let's look deeper at a Resource ...]
... Server - DevA
... [There can be more Properties]
... [Resource Type - Data Modeling]
... 2 things to describe metadata
... first thing is set of properties
... by JSON Schema
... and verbs using RAML (ReStful API Modelling Language)
... describes the request and response
... and now the third option
... emerging standard, Swagger (aka, open API)
... OIC introspection
... [Table 19: oic.wk.p resource type definition]
... OCF specification defines "oic.wk.p" resource type for
platform and its list of properties
... [Link]
... how to define te connection between two resources
... /a/room and /switch
... relative URL
... {
... "href": "/switch",
... "rel": "contains",
... "anchor": "/a/room",
... ...
... [Collections]
... also scenes
... set of devices
... can be stored
... [Collections...example]
... "Room" collection - room has lights and fan
... /my/room/1
... {
... "rt": "acme.room",
... "if": ["oic.if.r", "oic.if.rv"],
... ...
... [Interfaces]
... subset of resources
... interface provides a "view" into a Resource or
Collection
... Interface defines allowed methods and semantics on that
"view"
... OCF has a set of predefined Interfaces
... [OCF ER Model]
... not from the official OCF spec...
... platform-devices
... WoT semantics define similar model
... [Major Changes in OCF 1,0 (Draft) CR from OIC 1.1]
... Swagger/OpenAPI for: data modeling, introspection, RAML is
still used in main spec definition
... Enhanced security: alignment with IETF ACE and
AllJoyn
... better specification of uses of certificates
... better management of onboarding and offboarding
processes
... mandatory access control, system management
... [Summary]
... resource-oriented architecture
... IoTivity
... New features in OCF 1.0
... Questions?
dsr: relationship between OCF and narrow band IoT?
mccool: OCF work is
protocol/transport-agnostic
... CoAP designed based on UDP
[Slides]
koster: [T2TRG]
... started in March 2015
... chartered by IRTF
... investigate "Internet of Things" applications and
architecture beyond IETF CoRE/CoAP
... [Topics]
... quite broad
... REST and Hypermedia for connected things
... Event-state duality, pub-sub pattern, notification
... Connected Thing Life Cycle
... Management and Operations
... Work with Industry SDOs and Fora - work with W3C WoT on
data models and semantics
... Plugtests, Interop tests
... Practical Semantic Interoperability
... Mobile code
... Security
... [Research Drafts]
... RESTful design guidance
... Security challenges for IoT
... Hypermedia content types
... CoRAL - CBOR Encoding of Hypermedia Controls
... HSML - SenML + Link-Format Hypermedia Controls
... [Events]
... meet in conjunction with IETF and related activities
... joint meetings with Industry Fora, e.g., OCF
... semantic interop in conjunction with IETF 99 in Prague,
July 15-16
... planning for semantic interop events
... multiple device ecosystems participating
... [Meetings]
... IETF 93, IETF 94, Jan 2016 (Sophia Antipolis Plugtest),
March 2016 (with IAB Semantic Interop), IETF 95, IETF 96, Sep.
2016 (Joint with W3C WoT IG), Oct. 2016 (with Eclipsecon),
IETF97, Mar. 2017 (joint with OCF), ...
... [Next T2TRG Event]
... T2TRG Joint Semantic and Hypermedia Interoperability
Workshop
... with IETF 98, Prague, Jul 15-16
... OCF, LWM2M/IPSO, W3C WoT, iot.schema.org
... example topics: cross-ecosystem semantic interop planning,
hypermedia controls for actions, hypermedia-driven apps, models
and model translation
... [References]
... datatracker.ietf.org/rg/t2trg/charter/
... github.com/t2trg
... datatracker.ietf.org/rg/t2trg/documents/
... questions?
mccool: next f2f of wot will be held Dusseldolf
koster: ending on Thursday and will travel to Prague on Friday
[Slides]
er: [Importance of Security for
WoT]
... why security is important for WoT?
... 10 things to know about the Oct 21 IoT DDos attacks
... avarage IoT device is compromised after being online for 6
mins
... large-scale IoT security breach coming in 2017
... here are the biggest IoT security threats facing the
enterprise in 2017
... very popular topic
... [Always good to remember]
... 3 principles: start early, involve everyone and explore
existing solutions
... [How do we do it?]
... 1. threat model - understand what you need to protect and
why
... 2. scoping - organize and prioritize threats, define
security objectives
... 3. state of the art - study related areas and their
approaches to security
... 4. solutions - find a suitable mitigation for each in-scope
threat
... 5. implementation and evaluation - implement and test each
solution
... questions?
... (continues)
... [1. Threat model - Understand what you need to protect and why]
... stakeholders, assets, attackers/attack surfaces,
threats
... [Resources]
... WoT security documentation:
github.com/w3c/wot/tree/master/security-privcy
... WOT IG security webconf:
www.w3.org/WoT/IG/wiki/IG_Security_WebConf
... that's all
naka: questions?
kaz: everybody from this meeting room is encouraged to join the Security TF :)
elena: good point
[ Lunch ]
afternoon session will start at 13:30
remote+ Elena
ms: [Building this necessary
interoperability of fog-enabled applications requires a
collaborative approach]
... funded by the 5 companies and one univ
... Intel, MS, Cisco, Dell, ARM, Princeton Univ.
... [OpenFog mission]
... mission statement
... To drive industry and academic leadership in fog computing
architecture, testbed develpment, and a variety of
interoperability ...
... [OpenFog COnsortium]
... 57 members
... 6 founders
... affiliations, contributing members, and other members
... [OpenFog Consortium goals]
... technology, innovation, education
... testbed to demonstrate interoperability
... ... evangelize fog computing
... doing a lot of efforts
... [Organizational structure]
... technical WGs
... architecture framework, SW infrastructure, communications,
security, manageability, liaisons, testbed
... under the technical committee
... and marketing committee, social impact committee, americas
committee, greater china region committee, japan committee and
european committee (planned)
... [OpenFog Reference Architecture]
... www.OpenFogConsortium.org/RA
... [The OpenFog reference Architecture Framework]
... software/device developers
... interoperability in IoT, 5G, AI and other complex
data/network intensive apps
... and creating common language for fog computing and wil help
unify the edge/fog ecosystem
... under a single, interoperable, testable set of hardware and
software standards
... [Key pillars of the OpenFog architecture framework]
... security, scalability, open, autonomy, RAS, agility,
hierarchy, programmability
... [Architecture description with perspectives]
... green layer: sensors, actuators, control; protocol
abstraction; hardware platform instracture
... dark blue: network, accelators, compute, storage; OpenFog
Node Security; OpenFog Node Managment; Hardware
Virtualization
... blue: Node Management & Software Backplane
... Orange: Application Support
... grey: Application Services
... vertical mechanisms: Security, Manageability, Data
Analytics&Control, ...
... perspectives; node view (green), system view (dark blue),
software view (blue);
... [A closer look at fog nodes]
... gog nodes communicate with each other in a distributed
manner
<scribe> ... new value chain and business entities
UNKNOWN_SPEAKER: [Technical WG
focuses]
... [Reference Architecture Contributions]
... [Node Security]
... basis of Fog security
... hardware root-of-trust
... physical security
... [Network Security Aspect]
... node to cloud
... REST over TLS
... node to node
... HTTP over TLS, CoAP over DTLS
... node to device
... IP adaptation
... [Data Security Aspect]
... Data in Use
... data in memory undergoing procesisng
<scribe> ... [New Work & Task forces]
<scribe> ... new TFs established
UNKNOWN_SPEAKER: [Security
Requirement Taskforce]
... mission statement
... to define sets of requirements that has to express the
fundamental security (and in the future evaluation)
requirements for an OpenFog compliant (in the future certified)
node and system.
... as a reminder, the work shall support both brown and green
field implementations
... [Security Requirement Taskforce (contd.)]
... Method
... [Security MVIs]
... minimum viable interface
... [Smart Objects for an OpenFog Architecture: SW
Infrastructure WG - Task Group]
... What are Smart Objects?
... Why do we care about Smart Objects?
... Smart Object Landscape, ...
... [What's a Smart Object?]
... an object that describes its own possible
interactions
... can be physical, e.g., sensor, computing device,
wearables
... can be cyber, elgl, data, executable code, apps, services,
clouds
... [Why do we care about Smart Objects?]
... reduce time and cost to develop, deploy and maintain IoT
applications
... data interoperability; service, object and software
composition
... [Smart Object Landscape]
... W3C Semantic Web, W3C Web of Things, ipso, OCF, IIC,
Haystack Connect, UPnP, Allseen Alliance, IETF, OPC, RDA,
NIST
... [Smart Object Issues]
... a lot of challenges
... frameworks: standards, ontologies, interoperability
... [Charter]
... working closely with other SDOs including W3C
... [Transaction Management & Orchestration
Princeples]
... [Logical Transaction Layers - concept]
... distributed resources
... 1. Fog Platform Infrastructure - Shared Resources
... 2. Microservice Logical Fabric assemblies
... 3. Data, Object, Interface&Access
... 4. Fog Transaction&Management
... defines scope of services
... e.g., with a building
... would control temperature and humidity
... resources are connected to storages
... project could be energy management
... [What is a Transaction?]
... transaction based TLA time (e.g., 10sec) consists of:
... Internet (3sec)
... Application (3sec)
... System+Storage (2sec)
... Network (2sec)
mccool: fog as distributed
cloud
... micro services?
... access to a service, e.g., computer vision
... public devices
... difference in computing storage
ms: go back to the diagram of
"Logical Transaction Layers"
... these are system infrastructure view (=Fog Platform
Infrastructure layer)
... metrics of business for a transaction
... [Transaction Level Management Elements]
... the fog is logical description of resources
... on top of that, orchestration layer
... and delivery model
... on the left side
... transaction management e.g., by blockchane
... [Resource, Data, Object Transaction Management]
... [Moving forward...]
... [OpenFog Priorities (2017-2018)]
... technical WGs under the technical committee
... interface standardization with an SDO -> open reference
implementation
... certification and interoperability fogfests
... regional use cases and test cases from regional
committees
... APIs to standardize
mccool: questions?
unida: regarding smart
object
... diversity is one problem
... how to overcome?
ms: study in the market
... e.g., W3C perspectives, OCF perspectives
... common vocabulary in those areas
... not to have one single standard
... but consider interoperability
... common vocabulary the use cases
... other SDOs like OIC, AllSeen
... maybe OCF would have different profiles
yongjing: similar question
... you plan to pick up one of existing standards
... or interoperability like WoT
ms: would take existing good
things
... don't want to reinvent wheels
... interoperability with existing standards
... may work on open source project with other SDOs
... also testbed project
yongjing: common vocabulary?
... can be done with somebody collaboratively?
... how to host that?
ms: openfog has a liaison
wg
... liaison from technical viewpoint
... communicate with other SDOs
... simple liaison and collaborative work on common
vocabulary
yongjing: generating your own vocab?
ms: don't have to be a single entity
[Slides]
<dsr> scribenick: dsr
Kazuyuki Ashimura presents W3C work on automotive.
The automotive industry has seen lots of change.
Kaz runs through the list of Automotive WG meetings
He presents a diagram showing the vehical signal architecture.
The bottom level is the car’s internal system as exposed e.g. on the CAN bus
The Vehicle Information API is exposed via Web Sockets using a Vehicle server.
Kaz mentions the VW submission https://www.w3.org/Submission/2016/01/
Work has started on a test framework.
The Vehicle Signal Spec is defined by GENIVI not W3C.
Kaz lists some links to related other work.
The Web of Things architecture will enable an ecosystem of automotive related services.
The VIAS (Vehicle Information API spec) defines an API that is exposed to applications in a web browser.
The VISS (Vehicle Signal Spec) feeds a JavaScript library that then exposes the VIAS API to applications.
Michael McCool asks a question on how to satisfy requirements for functional safety certification.
One solution is to prevent the apps from being able to control the car in ways which would risk safety.
This may require a module that enforces this.
Kaz: the car maker is responsible for that.
Michael: this becomes very challenging for self-driving cars.
Kaz: web of things needs to handle safety and security
Kajimoto-san asks about requirements such as response time.
[afternoon break]
<inserted> scribenick: kaz
[Slides]
norikazu: agenda
... overview of oneM2M partnership project
... standardization at IoT/M2M Service Layer
... release 2 and release 3 ...
... [Global Partnership Project
... 8 partner type 1: atis, TIA, ETSI, tsdsi, CCSA, TTA, ARIB,
TTC
... also patner type 2 (vertical payers and industry
groups)
... BBF, OMA, HGI (merged into oneM2M), New Generation M2M
Consortium, Global Platform, CEN&CENTRIC
... [200+ Members Organizations]
... [Purpose & Deliverables]
... oneM2M purpose: to specify and promote an M2M common
service layer
... oneM2M deliverables: technical reports (informative) and
technical specs (normative)
... [oneM2M Organization Structure]
... Steering Committee - finance, legal, marketing,
methods/proc., certification
... [Work Process]
... various use cases: enargy, enterprise, healthcare, public
services, residential, other, transportation, industry
... common requirements based on the use cases
... that is stage 1
... stage2/3 is specification
... [M2M/IoT Common Service Layer]
... M2M Service Layer was defined by ITU-T FG-M2M
... software layer
... between M2M apps and communication hardware/software that
provides data transport
... nomally rides on the top of IP
... [oneM2M Architecture Approach]
... Pipe (vertical)
... Horizontal Interoperability (based on Common Service
Layer)
... [oneM2M Architecture]
... application layer (consists of Application Entity): device
AE, Gateway AE
... Service Layer (consists of Common Service Entity)
... Network Layer (consists of Network Service Entity)
... defining interface between entities
... [Common Service Functions (CSFs)
... registration, discovery, security, group management
... data management&repository,
subscription¬ification, device management,
application&service management
... [Communication Protocols]
... reuse IP-based existing protocols
... service layer core protocols: CoAP, MQTT, etc.
... [Timeline of oneM2M Key Events]
... 2012 - 2013 - 2014 - 2015 - 2016 - 2017
... oneM2M partnership project launch: Q3, 2012
... Release 1 Issued: Q1, 2015
... Interoperability Test Event #1: Q3, 2015
... Interoperability Test Event #2: Q2, 2016
... Release 2 Issued: Q3, 2016
... Interoperability Test Event #3: 2017
... [oneM2M Release 2 Features]
... oneM2M as eneric interworking framework: AllJoyn/AllSeen,
OIC, LWM2M
... Semantic interoperability
... [Ongoing Collaborations]
... with other SDOs
... utiliaztion: OMA, BBF, OASIS, HGi, IETF, ETSI
... Interworking: Allseen, OCF (including OIC and UPnP)
... Collaboration: IIC
... liaison&collaboration: ITU-T, GSMA, W3C, 3GPP, IEEE,
ISO/IEC JTC1/WG10
... related to IoT technology
... regarding collaboration with W3C, the detail will be
explained by Yongjing
... [Toward Release 3]
... Release 3 planning
... work track 1: Market Adoption Track (high priority)
... work track 2: Industrial IoT and smart cities
... work track 3: Forward Looking Areas
... [Phased Approach for ertification]
... initial phase: Oct. 2016-
... Global Phase: 2Q, 2018?
... [OSS and Implementation]
... Industry-driven open source software/platforms
... LAAS-CNRS: OM2M
... KETI: OCEAN
... Cisco: Open Daylight
... examples of commercial implementations/demos
... LG, Huawei, SK Telecom, Sierra Wireless, Ericsson, LG U+,
kt, ...
... [Busan Smart City Project/Korea]
... [Smart City/France]
... [UK]
... [India]
... [LG U+]
... [Open IoT Platform (sensinov/France)]
[Slides]
yongjing: [Technical Highlights]
... [Architecture Configurations]
... Infrastructure Node (IN)
... Middle Node (MN)
... Application Service Node (ASN)
... Application Dedicated Node (ADN)
... Non-oneM2M Node (NoDN)
... lot of options
... [Generic CRUD procedure]
... create request/response
... retrieve request/response
... [Communication Models]
... blocking synchronous
... non-blocking synchronous
... non-blocking asynchronous
... [oneM2M Resource Model vs WoT]
... CSEBase - base
... cseType - @type
... supportedResourceType, pointOfAccess, nodeLink -
property?
... [Data Management]
... different resource types
... support hierarchical data model
... support semantic annotation
... can represent (depending on implementation context)
... eventable
... [Subscription & Notification (event)
... can set event criteria
... target address of notification
... [Device Management]
... mgmtObj as a template is specialized to individual
management resource, e.g., deviceinfo and firmware
... some are actionable and some are not
mccool: hybrid function
yongjing: [Group Management]
mccool: OCF has same functionality
yongjing: [Semantics]
... RDF descriptors
... semantic discovery/query
... [Security: Enrollment & Security Association]
... enrollment phase and security association phase
... [Security: Encryption]
... [Security: Authorization (Access Control)]
... protocol specific
... [oneM2M Interworking Overview]
... to make different standards/technologies working smoothly
together
... - transparent interworking
... - translucent interworking
... - semantic interworking
... [OIC/OCF Interworking]
... OIC/OCF domain and oneM2M domain
... [Ontology based Interworking]
... oneM2M based ontology
... the upper ontology serving as the anchor to
facilitate/automate the mapping from external systems to oneM2M
resource tree
... [Proximal Interworking via HAIM]
... mapping at the semantic level
... common template
... [HAIM example]
... SDT concepts vs WoT concepts
... [Interworking: WoT->oneM2M]
... exposing the WoT interface described in TD to oneM2M
systems
... benefit: WoT services/data can be consumed by oneM2M
apps
... question: do oneM2M apps need to understand WoT data model
at all?
... [Interworking: oneM2M->WoT]
... exposing oneM2M interfaces to WoT systems
... benefit: oneM2M services/data can be consumed by WoT
servients
... question: is WoT descriptive enough for oneM2M data models
and interfaces?
... [Annex: oneM2M specification walkthrough]
kaji: comments/questions?
sebastian: we should look into the
details
... possible scenario for the next PlugFest
yongjing: can provide further information for discussion
[ OpenDay ends]
Demo Tour at Panasonic Center Osaka
and then Dinner!
[OpenDay ends]
scribenick: kaz
sebastian: gives basic background
maria: talks about ontology work
mccool: possibly multiple serializations
... we could omit some of the information
... simplify some of the information
... different serialization for different people
(looking at "Proposal of TD Model")
sebastian: having one core TD model and various serializations
mccool: one serialization could include everything and possible subsets
(discussion on model and serialization)
sebastian: summary
... simple understandable model which is independent from serialization
yongjing: UML-based model?
sebastian: simplified Maria's proposed model
matthias: you can put the slides at somewhere and we can continue discussion
sebastian: will put the resources on the server
mccool: we should consider which tool to use
matthias: matthias: you can create an issue on github within the TD repo
[Slides]
kaji: introduces Echonet spec
... can be converted to JSON-LD
... inclusion and removal of part of JSON-LD definition
dsr: different SDOs have different approaches
sebastian: is this proposal part of JSON-LD itself?
matthias: we had discussion in Santa Clara
... there was the person in charge of JSON-LD 1.1 spec
... may be difficult to reflect to JSON-LD itself
... maybe we can have some specific discussion on how to reflect this idea to RDF triples
kaji: we have research society in Japan
... RDF experts there are interested in this
matthias: are you planning to propose this idea to JSON-LD guys?
kaji: yes
sebastian: you can send an email to the WoT group as well
[Slides]
dsr: this relates to work on personal zones and the social web of things. The challenge is to find ways to create simple user interfaces that non-geeks can use.
barry: we need a control panel?
scribenick: naomi
mccool: we should building a map, what things in a house.
... we should building a map, what things in a house.
barry: but other devices no more relevant to a house for example on a toaster
mccool: ownership, household. issue is to access network is the key. Need to describe too access control.
matthias: it's in a system. smartphone communicates devices who to access. It could be possible to @1. It's a good starting point. Idea of map, usage of description. It will be an intermediate goal.
[morning break]
and then breakouts
[Resource models and mapping to TD]
[Liaison TF charter initial discussion
<dsr> scribenick: dsr
Yongjing shows the oneM2M meta model for the home appliance information model.
This includes non-functional information such as a product’s serial number, as well as functional information such as the device’s propertied, actions and events.
Michael describes the relationship to the OCF models
Yongjing talks about modularity and how devices can be embedded in other devices.
Michael: I don’t see links, nor the idea of collections
Yongjing “link” is like a property
Michael: one requirement is to
assign the value of a property for a collection of things
... rather than having to do this explicitly for each member of
the collection.
Yongjing talks about the hiearchy of modules in HAIM.
HAIM has an ontologyRef that links to an ontology that relates to the thing’s type.
Dave: HAIM properties could be mapped to thing properties or metadata depending on their nature.
Sebastian makes the same point.
Dave: the SDO’s like oneM2M need to define their Linked Data namespaces to allow us to define the mapping to thing descriptions.
Yongjing: so properties are more like functional information, right?
Sebastian: yes
Yongjing: any oneM2M device should be describable as a thing for the Web of things.
Dave: my mapping of HAIM to things is at https://www.w3.org/WoT/demos/td2ttl/m2m.html
Yongjing: I struggle a bit between retaining the HAIM hierarchy and flattening it when mapping to a thing description
Yongjing talks about the challenges for the metadata needed for the protocol binding.
Sebastian: I would approach this simply.
They stand at the display chatting about the details
Dave: we want to decouple applications from the specific IoT platforms, and to keep the thing descriptions as simple as possible. A oneM2M driver will know a lot about the details for oneM2M, but not about specific oneM2M devices. If the thing model is a natural representation of the HAIM model, the oneM2M specific metadata in the thing description can be minimised.
Yongjing: in my exploration, I’ve tried to be explicit (e.g. he includes the PUT method in the metadata)
oneM2M doesn’t support attribute addressing, everything is at the level of modules (aka resources)
He shows a table summarising the mapping principles.
Device maps to thing. Property to property. Action to Action. Event to Event.
It isn’t clear what a ModuleClass maps to
Yongjing talks about the oneM2M specific HTTP headers, e.g. X-M2M-Origin
Sebastian: one approach is to describe the protocol information in detail. It is quite hard to do that.
The other approach is for the thing description to identify that this is a oneM2M device along with metadata that a oneM2M driver could utilise.
Yongjing: I was previously thinking that a thing description would be sufficient to access a oneM2M device without a oneM2M specific driver.
Dave: the URI for oneM2M could be dereferenced to obtain information about how to obtain and install a driver.
Michael: there’s two levels of adaptation. Aspects that can be automated would be in the driver, but other aspects should be in the thing description so that the application can adapt as appropriate.
Yongjing discusses device firmware update as an example use case
One idea is to write metadata to the thing and then command it to update its firmware based upon that metadata.
Yongjing: there can be a need for atomic transactions
Michael: an IoT platform driver may translate a thing action to multiple IoT platform specific actions.
Sebastian repeats the point that we don’t want to model everything in the thing description.
Michael: if oneM2M mandates firmware management capabilities, this doesn’t need to be mandated in the web of things, as you could instead use the oneM2M management interfaces directly.
Sebastian: that sounds like
something for this afternoons break out session with Johannes
and Zoltan.
... we break for lunch …
Yongjing: oneM2M specs are publicly available so everyone is free to join the liaison task force.
Michael: that looks like being the OCF policy too for future releases.
[slides]
error objects/messages to throw in handlers (scripting) based on Symbolic Error classes (like HTTP 2xx, 3xx, 4xx, 5xx)- see also this reddit entry)
matthias: HATEOAS: Hypermedia-driven
Actions and error handling
... [Be aware: WoT is Two-fold]
... complementing existing standards
... for binding templates, scripting API
... [HATEOAS/Hpermedia Controls]
... Entry URI -> Resource Directory -(follow links)->
Thing A
... how to handle multiple Things?
... [Prototype: ISO/IEC 15118-2 - Electric Vehicle
Charging]
... a lot of steps here
... Siemens implements EV charging device
... setup phase and charging phase
... we can find use cases from this
... [Actions]
... short-lived actions and long-lived actions
... we might want to monitor them
... any implementations?
... ideas?
... in your prototype implementation, how to control the
process?
radim: so far just reading data
matthias: what about air conditioners
or robot cleaner?
... would like to have some brainstorm
nimura: related to management
topic
... need some control mechanism inside Things
... HATEOAS might be applied
... some one need to provide management mechanism
matthias: definitely need new
mechanism
... would like to start with this viewpoint
... related to Scripting API
... maybe we can connect this topic to the management topic,
though
... you don't have to let the client know about concrete state
transition model
... loose coupled interface
... (mentions a use case of online payment)
... having this mechanism for machines would be powerful
nimura: we need to think about concrete situation for this
matthias: maybe machines should know about basic state transition by vising the "next" link
radim: question about the "long-lived" action
matthias: there a lot of freedom
here
... TD usually has some starting page and following consecutive
links
nimura: need mechanism for error handling as well
matthias: [Error Handling]
... shows example code of .onInvokeAction
... but how to recover?
... handling status code internally?
... [Error Messages]
... provide means for recovery
... 404: link to the start page
... 401: link to "log in with Facebook"
... provide means for machines
... TD-like interactions
... action(?) to the get access token
... would like to get opinions from people
kaz: mentions SCXML as a detailed
state transition mechanism for long-lived action
transition
... but what kind mechanism would fit which level of action
transition?
matthias: small high-level state
transition mechanism possibly?
... (mentions an example use case of converting temperature by
C to F)
[Slides]
radim: [CHRIMEN]
... based on B2G
... reference open-source hardware board providing Web GPIO/I2C
APIs
... [Exhibition/Event]
... try and touch event
... Interop Tokyo 2016
... Keio SFC 2016 event
... [Maker Fair]
... [Online Resources]
... chirimen.org, etc.
... [Web x IoT Maker's Hackathon]
... [Web x IoT Maker's Hackathon (cont.)]
... [Vision: Pervasive browsers]
... IoT devices into which Web technology ahs been
introduced
matthias: chicken and egg problem
... hard to give enough information
... [Web GPIO/I2C API]
... work by the Robotics CG
... robot controlled by a browser (with GPIO/I2C APIs)
... can handle temperature sensors, etc.
... and export the information as a servient
... [Recent Activities]
... implementations by polyfills
... discussion on APIs
... should be more general APIs?
... security issues
... authentication and authorization
... some of the devices don't have displays
... browsers always send requests?
radim: [Browser has no server
function]
... [WoT servient with browser]
... browser on th edevice communicates with WoT servient on
cloud or gateway as a WoT client
... [Issues]
... authentication and authorization of browser/client
... setting properties should be allowed only to some specific
client
... consistency between thing descriptions and devices
... distance sensor value should be set as a distance
properties
kaz: interested in the DAP WG's generic sensor API discussion?
radim: possibly but so far
interested in GPIO and I2C
... how to make the interface abstract
matthias: where to connect with the WoT
discussion?
... Matsukura-san is working on abstraction
... this is related to hardware APIs
... how to talk with sensors
... are you aware of Johnny 5 project?
... similarity with TD as high-level interface
... can provide your ideas to the Scripting API discussion as
well
... this board is usually connected with ubiquitous
browsers
... possibly connection during the plugfest at the next f2f in
Dusseldolf
... comments/questions?
... lunch and marketing strategy after that
[Lunch]
[Slides]
<scribe> scribenick: kaz
mccool: [Marketing Planning -
Brainstorming Session]
... there is another session on Friday as well
... [Purpose]
... brainstorm topics to discuss on Friday
... think about what we want and need
... [Messaging]
... need to clarify our message
barry: difficulty with the second topic: focus on key value/deliverable of WoT
mccool: what's the key value?
... we could have offline discussion as well
... could list things
... what would be the "one thing" for an elevator pitch?
... [Collateral]
... presentation material
... keep it up-to-date
... different length
... different audiences
... history vs base materials for new presentations
... Materials for developers
... tutorials, examples and documentation
dsr: would be useful to have videos as well
mccool: presentation tutorial?
dsr: plugfest as well
... we don't have resources to maintain presentation
materials
... great to have help from the group
mccool: we have to get permission for
images
... there is a datasheet
... (shows the current version of the datasheet)
mccool: [Online Presence]
... Web site, Wiki, Github and evangelism (Webinar, etc.)
... [Evangelism]
... Events and Liaisons
... [Recruiting]
... how to recruit new Members?
... who would be valuable to have?
... (lists some stakeholders)
... also about timing
... would have a list of questions
... [Logistics]
... what are the deliverables?
... by when do we need them?
... who does the work?
... started to collect presentations on GitHub
mccool: comments?
<inserted> mccool: shall we try some exercise?
<kajimoto> Open,Enhance, Flexible by WoT
kaji: who would be our
audiences?
... browser vendors? service providers?
mccool: e.g., Google is both
<barryleiba> Too geeky, but "We're building a data model for the Internet of Things, which programmers can use to make 'things' sold by different companies work together."
<barryleiba> 'tis a start...
<yongjing> what i used in presentations in other events is to position WoT as the 'glue' at the metadata level to enable cross-platform communication/interaction by the powerful descriptive capability of TD.
<McCool> My messaging proposal: The Web of Things defines an open, free standard that describes IoT devices in enough detail that other devices, people, and services can communicate with them.
<kaz> WoT as a universal connector for various IoT technologies/standards
<McCool> I think the WoT is the thing we are introducing, let's assume people know what "IoT" is (IoT: known; WoT: new concept)
<barryleiba> I don't see a substantive difference. I think we're better off conflating them.
<jhund> where can I find the webex coordinates?
<barryleiba> Here's a question to tease that out: Do we really want to have a set of people who think that they care about IoT, but they don't care about WoT?
<McCool> My messaging doesn't really refer to WoT except as the name of the group. Instead I think we should focus on the key deliverable: the open "description" (the TD) and why it is useful
<barryleiba> If the answer to that is "yes", then describe that set of people.
<barryleiba> McCool: Yes, exactly.
<mkovatsc> W3C WoT aims at complementing existing standards and platforms by providing semantic descriptions and horizontal technological building blocks to pick from, instead of prescribing a full vertical architecture.
<zkis> WoT: do IoT with web concepts ( in addressing, access, ...) using TDs to describe interactions and interacting entities.
<McCool> https://en.wikipedia.org/wiki/Elevator_pitch
Matthias: who would handle this?
<zkis> WoT compliance: TD compatibility (ontology, semantics, ...)
Matthias: we could discuss the strategy during the breakouts
<naka> WoT: interconnect different IoT standards
mccool: will take an action item
<dsr> The potential for the IoT is huge, but is being held back by fragmentation. W3C is defining an interoperability framework that reduces the effort and risk for developing services across a wide range of platforms. Our unique selling point is cross platform metadata for describing services based upon W3C’s extensive experience with Linked Data and APIs.
<k_nimura> wot provides abstruct way to use things. less programming
[slides]
zoltan: need to discuss the relationship with "tab"
zoltan: the first thing I get is request if I'm a runtime
matthias: maybe we don't have to manage this at all, do we?
zoltan: don't think there is any implicit origin
matthias: requests from the outside to start scripts are irrelevant
jh: wraps up the discussion:
<jhund> We have concluded upon these points:
<jhund> * scripts have a context (resembling the "origin" in UA)
<jhund> * scripts run in a script execution context
<jhund> * we should define the interrelation between the origin and the execution context
<jhund> * we should formulate the guarantees/contract that a script developer can rely on (single-threaded execution etc.)
<jhund> * when starting a script, the runtime needs to know in which context it runs
<jhund> * origin / context does not relate "1:1" to the browser world
zoltan: [WoT Runtime]
... management of Things as part of the runtime
... separate mechanism for security
[here: Kajimoto, Yamada, Ohura, Nagao, Kaz, Toumura, Matthias, Uday, Mizushima, Matsukura, Taki, Yongjing, Osamu, Shigeya, Uchida, Nimura, JooYoung, Youngmin]
<jhund> regarding Zoltan's slides:
<jhund> * we conclude on encouraging encapsulating functionality (such as accessing the system) into thing interfaces
<jhund> * such local things are accessed in the script just like remote things (discovery etc.)
matthias: in the early version of the
architecture diagram we had legacy api
... non-standardized access
... need special functionality for system access, e.g., Echonet
or I2C?
jh: client api for physical
interface?
... or need specific physical api?
<kajimoto> Physical API/Legacy API might be out of scope of standardization, isn't it? Because those APIs exist so script only call them. Scope of standardization is client API for calling WoT servient, server API and discovery API.
<zkis> as example for high and low level IoT APIs: https://github.com/01org/iot-js-api
matthias: to change your script for GPIO kind of specific interface or do we need another layer?
sebastian: [Request to run script]
jh: would talk about this during tomorrow's session
https://www.w3.org/TR/mmi-arch/#ArchDiagram
kaz: clear separation between the management side and the device handling side might be useful
jh: summarizes the session
... management interface session tomorrow
<zkis> * I will be back in 40 minutes.
[Slides]
[afternoon break till 4pm]
[Slides]
matsukura: [WoT Servient architecture]
... 2 types
... type A: uses scripting API to execute
... type B: ues WoT API to execute
kaz: so type A has script on
itself
... and type B means external script
matsukura: yes
... [Overview of processing flow]
... [Discovery and Provisioning from device]
<inserted> matsukura: [Discovery and Provisioning from App.]
matsukura: type A search and check to TD
repo and search for the legacy device
... [Application searches TD]
... [Application gets data from device]
... consumed Thing retrieves TD from the repo and sends "get"
to the device via the legacy device adapter
... [Application type B searches TD]
... application B asks consumed Things if the device is
available now
... and searches the TD corresponding to the device in the
repo
... [Application type B gets data from device]
... [Why synchronization is required?]
... synchronization mechanism is required in some cases of
management for multiple TD repos on multiple WoT
Servients
... server-client/master-slave, distributed,
redundant/multiplexing
... [Some issues on multiple WoT servients]
... access control for the distributed devices
... [Example diagram for server-client]
kaz: which is the server?
matsukura: right side "Cloud (WoT servient)"
kaji: maybe the left-side "Gateway (WoT servient)" is also a server?
matsukura: [Device registered to master
repository]
... [Another way on TD synchronization]
... [Application on cloud searches TD]
... [App on cloud gets data from device]
... [Conclusions and proposals]
... conclusions:
... synchronization mechanism is required for multiple WoT
servients
... there are some methods to manage TD repos on distributed
servients
... 2 types of application for the WoT servients
yongjing: question on slide 5 and
6
... [Discovery and Provisioning from App.] and [Application
searches TD]
... what is the difference?
matsukura: this process an be omitted
matthias: discovery api is missing here
yongjing: Matsukura-san proposes 2 ways
matthias: one option is more searching and another might be push
yongjing: pull vs push
... Matsukura-san, do you have any preference?
matthias: core resource directory is
getting a standard
... you could use some lookup mechanism depending on the
underlying mechanism
<mkovatsc> jhund/zkis, do you have audio?
<zkis> *yes
<mkovatsc> We had a question about the status of the Discovery API
matsukura: [slide 2]
<mkovatsc> Are there drafts that could be used to implement the presented use case
matsukura: would have the resource model separately from the runtime
nimura: [Device registered to master repository]
matthias: we discussed synchronization
of data in Santa Clara
... maybe you might be able to have a smart implementation
which has prediction capability
... need to clarify the logic how to copy the TD between the
local side and the remote side
uhcida: not sure if
synchronization would be always the best way
... we should clarify issues and requirements first
... and then solutions next
matsukura: yeah
... would like to clarify issues based on use cases
yongjing: what would trigger the data transfer
kaz: would suggest clarify the data transfer using a simple diagram which shows the inter-servent data transser
matsukura: tx
[Slides]
[Technical Work Day 1 ends]
[Slides]
mccool: [Summary of Changes from OIC
1.1]
... introspection: swagger 2.0 (aka OpenAPI) available
... meant to augment (not replace) other introspection
capabilities
... [Major Change 1: Introspection and Data Models]
... see pages 132-134, section 11.8 of OCF Core spec
mccool: the intended usage of the
introspection device data is to enable "dynamic clients"
... dynamically generate a generic "browser" UI, create
translations fo the hosted resources to another
ecosystems
... other usages of introspection
... [RAML vs OpenAPI/Swagger]
... both designed for Web APIs (not IoT)
... RAML is based on YAML (but can be encoded in JSON)
... Swagger uses JSON-Schema (but can also use YAML)
... for detailed comparisons:
... http://modeling-languages.com/modeling-web-api-compareing/
...
http://nordicapis.com/top-specification-formats-for-rest-apis
... [RAML vs OpenAPI/Swagger] (sample codes)
... [Major Changes 2: Enhanced Security]
... details here: @@@
... property access, mandatory device state, software update,
...
... [Other Changes]
... [OCF ER Model]
... omitted/incomplete/wrong:
... mappings from abstract mechanisms to concrete
mechanisms
... link is incomplete
... collections, links, scenes
... introspection: new in OCF 1.0, introspection resource is
available to retrieve OpenAPI data model
... walk through the data model...
... properties have some flags
... resource types
... manager part optional
... [Issues with OCF ER Model]
... relationships need to be labelled and categorized
... links are incorrectly modelled right now
... certain other aspects not modelled yet
... [OCF Links]
... sample code
... "href": "/switch", ... target
... "rel": "contains", ... relation
matthias: this is not "OCF link" but "Web link"
mccool: depending on CoRE
matthias: core link format defined by some RFC
mccool: [WoT Links]
... [Next Steps with OCF Model]
... converge notation with oneM2M, IoTschema, etc.
... formalize usimg RDF and define OCF ontology
... validate with OCF
... mirror work done with oneM2M
... [OCF/WoT Interop Demonstrator Planning]
... need to demonstrate WoT system interoperating with OCF
devices
... select set of simple OCF devices to use at a test
case
... generate a TD for OCF devices
... [OCF Smart Home]
... demonstrate multiple aspects and implementations of
OCF
... requires special hardware to run
... physical sensors to be connected
... should be possible to convert to software emulation (using
QEMU for Zephyr component)
... https://github.com/01org/SmartHome-Demo
... smart power meter on Zephyr
... [Smart Home Demo Enhancements]
... questions?
kaz: are you joining PlugFest from this viewpoint (as part of OCF) during the next f2f in Dusseldolf?
mccool: that is the plan
... possibly using multiple different platforms/backends
... have to look into the detail
... comments?
yoshi: interoperability between
OCF and WoT
... what kind of architecture do you assume?
... function bridge
mccool: WoT bridge which exposes
TD
... binding to OCF protocol
... possibly on a gateway
yoshi: possibly OCF, oneM2M and WoT
mccool: protocol binding discussion
should handle a list of possible target protocols
... visits 01org/SmartHome-Demo
... Michael Koster will present his protocol binding proposal
later
[Slides]
sebastian: [Agenda]
... JSON Schema
... [TD Current Working Assumption]
... [Missing Thing in JSON Schema]
... e.g., a TD servers a property 'status' of a
thermostat
... 'status' defines an object with multiple data
... where is the temperature value measured in Celsius?
... [Agenda] again
... discussion with Henry Andrews in Santa Clara
sebastian: https://github.com/w3c/wot-thing-description/json-schema-spec
daniel: semantics could be edited
using json schema
... Henry brought a comment
daniel: would respond to that
... last comment made one hour ago
matthias: somewhere to store data
... and schema and validate the data
... different languages for humans
... TD tries to unify
... you don't have to have out-of-bound knowledge
... applicable from one platform to another
barry: thermostat might provide time/date
dsr: we don't want to make small devices handle complicated semantics
daniel: simple string might be useful in some cases for our plugfests
matthias: semantics and interaction model
<dsr> For the web of things we need both descriptions of interaction models and semantic models which deal with different concepts
matthias: we want to describe how
machines handle semantics
... how one machine interact with another machine
... and understand what it can do
dsr: temp sensor provides temperature as simple number
matthias: number is not
interaction
... important part is what kind of links/methods are used
daniel: links to different concepts
dsr: discussion later today
... what would be the cleaner way for interaction
taki: data types are some degree
some kind of semantics itself
... integer, binary, base64, ...
... we need to convert one form to another
... we can't do automatic conversion
matthias: another question
... how you actually link to the linked data level
... text form vs rich level
... how to manage the gap?
... numbers and strings
dsr: linked data and RDF
... you can use json schema or json
matthias: in human mind, we can
understand how to handle data
... but if we can't formalize the gap, machines can't handle
the data
... we need concrete mechanism
sebastian: you should provide concrete proposal
kaz: we had discussion during the
TD call the other day
... and I started to think it would be useful to have 2
separate layers for TD
... device-agnostic interaction layer
... and device-dependent layer
... was expected to create an issue on that
... but have not yet done...
dsr: shows his proposal
dsr: data types definition
... booleans, numbers, strings, objects, ordered/unordered
collections, vectors, enumerations, unions
... how to formalize in terms of metadata?
... interaction model
... in terms of RDF
sebastian: difference from
JSON-LD?
... how to integrate semantic meanings of particular data
types?
dsr: we want to start with some
particular things
... what kind of units are used
matthias: fundamental already we're
doing
... the question is how to start something?
... how to formalize this for distributed "Thigns"?
... that's what we've been doing during our PlugFests
... this is fundamental we've been doing
... but how to build concrete systems?
mccool: replacing JSON-LD with
RDF?
... what do we use JSON Schema for?
yongjing: maybe we should once go back
to Sebastian's slide?
... [Missing THing in JSON Schema]
... the issue may not be te problem of JSON Schema itself
... rather how to represent the information model?
... for oneM2M spec
... you have "unit" value
... maybe need another level of hierarchy
... we can solve this issue by information model rather than
JSON Schema itself
sebastian: that's possible
... but how to handle additional information within TD?
matthias: we don't have any specific
semantic mechanism here
... we should fill the gap
... we don't want to start from scratch
barry: we're talking about 2 things
now
... you can go with many levels of data
yongjing: if someone provides this kind
of data model (on the left side)
... can't tell the semantics
... we should add additional semantics information
matthias: agree
... need to provide unified way
sebastian: would like to ask Yongjing and Dave to join the issue discussion on GitHub
kaji: we can use the open slot
after the morning break
... also could shorten the lunch
kaz: btw, there are 2 issues:
semantics and unit
... from the viewpoint of unit, we can simply use SI unit,
e.g., kelvin for temperature
... each local servient can convert kelvin to C or F
[ morning break ]
koster: [Protocol Binding]
... maps abstract operations on WoT meta types to concret
operations
... WoT, OCF
... [Protocol Binding Template]
... a spec for the information included in a particular
protocol binding
... [Thing Description (simplified)]
... semantic description and protocol binding
... [OCF Protocol Binding]
... avoid embedding knowledge of specific OCF resource type
constraints in software
... basic form of a hypermedia control, extension to the
"links" property
... [Generation of Thing Descriptions from OCF Introspection
Data]
... generate TD and protocol bindings from introspection data
(Swagger)
... Dave's tool creates TD from OCF resource descriptions
... OCF has an open source "swagger 2x" tool
... with input/output schemas
... [Strawman Example]
... highly explicit, identifies everything needed to use
generic protocol engine
... [Alternate OCF resource formats]
... composite format and batch format
... this is an actuation format
... [TD - Interaction Description]
... JSON Schema + Extension
... "targetlevel": { "type": "number", "semtype":
"sch:level"}
... protocol binding goes under that
... [TD - Protocol Binding (Composite Format)]
... links: [
... {
... "href": "..."
... "inputdata": {
... "type": "object",
... @@@
... CoRE link model
koster: going back to 2 different
formats
... [Batch Format]
matthias: your implementation needs to know what OCF spec does here
mccool: need to be more general thing
matthias: you can look at this from
technical viewpoint
... might be some specific options
mccool: e.g., nice to have a CoAP
level
... and OCF level too
matthias: if we need to know the detail of OCF spec, there is no merit of protocol binding
<inserted> yongjing: who is in charge of the binding? refer to, e.g., oneM2M schema?
matthias: media type is missing
koster: possibly multiple
resource types
... might have some kind of state machine
yongjing: wondering if it's really
sufficient to use this information to generate OCF
messages
... any OCF specific extensions?
koster: good question
... e.g., IoTivity is a client
... probably a bridge
yongjing: native WoT servient may not fully be able to interact with an OCF server
koster: WoT client should have capability to talk with an OCF server
mccool: a WoT client should be able to behave as an OCF client
koster: that's one case
... another case is
... using consumeThing interface
matthias: exposing a Thing to an OCF
client might be difficult
... maybe need to think about on the next step
yongjing: possible need for additional oneM2M parameter
<toru> quit
kaz: draw a diagram
... and wondering who/what is in charge of generating the
protocol binding part
... and how it generates the template?
mccool: would like to try protocol
binding from WoT to OCF during the next PlugFest in
Dusseldorf
... starting with manual generation
... and Swagger introspection is the second spec
dsr: should maximize the semantic information
(discussion on how to proceed)
matthias: would suggest we create an issue on the GitHub before starting yet another TF call
[Lunch till 1:30pm]
sebastian: [Missing Thing in JSON
Schema]
... [What we need in JSON Schema]
... key elements and semantic annotation
... "@semantic": "http://example.com/..."
mccool: or add keywords to JSON Schema to point URLs
sebastian: this approach adding meaning of concrete instance as well
barry: what you're talking about
here is not semantics but type
... semantics is something like "in-door temperature at this
room"
... Celsius/Fahrenheit is not enough
mccool: unit and semantics
yongjing: not a set of RDF
... this could be multiple instances
sebastian: can be array?
yongjing: yes
matthias: link to a number of linked
data
... this is a linked data model
barry: Celsius/Fahrenheit information is part of the data but we need some more information
matthias: temperature data may be
described using kelvin as unit
... location (=at this seminar room) is possible semantics
sebastian: [TD Current Working Assumption]
mccool: maybe you could pick up some key concepts
matthias: this is extension to JSON-LD for semantics
mccool: this is not actual TD but JSON Schema. right?
matthias: this is not a good
example
... so McCool has a question
mccool: putting Schema into TD?
sebastian: yes
mccool: so would have extension for JSON Schema
yongjing: what is your expectation? ontology or schema?
sebastian: want to introduce a tool to handle semantics in TD
matthias: in TD, we need some kind of
vocabulary
... didn't want to reinvent the mechanism
... in JSON Schema, there are useful terms
... so might want to embed some of them into TD
dsr: JSON Schema is not a
vocabulary
... that is a different task
matthias: but we can borrow the
mechanism
... the question is which linked data vocabulary to start
with?
... nice idea is combining the mechanisms
... can be handled by machines
dsr: linked data should be independent from serialization
matthias: JSON Schema would be a good
starting point
... this is a subset of what we agreed on
sebastian: shows JSON-LD Playground:
http://json-ld.org/playground/
... getting more challenging
yongjing: wondering about the
difference between existing type and this additional type
... your problem scenario should be a complex type
... would ask Dave to provide concrete example with
problems
[[
{
"@context": ["http://w3c.github.io/wot/w3c-wot-td-context.jsonld",
{ "sensor": "http://example.org/sensors#" }
],
"@type": "Thing",
"name": "MyTemperatureThing",
"interactions": [
{
"@type": ["Property","sensor:Temperature"],
"name": "temperature",
"sensor:unit": "sensor:Celsius",
"outputData": {"valueType": { "type": "number" }},
"writable": false,
"links": [{
"href" : "coap://mytemp.example.com:5683/",
"mediaType": "application/json"
}]
}
]
}
]]
mccool: one option is adding keywords
from JSON Schema to TD
... another option is adding custom types to JSON Schema
barry: "cvc" is just a number
mccool: we need richer type system
barry: right
mccool: use case discussion for tomorrow
sebastian: use case:
... servient 1 (weather station) just needs Celsius value
dsr: TD is abstraction and should be independent from serialization
matthias: problem of terminology
... combining two things
... serialization is a mechanism to serialize some data
model
... JSON-LD is a serialization
dsr: am focusing on interface between apps
<elena> kaz, sorry to interrupt, is there a change in agenda? There is noone at the security meeting...
ah, yes
we've been talking about TD again
for 30 mins
but the discussion getting longer
<elena> so when should I join?
maybe in 5 mins but not sure...
<elena> ok, I will keep the meeting running then
tx
taki: what is our scope?
matthias: starting point is ok with
JS
... input/output on the Scripting API level
mccool: expressing the structure of
the data
... JSON meant to be a universal data format
(some more discussion)
[we'll continue discussion on how to add types, semantics to TD based on generating concrete TDs and corresponding JSON Schemas]
[Slides]
nimura: [Behavior of management Interface]
zoltan: need to fix the figure
matthias: if you can't do something
using property/action/event, something is wrong
... there are 4 management features
... but could be handled by action/event
... there might be a servient which doesn't provide
functionality
... only allows proxies
nimura: [How to achieve the
Synchronization]
... can be achieved by some scripting api
... not necessarily need to use management interface
matthias: quite similar to the
management api
... what is the difference???
... why we need to create something new?
johannes: [slide 4]
... similar interface to other exposedThing
nimura: yes
matthias: the red box "management api"
accessible from outside
... TD describing the management thing?
johannes: got consensus?
kaji: motivation to introducing
management
... [slide 1]
... (2) Scripting API (Remote)
... some kind of tunneling functionality?
... directly connecting to the Servient would be easier
<zkis> *yes, but maybe through my new version of slides, so let's wait on their turn
kaji: not sure about the motivation
[here: yamada, nagao, kaji, ohura, kaz, toumura, matthias, matsukura, nimura, yongjing, sebastian, uchida, jooyoung, youngmin, shieya, mizushima, uday]
johannes: expose all the
functionality to the network
... why not having exposedThing for this purpose?
<jhund> to clarify my view : Management Thing is a regular Thing to the outside, but it has more rights, as it controls the runtime
<zkis> Agree with Johannes - I have a new version of yesterday's slides that hopefully makes that more clear.
kaz: our impression is that we don't need specific new "management api" but can extend the capability of scripting api. would suggest we clarify our expectation for "management" based on some concrete use case (e.g., the plugfest demos in Beijing) by drawing a sequence diagram/
zoltan: [WoT Scripting]
... do you agree this usage of scripting?
johannes: TD template pointing script is a new idea
zoltan: red line means script create
things
... blue line means TD refers to script
matthias: green "TD" has new
concept
... green "TD" is usually something related to yellow
"Things"
zoltan: agree
nimura: what about security with remote servient?
zoltan: same for all the
servients
... who is requesting what
... runtime checks access rights
johannes: we have a manager
thing
... allows us instantiate runtime
... and script execution context
... discoverable by local discovery
<mkovatsc> Tried to incorporate my understandings here:
johannes: and accessing outside sandbox should be done by scripting api/client api
<jhund> 1) There is a Managent thing that allows to download or receive a script and run it
matthias: is the plugin interface
intended to standardize something? or implementation?
... can be done using system interface
<jhund> 2) scripts run associated to a script execution context. things in the same execution context are discoverable via local discovery
<jhund> 3) Accesses outside of the sandbox resp. the execution context should be done via a thing interface
<jhund> (those were 3 proposed formulations for consensus points, please feel free to correct&comment)
(showing Matthias's updated figure)
zoltan: better figure
matthias: better to iterate discussion on this kind of picture
nimura: do we have one single
event loop?
... or separate multiple loops?
matthias: safe to share the same event loop
nimura: how to protect the context?
matthias: no need to expose to the
outside
... same owner of the device, then no need for separation
zoltan: we should come with updated
slide set
... and update the rational document
matthias: +1
... having an accurate picture is very important
... relationship between boxes
zoltan: yes
... we can start with Matthias's diagram on Google docs
johannes: ok
nimura: btw, we were talking
about synchronization as well
... how to deal with that part?
... e.g., using a 2-runtime model
sebastian: how to manage versions?
<inserted> sebastian: [TD Namespace]
dape: what we discussed so far is
reference to the latest version
... vs dated version
kaz: we can publish a specific
group Note for each version of the namespace
... e.g., https://www.w3.org/TR/wot-thing-description
vs https://www.w3.org/TR/NOTE-wot-thing-description-
20180101
sebastian: [TD Model Requirements]
... should be independent of any serialization format
... JSON-LD 1.0, 1.1, JSON, EXI, EXI4JSON, CBOR, ...
... TD model hsoudl be very clear and understandable by
developer that have different backgrounds
dape: will share my slides
... some ideas
... [Goal]
... identify suitable serialization foremats for WoT TD
... what is not a goal?
... [What is important for WoT TD format?]
... adaption in communities/platforms
... acceptance by Web developers, embedded developers
... data exchange size
... processing speed, requirements
... royalty free
... free/opensource implementations?
... collect ideas?
sebastian: opinions?
cabo: for embedded
environment
... should be interesting original requirements
dape: interested in what "processing" means
<cabo_> ... enable in-place processing
dape: [Possible Candidates]
... text-based ones vs binary-based ones
... JSON-LD, JSON, RDFa/XML
... EXI4JSON, CBOR, Smile
matthias: might want to say "constrained or not"
dape: 2 different use cases
... target to Web developers on the left side
... and embedded developers on the right side
... Web-friendly or traditional
sebastian: possible additional
category
... semantic web developers
matthias: let's have a list
... and then could sort it
sebastian: possible to support all of
them
... should we make examples?
kaji: agree
... first creating categories
... and then think about priorities
dape: somewhat tricky
... [How to do an evaluation?]
cabo: usual way in the past
... coming up with a benchmark scenario
... do the data model in the serialization required?
dape: size and processing
cabo: size is an interesting
property
... but optimization as well
sebastian: how would you measure that?
cabo: not necessarily quantify
sebastian: comments?
... make sense to find some use cases and test beds?
... different sample TDs
... also some benchmarking
dape: wa're targeted more on embedded purposes
sebastian: Dave is not here but he had a proposal
cabo: more in favor for
exposing
... explicit rule for interchange
dape: updates the slides
... creat embedded test-bed
... check conversion from/to Web to embedded format
... we could start with something simple
... TD files could do some initial things
sebastian: make sense to set up a test bed
dape: mix of TD complexity
cabo: 2 different
objectives
... 1 is having examples
... structured element
... 2 is realistic examples
... various functions
... no need for benchmark for the coverage part (=#1 above)
sebastian: could have examples from OCF
and/or oneM2M
... different kinds of examples
sebastian: any volunteers?
... maybe Daniel and Carsten?
... everybody who participates in PlugFest provides their
generated TD
dape: as a starting point, can we collect TDs?
sebastian: information at:
https://www.w3.org/WoT/IG/wiki/F2F_meeting,_May_2017,_Osaka,_Japan#Participation
... Daniel, can you organize this work with Carsten?
dape: try to start
taki: processing TDs for embedded
devices
... how to find semantics
sebastian: we already have some
semantics
... any other comments?
(none)
kaji: all the sessions for today
ended
... tomorrow administration and next steps
... marketing and the next f2f
... originally planned till 5pm
... but would like to shorten till 3pm instead
[Slides]
[Technical Work day 2]
[Slides]
<inserted> scribenick: kaz
mccool: [Initial version of Threat
Model]
... [Threat Model]
... stakeholders, roles, assets, adversalies, attack surfaces,
threats, use cases, security objectives/non-objectives
... attack surfaces
... we have an opensource implementation
... hierarchy of trust
... different levels of trust
... [External References and Standards]
... if any ideas, please create an issue on GitHub
... External references
... industrial internet consortium security framework
... IETF ACE, RFC 7252 (CoAP) security model, RFC 3552, RFC
6973, STRIDE Threat Model, OWASP IoT Attack Vectors, IoT
Security Foundation, FIPS and other national standards
... Liaison references
... OCF 1.0 Security spec
... oneM2M security solutions, OPC, Echonet, BACnet
kaji: can we add even more references?
mccool: see pullrequest 319
kaji: emotion technology
consortium
... btw, what would be the concrete methodology for the
security discussion?
mccool: shows [Process]
... opensource implementation
... also clarifying requirements
... 1. threat model, 2. scoping, 3. state-of-art, 4. solutions,
5. implementation and evaluation
nimura: regarding attack surfaces
mccool: protocol bindings execution boundary
nimura: distributed way
... with multiple WoT servients
mccool: multiple instances and
bridges
... should clarify what would be in-scope and what would be
out-of-scope
dsr: single system here
mccool: WoT is basically a
bridge
... very important to be secure
nimura: use cases?
mccool: e.g., smart homes
... gateway as a firewall
kaz: the final deliverable would handle safety as well?
mccool: mainly security and privacy but would see the charter
[Slides]
nimura: [WoT Stack]
... also [Role of scripting API]
... discussion on the management interface
... will update the rational document with the WoT stack
diagram as well
kaji: registration of the WoT
servient?
... possible need for a specific servient for management
purposes
nimura: shows the slide on synchronization
[Slides]
sebastian: TD core model, TD lifecycle,
semantic annotation in JSON Schema, ...
... [Set this TD Model as Baseline]
... shows the basic TD model and sample instances in different
formats
... JSON-LD vs JSON
... [TD Lifecycle]
kaji: proposed to introduce
additional operatons like "@remove" and "@include"
... to modify/update TDs over its life time
... collaboration with the JSON-LD team
dsr: similar topics for the API side as well
yongjing: dynamic modification or kind of static?
kaji: modify attributes
... e.g., when copy existing attributes, maybe don't need part
of them
... also variation of products like air conditioners
... basic template and various additional features based on
each product
... mainly thinking about lifecycle of products
dsr: possible live update
kaz: possibly update the OS or library weekly?
kaji: yes, so related to scripting as well
sebastian: [Missing Thing in JSON
Schema]
... long discussion
... keep collaboration with the JSON Schema team
... reuse JSON-LD keys such as @context and @type
... would ask Dave and Yongjing to join the discussion
... [TD Serialization]
... TD core model could be serialized using various
formats
... separation between text-based representation and binary
one
... maybe should select one default text rep and one default
binary rep
... but don't invent new serialization formats
... evaluation of binary versions (e.g., EXI4JSON, CBOR)
... how to evaluate?
... Daniel and Carsten are volunteering
yongzing: we should support all the possible formats?
dsr: how to work with broader
communities?
... need to have a plan for that
dsr: relationshp between
interaction models and semantic models
... scarable approach based on commercial reality
... need for bridging ontologies
... valuable discussion and working on a plan for a roadmap
with clearly defined short term goals
sebastian: TD related to the semantic model
mccool: bridging multiple
standards
... mapping of concepts for transformation
dsr: don't think there could be a single mapping
mccool: model for some given
standard
... maybe need for an abstract model for IoT
sebastian: motivation of this mapping?
dsr: different vendors may have
different models
... need to allow bridging different models
mccool: there are ontologies out
there
... could have a common ontology and mapping to that
yongjing: the mapping itself is not in our scope?
sebastian: this TF is working on that
dsr: this is a TF of the IG
side
... not for the standard work
mccool: we should have some concrete
example
... possible output is about what should be added to TD
dsr: slides available from the agenda wiki
kaz: related to the discussion on
TD vs protocol binding
... TD should handle abstract semantics and protocol binding
should handle concrete information on the device level
mccool: but the separation is not that simple
matsukura: [WoT Servient
architecture]
... 2 types of applications
... [Discovery and Provisioning fro device]
... [Example diagram for sever-client]
... one servient on the gateway
... and another servient on the cloud side
... [Device registered to master repository]
... will continue the discussion and clarify the
requirements
yongjing: thought we had 2
approaches
... will support both?
matsukura: yes
[ morning break ]
<dsr> We also need to consider peer to peer approaches for fully distributed repositories which can offer greater security, e.g. against denial of service attacks.
[mornin break]
[Slides]
<dsr> scribenick: dsr
Michael McCool as the session lead.
(slides to be uploaded later)
Outline: discuss process and goals, gather/brainstorm, prioritize, derive requirements and incorporate into our plan. An example is the security objectives.
The goals: use cases as a basis for justifying specification design choices
Use cases for mindshare and building a concrete understanding, e.g. as a basis for recruiting new companies to help with work on standards
This needs concrete and compelling examples.
To drive requirements and test cases we need a range of use cases.
There are two broad axes: one is technical and the other the application domain
On the technical axis: simple use cases to explore the data types, interactions and architecture
Complex test cases to test boundaries including pathological cases
Distributed use cases, multi-device use cases, lifecycle use cases, different audiences, etc.
Including real time and streaming.
Example contexts: application domains such as smart Home, smart Building, smart *
We need examples that explore the use of contextual information richer semantics.
Other dimensions: simple to complex, local to global, trusted to untrusted, number of devices, number of ecosystems, asynchronous (deliver whenever) vs Synchronous real-time delivery
Lossy vs guaranteed (transactional)
My expectation is that we should start at the easy end of this multidimensional space and then expand along some key dimensions.
Issues to test: dependency chains, distributed race condiitions, translation of information, and possible loss of meaning and capabilities.
Performance and so forth.
For the smart home: connection of personal devices owned by a family (need to develop personae)
Some devices installed in house, some owned by family some by individual family members.
Assume that there is a firewall with a wifi network, and a gateway/hub that has capability for computation and storage, e.g. acting as a bridge and small services.
Some scenarios: onboarding a new device, controlling a single device, services coordinating multiple devices from different ecosystems, family member moving to new household, visiting guest need access to a subset of devices
Yesterday, Barry talked about some interest scenarios we should look at.
For smart cities: a constellation of smart buildings as well as city infrastructure.
System integrator that combines systems from different manufacturers.
Need for large scale monitoring and maintenance
etc.
The smart factory context involves a combination of IT and OT (operational technology), including strict requirements in respect to safety, reliability and so forth.
The need to address brownfield systems, pre-IoT OT systems.
The need to enable data driven decision monitoring of devices and processes.
More background available from the Industrial internet consortium.
Barry: we could take forever to think about use cases. It would be a good idea to constrain this by considering how use cases change what we think.
Is our goal to list the use cases on the website for internal use or do we want to publish them for external consumption?
Michael: we already have several external bodies working on use cases, perhaps we can leverage these?
Dave: I see a need for a small set of polished use cases for marketing materials in addition to those we use internally for technical guidance.
Michael: we need to decide on our key values and how we can show and explain these to others.
Barry: having simulated devices can be really valuable for ease of demonstrations
Michael: the benefits need to be really clear.
Sebastian: use cases can help with design choices in the architecture, e.g. thing to thing, thing to cloud
I think we can look at smart city use cases from the BigIoT EU project
This includes some automotive use cases.
Michael: we’re trying to enable larger ecosystems that span multiple standards
Smart cities could be fruitful in that regard
Kajimoto-san: what guidelines should we adopt for describing use cases, e.g. the granularity
Sebastian: in the early work of the Interest Group, we rapidly switched to focusing on atomic use cases.
Uday: we should consider use case scenarios involving a handover of domains
e.g. home, workplace and city
Importance of focus and prioritisation
Michael: perhaps we could survey existing use cases and identify a taxonomy
So an action on studying existing use case collections and identify use cases where the web of things would add value.
Another action is to take our key value(s) and brainstorm some example use cases that demonstrate it, and then build the corresponding demos.
<mkovatsc> http://w3c.github.io/wot/wot-ucr.html
<mkovatsc> https://github.com/w3c/wot/tree/master/ucr-doc
Dave: one idea is to make simulated deviced available by our member companies for use in demonstrating the power of the Web of things across ecosystems.
Michael: we could also support online information on how to download and install demos, e.g. onto a Raspberry Pi.
Likewise, we could make it easy for people to download and run simulations.
Some companies could offer evaluation kits
We could collect, maintain and publish a large collection of use cases — however that would be a lot of work.
Kaz: do we want to have an internal collaboration within W3C, e.g. across groups with demos at TPAC?
Michael: yes, e.g. with the automotive and sensor group.
Dave: how about some short term goals?
Michael: yes, we should soon decide on what is and what isn’t in scope.
I would like to assemble a list of references to IoT use case collections
Secondly to work on the marketing needs
For security, we will need to describe what we’re looking for from use cases.
Michael: any volunteers for driving the collection of references for use case collections?
Kajimoto-san: I have some use cases I can offer to the group for consideration
Michael: we should aim to work top down rather than bottom up, so that can ensure that we’re efficiently addressing our goals.
I will put this up on Github and we can use the issue tracker to work on it.
scribe: . we break for lunch ….
[Matthias's Slides on the next steps]
[Uday's Slides on the upcoming Dusseldorf f2f]
<inserted> scribenick: kaz
matthias: [Change for 2018?]
... issue: little time between f2f meetings
... slow progress in PlugFest implementations
... still very little at f2f time for TFs
mccool: security input
matthias: no other comments?
(none)
matthias: would go for this
... proposal only 3 f2f meetings in 2018
... and having regional+online
... [Dusseldorf f2f 9-13 July 2017]
uday: give explanation
uday: airport concress
center
... accommodation details to be followed
... f2f wiki will be created shortly
matthias: deadline for registration?
uday: not decided yet
mccool: need deadline for logistics (food, party, etc.)
matthias: hosted by RWE/Lemonbeat
... 9-13 July
... 2months to work
... todos:
... populate wiki: hotel list, collect topics
... block rooms in nearest hotel
... open registration (Kaz to help)
mccool: network connection (cable, wifi)
uday: looking into that
matthias: check network infrastructure
of the venue
... usually I bring a wifi router
... got inquiry from possible attendees for OpenDay
uday: when would be the
OpenDay?
... possibly Sunday for PlugFest preparation and PlugFest on
Monday
matthias: good to have demos on OpenDay as well
uday: half day on Sunday (afternoon) for preparation?
matthias: yeah, don't want to work the
whole Sunday
... btw, there will be the IRTF T2T meeting in Plague next
week
... 9-13 July (Sun-Thu; Sat-Fri IETF in Plague)
... [F2F Meeting November 2017: Burlingame, CA, USA]
... TPAC 2017
... 6-10 November 2017
... 4 months to work
... plugfest preparation: open space or room on Sunday
... plugfest: request full-day room or at least 3 hours on
Wed.
... plan observers/groups to meet
kaz: will talk within the W3C
Team
... about the PlugFest planning
matthias: joint meetings?
kaz: automotive, DAS, TV,
etc.
... will contact Chairs of those groups
matthias: accept observers?
kaz: yes
matthias: [F2F meeting spring 2018]
... in US?
... collocated with security conf?
...
internetsociety.org/events/ndss-symposium/ndss-symposium-2017:
San Diego, 18-21 Feb.
... ieee-security.org/TC/SP2017/index.ml: San Jose May)
... look at calendars
... IETF: London, UK, 18-23 March 2018
... OCF? oneM2M?
... todos:
... organize academic conf workshop (with T2TRG)
... will discuss in Chairs call
... good to have the ndss symposium as a fallback if we fail
the possible workshop
... [F2F Meeting Summer 2018]
... Asia?
... China hosted by Huawei?
... look at clendars
... IETF: July 22-27 2018 (SF)
... OCF? oneM2M?
... X months to work
... todos:
... consider visas
... companies from Taiwan?
... check alternatives in Korea and Taiwan
yongjing: oneM2M meeting in Asia 21 May 2018
matthias: moves it to "spring 2018"
... OCF meetings?
mccool: will check
matthias: please check your calendar to see
your schedule
... [F2F Meeting October 2018]
... TPAC in Lyon, France
... 22-26 Oct 2018
... look at calendars
... IETF: 4-9 Nov. 2018
mccool: for the Burlingame meeting
... IETF: 11-15 Nov. Singapore
... OCF: 6-10 Nov. Singapore
... no information on 2018
matthias: [WoT TFs]
... www.w3.org/WoT/IG/wiki/Roadmap
... OK to merge the Synch TF to other existing TF?
nimura: will check with
Matsukura-san
... he was planning to merge it
matthias: Architecture
... TD
... Scripting API
... (shows the roadmap wiki)
... Synchronization and Management included here (=Scripting
API)
... Binding TEmplates
... Security & Privacy
mccool: should go to which group (IG or
WG)?
... possibly a separate GitHub repo
matthias: make sense to have a WG
deliverable
... but having a TF as an IG TF would be good to get inputs
... informative deliverable as a WG Note or as an IG Note?
... would like to make sure that W3C wouldn't create a new security
standard
... Binding Template: get input from OCF and oneM2M
... (visits the roadmap wiki again)
... green part is doen
... editors draft on GitHub
... graphical and RDF model of TD
... Osaka f2f
<inserted> ... pin topics are tbd
matthias: release candidate for WoT
Architecture FPWD
... start security review for the WoT Architecture
mccool: would like to start that
... IETF guidelines should be included
matthias: RC is candidate for release
... note that finish security review for WoT Arch with Internet
Drafts
... security concepts
... other RCs for FPWD drafts
... further topics to be discussed later
<inserted> scribenick: taki
Yongjing: I would like to contribute
OneM2M binding to TD.
... Examples are in JSON formats.
[Slides]
McCool: More people need to be
involved from those organizations.
... What is the key message about our value.
... showing "messages" from 5/17 minutes...
... How can we evaluate good message?
... Who we are targeting... Decision makers. ( business
person).
... We are not targeting consumers.
... Trying to connect audio...
... Testing, testing tesing...
... Criteria about message.
... I listed goals. Give meesages to audience.
... They have to agree with us.
... How thimgs are differemt.
... They have to engage with us.
... Messages must be simple.
<naomi> +1 > must be simple
McCool: It is all about simple
message, and repeat again.
... no jargon.
... You want to target one level lower.
... avoid confusing words. data model.
... for example.
Sebastian: JSON, XML are also maybe confusing.
McCool: You want to communicate
concepts people already know.
... Key message. One key idea. Whats the one thing?
... I looked through. Key ideas.
... I saw Interoperability between multiple standards...
MM is going through the list "key value cadidates" in the slide...
McCool: Expand eco-system....
... Not crisp enough. We still have time. In Github, I can
upload.
... I can create pull request.
... It is gonna be public, we have to be careful. can make
private.
... As far as further discussion. Web presence.
... reinforces message, is important.
... Web presence and presentation, should be nice clean.
... Communication meeting. I try to get presentation
template.
... Simple, practical template is what we need/
Matthias: When do we get good
example?
... When do we get it applied?
McCool: This is difficult.
... I have been doing two months.
... We need some more proposals.
... By next meeting, less than a meeting, let's prepare for a
proposal.
Matthias: We need to allocate time, or hire marketing people.
McCool: We could try to ask for intel marketing people help.
Matthias: Let's make a good concrete plan.
McCool: This is all on record, let's continue.
Matthias: We use various content
management.
... Dashboard in WG page.
... So much text.
<kaz> WoT landing page
Matthias: It has to be concise.
McCool: Content system is one
reason.
... We need to make some good proposal.
... Make sure the very first thing in each page points to this
page.
Matthias: We can even use static
system...
... We need simple landing page.
... People should be able to be focused.
... Kaz, can we change content management system on WG landing
page?
<kaz> WoT WG page (managed on GitHub)
Matthias: This is not good for
marketing... Three pages has inconsistent information...
... As fast as possible, correct structure.
McCool: Landing page, someone is maintaining upcoming pages...
Matthias: Sometimes not updating.
Kaz: I will talk to W3C comm team.
Matthias: We could open issue in github IG space.
<kaz> ACTION: Kaz to talk with the W3C Comm Team about the landing page [recorded in http://www.w3.org/2017/05/19-wot-minutes.html#action01]
<trackbot> Created ACTION-105 - Talk with the w3c comm team about the landing page [on Kazuyuki Ashimura - due 2017-05-26].
Matthias: Or, do we need steering team?
McCool: every month, we used to have WoT Comm TF calls.
<kaz> WoT WG repo
Matthias: It is now part of main call.
McCool: yingying, naomi should be
part of the discussion.
... We can find out where information on page is coming
from.
... We can also poll.
... Remove page? Redirect better?
... Change content management, etc.
Matthias: Dave had opinion before. But he already left today...
Daniel: I had similar question
several weeks ago. Dave said content is sometimes duplicated
with multiple pages. It is difficult to maintain.
... We may want to converge them together.
McCool: Let's separate out what we
want.
... Having a single page, clear messaging.
... Let's get a meeting with marketing people.
Matthias: We need something
concrete as a result.
... We need to check whether it complies with W3C policy.
McCool: WoT, WoT IG, WoT WG, same look and feel is an objective.
Matthias: What are we telling
people.
... and design page accordingly.
McCool: Get organization done.
... Then content.
Matthias: Let's see if there is
any objection.
... With regards to policy.
McCool: We wanna say clearly and concisely what's our value.
Matthias: Can Daniel help?
Daniel: Sure.
Matthias: can't hear, naomi
<naomi> sorry to say this but w3c does't accept members directly to modify, write, update w3c pages so I'd like to collect your "raw" voices to reflect to our marketing materials. I don't recall marcomm had a place to hear voices from groups in the past.
Kaz: W3C doesn't allow members
directly update these pages.
... Naomi-san says.
... Yingying and Dave are organizing TF. TF and comm team
should work together. would like to talk with the W3C Comm
Team.
McCool: I want comm team active on this.
Matthias: concise, consistent
messages will stay stable.
... can naomi apply radical changes?
<naomi> Matthias, we'll change
<naomi> with hearing your inputs
Matthias: comm team can make private changes.
<naomi> exactly
Matthias: It also works.
... We will contact you guys.
<naomi> thanks Matthias!
Matthias: then please tell us what's allowed and what's not.
<naomi> wot groups++
Kajimoto-san: thank you very much
for cobtribution.
... Dusseldorf meeting is coming shortly.
... Let's prepare quickly.
... I hope you guys can go home safely, and enjoyed here.
... If you have a chance, it is good chance to go to Osaka
castle.
... Ohsumi-san also suggested to visit Kyoto.
Sebastian: I really enjoyed the
week.
... Very organized. Thank you for great food.
Uday: It was so such delicious
food.
... Thank you for hosting.
Kajimoto-san: Thank you.
[Osaka f2f meeting ends]