Day 2 -- 18 May 2017

OCF 1.0 Review: Changes from OIC 1.1, Swagger (OpenAPI) and introspection, OCF 1.0 security model - Michael McCool

mm: [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

OCF core spec

mm: 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://modelig-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

mk: this is not "OCF link" but "Web link"

mm: depending on CoRE

mk: core link format defined by some RFC

CoRE Link Format

mm: [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?

mm: 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

mm: WoT bridge which exposes TD
... binding to OCF protocol
... possibly on a gateway

yoshi: possibly OCF, oneM2M and WoT

mm: protocol binding discussion should handle a list of possible target protocols
... visits 01org/SmartHome-Demo
... Michael Koster will present his protocol binding proposal later

Thing Description: Data type with semantic annotation based on JSON Schema + TD Namespace - Sebastian

sk: [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

<McCool> p+ Michael_McCool

sk: https://github.com/w3c/wot-thing-description/json-schema-spec

dp: semantics could be edited using json schema
... Henry brought a comment

issue 309

dp: would respond to that
... last comment made one hour ago

mk: 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

bl: thermostat might provide time/date

dsr: we don't want to make small devices handle complicated semantics

dp: simple string might be useful in some cases for our plugfests

mk: 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

mk: 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

mk: number is not interaction
... important part is what kind of links/methods are used

dp: 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

mk: 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

mk: 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

sk: 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

Dave's 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

sk: 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

mk: 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?

mm: replacing JSON-LD with RDF?
... what do we use JSON Schema for?

yz: 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

sk: that's possible
... but how to handle additional information within TD?

mk: we don't have any specific semantic mechanism here
... we should fill the gap
... we don't want to start from scratch

bl: we're talking about 2 things now
... you can go with many levels of data

yz: if someone provides this kind of data model (on the left side)
... can't tell the semantics
... we should add additional semantics information

mk: agree
... need to provide unified way

sk: 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 ]

Binding Templates - Michael Koster

Michael's slides

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

RFC6690

koster: going back to 2 different formats
... [Batch Format]

mk: your implementation needs to know what OCF spec does here

mm: need to be more general thing

mk: you can look at this from technical viewpoint
... might be some specific options

mm: e.g., nice to have a CoAP level
... and OCF level too

mk: if we need to know the detail of OCF spec, there is no merit of protocol binding

<inserted> yz: who is in charge of the binding? refer to, e.g., oneM2M schema?

mk: media type is missing

koster: possibly multiple resource types
... might have some kind of state machine

yz: 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

yz: 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

mm: a WoT client should be able to behave as an OCF client

koster: that's one case
... another case is
... using consumeThing interface

mk: exposing a Thing to an OCF client might be difficult
... maybe need to think about on the next step

yz: 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?

mm: 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)

mk: would suggest we create an issue on the GitHub before starting yet another TF call

[Lunch till 1:30pm]

Thing Description (contd.)

sk: [Missing Thing in JSON Schema]
... [What we need in JSON Schema]
... key elements and semantic annotation
... "@semantic": "http://example.com/..."

mm: or add keywords to JSON Schema to point URLs

sk: this approach adding meaning of concrete instance as well

bl: 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

mm: unit and semantics

yz: not a set of RDF
... this could be multiple instances

sk: can be array?

yz: yes

mk: link to a number of linked data
... this is a linked data model

bl: Celsius/Fahrenheit information is part of the data but we need some more information

mk: temperature data may be described using kelvin as unit
... location (=at this seminar room) is possible semantics

sk: [TD Current Working Assumption]

mm: maybe you could pick up some key concepts

mk: this is extension to JSON-LD for semantics

mm: this is not actual TD but JSON Schema. right?

mk: this is not a good example
... so McCool has a question

mm: putting Schema into TD?

sk: yes

mm: so would have extension for JSON Schema

yz: what is your expectation? ontology or schema?

sk: want to introduce a tool to handle semantics in TD

mk: 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

mk: 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

mk: JSON Schema would be a good starting point
... this is a subset of what we agreed on

sk: shows JSON-LD Playground: http://json-ld.org/playground/
... getting more challenging

yz: 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"

}]

}

]

}

]]

mm: one option is adding keywords from JSON Schema to TD
... another option is adding custom types to JSON Schema

bl: "cvc" is just a number

mm: we need richer type system

bl: right

mm: use case discussion for tomorrow

sk: use case:
... servient 1 (weather station) just needs Celsius value

dsr: TD is abstraction and should be independent from serialization

mk: 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

taki: what is our scope?

mk: starting point is ok with JS
... input/output on the Scripting API level

mm: 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]

Scripting API: Management interface - Nimura

slides

nimura: [Behavior of management Interface]

zk: need to fix the figure

mk: 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

mk: quite similar to the management api
... what is the difference???
... why we need to create something new?

jhund: [slide 4]
... similar interface to other exposedThing

nimura: yes

mk: the red box "management api" accessible from outside
... TD describing the management thing?

jhund: 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]

jhund: 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/

WoT Runtime,Scripting, Bindings - Zoltan

zk: [WoT Scripting]
... do you agree this usage of scripting?

jhund: TD template pointing script is a new idea

zk: red line means script create things
... blue line means TD refers to script

mk: green "TD" has new concept
... green "TD" is usually something related to yellow "Things"

zk: agree

nimura: what about security with remote servient?

zk: same for all the servients
... who is requesting what
... runtime checks access rights

jhund: we have a manager thing
... allows us instantiate runtime
... and script execution context
... discoverable by local discovery

<mkovatsc> Tried to incorporate my understandings here:

<mkovatsc> https://docs.google.com/presentation/d/10xeircxLQzC7cOgArfMkxPMd1_kFjlQjiyan5zT-11k/edit#slide=id.g223c523f22_0_224

jhund: 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

mk: 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)

Matthias's update

zk: better figure

mk: better to iterate discussion on this kind of picture

nimura: do we have one single event loop?
... or separate multiple loops?

mk: safe to share the same event loop

nimura: how to protect the context?

mk: no need to expose to the outside
... same owner of the device, then no need for separation

zk: we should come with updated slide set
... and update the rational document

mk: +1
... having an accurate picture is very important
... relationship between boxes

zk: yes
... we can start with Matthias's diagram on Google docs

jhund: ok

nimura: btw, we were talking about synchronization as well
... how to deal with that part?
... e.g., using a 2-runtime model

TD Serialization - Sebastian

TD namespace reserved

sk: how to manage versions?

<inserted> sk: [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

sk: [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?

sk: 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

mk: 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

sk: possible additional category
... semantic web developers

mk: let's have a list
... and then could sort it

sk: 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

sk: how would you measure that?

cabo: not necessarily quantify

sk: 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

sk: 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

sk: 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)

sk: could have examples from OCF and/or oneM2M
... different kinds of examples

sk: any volunteers?
... maybe Daniel and Carsten?
... everybody who participates in PlugFest provides their generated TD

dape: as a starting point, can we collect TDs?

sk: 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

sk: 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

[ day 2 ends ]

- DRAFT -

Day 2

18 May 2017

Attendees

Contents