<inserted> scribenick: kaz

Tech welcome

mk: welcome to the 3rd meeting of the WG!
... would remind you of the W3C Patent Policy for the WG work as Kaz mentioned yesterday

https://www.w3.org/2017/Talks/0710-w3c-pp-ka/

mk: you need to become an official WG participant to make contribution
... we're taking minutes on IRC
... please help minutes taking

dsr: microphones are available

Agenda Bashing

mk: agenda bashing
... would like to start with Mozilla's contribution
... they've just made a Member submission
... after the morning break
... TD serialization
... open-source strategy
... won't go into the detail but the proposed agenda is available online

mm: maybe short summarization from the Osaka meeting?

mk: good to repeat what we discussed in Osaka
... we should talk together
... we go for single slots this time
... and then Day2
... security use cases/scenarios
... security next steps

dsr: can contribute to serialization today and data types tomorrow

mk: data types
... Victor?
... status, etc.

victor: maybe shorter than 1h?

mk: and the last day, Jul 13th
... security, Elena will join remotely

mm: threat model, etc.
... would like more input
... online questionnaire

<inserted> scribenick: mjkoster

mccool: has a questionnaire for security requirements

please fill out in preparation for the meetings this week

<inserted> scribenick: kaz

mk: please give your input
... next LD
... and in the afternoon, marketing topics
... and then modularization of TF work

kaz: planning session?

mk: right. TPAC, security conf., etc.

mm: for next year

mk: will talk with McCool offline as well

Mozilla's submission

https://lists.w3.org/Archives/Public/public-wot-ig/2017Jul/0000.html

http://iot.mozilla.org/wot/

mk: would impact our work

mm: important to consider this
... and other input from Members
... this proposal is descriptive
... here we do action, event, etc.
... need gateway and other things
... our work is different
... we should take this proposal seriously and think about the pros/cons

mk: let's look at this
... would have much more fruitful discussion from this
... could be discussed during TPAC as well
... straight description on what they want
... ideas on a possible default binding

mm: could be a default HTTP binding

koster: this is a concrete API

dsr: agree inviting them to give talk on this
... very similar with what I'm proposing

seb: 80% of this proposal is copied from what we've been doing
... related to the serialization discussion
... almost aligned with what we've been doing since 2 years ago
... this is a JSON approach

mk: this shows developers' hypothesis
... kind of JSON serialization option

mm: need some tweaks

mk: let's look at this

http://iot.mozilla.org/wot/#web-thing-description

mm: this is descriptive
... they're doing exposing thing

mk: we do both expose/consume
... they're doing another side of consuming

mm: they're using only expose, so simple

mk: if you look at "actions" here...

[[

v

"actions": {

"reboot": {

"description": "Reboot the device"

}

},

]]

mk: there is no detail on how to handle this yet
... it's a draft

dsr: good to have their proposal

mk: want to go through this

+1

mk: goes through 2.5-
... 3. Web Thing REST API
... defining resource type

Thing resource

scribe: example in JSON

mm: there is a "links" section
... shouldn't be in the example

koster: design in progress

mk: individual URIs and fragments to be concatenated
... 3.2 Property resource

http://iot.mozilla.org/wot/#property-resource

mk: doesn't really comply

seba: our approach is just using name-value pair

mk: would see RFC@@
... there are so many different IoT platforms

json interchange rfc

mk: we kind of got stuck with actions

mm: they have concrete idea

koster: expressing some intention we should look at this
... to see what the main idea is

mm: scripting API
... you could expose different APIs
... and this could be a default API
... we already had discussion when we generated the Charter

mk: network API could be REST API

mm: not conflicting

mk: identify actions and retrieve them

mm: websocket is another option

mk: there is websocket proposal as well
... goes down
... 3.4 Events resource

koster: our concept of "events" is a bit different

mk: 3.5 Things resource
... 3.6 Alternative Protocol Bindings

http://iot.mozilla.org/wot/#alternative-protocol-bindings

scribe: 4. Web Thing WebSocket API

http://iot.mozilla.org/wot/#web-thing-websocket-api

mk: easy coupling between the server and the client
... need to talk about protocols for various vendors, though
... how to open WebSocket, etc.
... establishing connection
... 4.2 setProperty message

http://iot.mozilla.org/wot/#setproperty-message

mk: here you have socket connection
... and 4.3 requestAction message

http://iot.mozilla.org/wot/#requestaction-message

scribe: then 4.4 addEventSubscription

http://iot.mozilla.org/wot/#addeventsubscription-message

scribe: 4.7 event message

http://iot.mozilla.org/wot/#event-message

mk: equivalent to the REST API
... wouldn't go deeper here
... 5. Web Thing Types

http://iot.mozilla.org/wot/#web-thing-types

mm: simple built-in vocabulary

mk: 5.4 Extensibility with JSON-LD

http://iot.mozilla.org/wot/#extensibility-with-json-ld

<dsr> Dave: we should also consider this from the perspective of what would be needed from a thing description to support the Mozilla IoT platform, given that the web of things needs to support a very broad range of IoT platforms

mm: having simple default Web API
... mentions OCF approach
... RAML and Swagger
... Swagger more momentum these days

mk: RAML and Swagger are tightly coupled to what the server is offering
... the key is loose-coupling

koster: big plus

mk: how should JSON serialization should be?
... concise and developer friendly way
... so that we can convert it to another serialization
... we saw a parameter of "actions" here
... there are patterns of property, action and event
... may need some interaction pattern

dsr: we have metadata for TD
... we have to live with driver model given existing various devices
... simple interaction model
... TD just has minimal information for drivers

mk: you can't model that simple interaction model

lindsay: do you plan to enforce some guideline?
... setting actions and write parameters, etc.

mk: there is a device with some property
... the other thing has reset button, etc.
... think about interaction between them
... layering on top of discussion yesterday

victor: this is already modeled
... e.g., for building automation services
... action on some property
... equivalent to changing property

mm: we need response from Mozilla

<mjkoster> victor: modeled in SAREF

mm: how to integrate with our document

mk: we have good questions about this proposal
... it's a complicated theme

mm: having an analysis would be good

mk: we'll have activity on JSON serialization
... and see gaps
... this is another IoT platform which we (WoT) would like to describe
... any other opinions?

mm: the other possibility is defining a simple default
... simple descriptive definition

mk: we won't create yet another standard
... our description should be easily mapped

mm: there is a definition on eventing
... could be a hybrid way

<dsr> mm: we should seek to make it really easy to provide a thing description for their platform.

kaz: this proposal is about interface between component, e.g., servient A and sevient B, with our context

mk: they don't have servient, so maybe gateway and client possibly

kaz: let's invite them to our telcos and TPAC f2f, etc.

<inserted> next

<inserted> mk: summarizes the discussion and defines the nest step

RESOLUTION: next step is (1) draft response to them by Thursday, (2) get JSON serialization TF which compare/integrate/extend Mozilla's proposal, (3) have a joint call with them and (4) invite them to TPAC
... go through possible responses on Thursday and let's invite them

[break]

Serialization - Daniel

slides tbd

dp: [TD Serialization test-bed]
... on github: github.com/w3c/wot-thing-description/tree/master/test-bed
... started to collect data from various sources: WoT CP document, PlugFests, SDO mappings
... [Measurements Osaka PlugFest]
... shows graph including the data serialization variations: JSON, CBOR, SMIL, EXI4JSON
... [Measurements Dusseldorf PlugFest]
... [Outlook]
... how can we improve even further?
... [Optimized JSON-LD Example]
... shows an example

(got a trouble with screen sharing...)

victor: devices are deployed somewhere not owned

carsten: shows his slides

slides tbd

<McCool> McCool: ways to reduce size: standard fields in fixed order; defaults; query parameters on API to get td (eg include semantic tagging only if asked)

carsten: [Objectives]

<McCool> McCool: regarding very small devices (eg SigFox) - might be best to return a simple identifier (eg a URL) rather than a TD; we want a TD to describe how to talk to small devices, but those devices don't necessarily need to generate or consume TDs themselves

carsten: represent TD information
... what do we want optimize? - compactness/usefulness for processing?

<McCool> McCool; BTW, defaults and multiple serializations also lead us to one possible way to align with the Mozilla/Evrything "prescriptive" network apis

carsten: what are our assumptions about the devices - holding TDs?
... [Maximizing compactness]
... use traditional data compression
... e.g., deflate, LZ77
... need some memory for decompression

<McCool> McCool: eg one particular choice of serialization (and the defaults in that serialization...) could end up looking a lot like the Mozilla proposal... but still could be serialized in a more explicit, expanded serialization that make all the default values explicit could still be available.

carsten: [Choosing a compressor]
... LZ77: sharing via <distance, length>
... need entropy encoder too
... classical algorithms: deflate (LZ77+Huffman), LZ4 (low complexity)
... [Maximizing processability]
... [Experiment]
... wot-thing-description/test-bed/data/plugfest/2017-05-osaka/MyLED_f.sonld
... JSON file: 3116
... JSON withoug whitespace: 1447
... deflate: 323, lz4: 415, lz4hc: 411
... CBOR: 1210
... deflate: 325, lz4: 416, lz4hc: 404
... CBOR packed (semantic sharing only): 793
... CBOR packd (prefix compression, too): 564
... 2 steps
... semantic sharin gonl vs prefix compression as well
... [Conclusion]
... packing (exploiting structural sharing)
... maintains processability, saves 1/3 (implementation not yet complete)
... prefix sharing helps with URLs, another 20%
... but reduces processability
... could further improve by adding static dictionary?
... in the example: 119 bytes of mostly static data
... name, type, links, application/json, outputData, mediaType, href, etc.

dp: ideas we can share
... get rid of static data
... different ways to achieve it
... questions?

mm: 3000 characters reduced

(Carsten goes back to [Experiment])

carsten: yes

mk: would go for easy processing, e.g., CBOR, EXI

seba: deflate-based compression would be useless, I think
... quite heavy to install on small devices
... what can be the maximum compression ratio is not the best question
... need some more clarification how it works

mk: TD includes set of property, action, event
... same way of having a dictionary

dsr: could do compression on Arduino, etc.
... but keeping battery down

dp: you need more memory for data without compression
... processing may be ok
... on a powerful device, it's worth trying

mk: we have deep dive on JSON and CBOR
... Mozilla proposal also mentioned JSON serialization

seba: what is the next step?

mk: we can collect examples
... people can present like Carsten too
... size of the representation, compression ratio, ability/usefulness, etc.

dp: which data should be used as the basis?

dsr: have some material on GitHub

mm: can do the discussion offline

mk: let's put the items on a short list

Open-Source Strategy

slides tbd

zk: [WoT WG deliverables]
... normative specs: WoT Arch, TD, Scripting, Test cases
... [Implementation(s) as Deliverables]
... WG Charter says under "Success Criteria"
... requirement for implementation experience
... [W3C Software...]
... [node-wot]
... should node-wot be a WG oss implementation?
... if yes, need to apply W3C license

mk: we've been contacting eclipse as well
... open source management in general
... possibly on eclipse foundation with W3C license
... we need 2 implementations anyway to make specs RECs

mm: do we need a resolution?
... implementation deliverable

dsr: proposed resolution given not all of the participants are here

kaz: also suggested that to McCool

mk: do we need to update our Charter?

dsr: don't think so

kaz: agree

zk: also talked with Anssi about this
... and the Chair can make decision

mm: the Chairs would recommend to make the wot-node implementation a deliverable of the WoT WG

Web of Things - Dave

dsr: [Developer Feedback]
... startups and SMEs
... [Current Practices]
... TD based on JSON-LD and JSON Schema
... some drawbacks
... [Mozilla Web Things]
... simple, obvious use of JSON for TD
... [My proposal]
... similar to Mozilla's proposal
... PoC server implemented with node.js
... tested against OCF, oneM2M, Echonet
... [Mapping JSON to Linked Data]
... property names treated as either predicates/names
... predicates mapped to RDF URIs via @context
... enumerations as JSON arrays
... short cut when you only need to state property type
... JSON object property reserved terms: types, properties, actions, events
... names must not start with "@"
... (shows GitHub repo)
... w3c/wot/proposals/dsr-td/json-to-ld-dsr.md
... www.w3.org/WoT/demos/td2ttl
... would group's review

mk: this is an example serialization proposed by you

dsr: yes
... (shows jsonto-ld-dsr.md again)
... "properties" is metadata
... acceleration is a name
... shows spec on what I'm working on

mm: good to have multiple options for serialization depending on the need
... could have a library for node.js

dsr: good idea
... so far quite flexible

seba: TD is generated automatically by servient
... why do we need to think about non-semantic-based TD serialization?

mk: we should think about different serialization examples
... there are proposals for serialization
... actual data is semantic data
... we need tools for serialization
... essential building block is still TD

mm: agree we should handle core TD model and serialization separately
... regarding another point that developers don't touch TD

seba: agree to need for easy structure for TD

mm: we need more concrete examples

mk: you have prototype
... some parts missing

dsr: idea here is extensible support for Linked Data
... generic mechanism for mapping JSON to LD

mk: but seems like you're reinventing JSON-LD...
... that is not good for WG discussion

dsr: the idea is that LD is underlying data model
... simple JSON it's simpler than JSON as a possible serialization

<mjkoster> matthias: how does protocol binding work with this?

victor: this is not 100% corresponding to what we've been doing
... can try to link it to our spec?

dsr: depends on which predicate is used

victor: compatibility with our proposals so far?

mk: we have a problem
... this is a different proposal than Mozilla's proposal
... there is no connection at the moment

kaji: agree with Matthias
... as WG, we should fix the spec asap
... and as IG, this is a new input for v2
... so would ask Dave to split this proposal from WG work
... this should be an input for IG
... we should be careful how to handle this

lindsay: interested in the problem space
... extensible exchange of metadata
... would be good to have a beauty contest (survey?)

mk: would wrap up
... we decide core model
... this is a model formally defined by semantic web technology
... e.g., JSON-LD is already a standard
... we could do some beauty up things
... there is still constraints with JSON-LD of course
... there is no concrete specification on serialization
... as Kajimoto-san mentioned this could be an input for next version
... concise serialization also possible
... let's continue the discussion tomorrow as well

kaz: purpose of this?
... who/how/where to use this?

dsr: consume thing and expose thin

kaz: e.g., between consume thing servient and expose thingg servient

[ lunch ]

cabo?

<dsr> scribenick: dsr

Binding Templates

<inserted> slides tbd

Michael Koster presents some slides setting out the background to protocol binding

The protocol binding refers to the information needed for a driver for the chosen IoT platform/protoocol

Shows a JSON example with protocol binding within a “links” section

Introduction using OCF as an example platform

Michael shows how @type can be used in JSON-LD to identify the OCF type for each property

In addition, there are fields for href, content-format, method, resource type etc. as needed by OCF.

Michael displays a slide the depicts two ways to intergrate with OCF. One is where a WoT application acts as a client for a thing provided by an OCF device. Another is where a WoT application provides a thing that is exposed to clients as an OCF device.

In otherwords, both providing and consuming things using the OCF standards

Discovery: enabling apps to discover thing descriptions containing given semantic constraints

Discovery could be supported in terms of WoT thing descriptions as well as in terms of the OCF discovery protocols

Sebastian: are you assuming CBOR?

Michael: you could use CBOR, but this is not specific to CBOR

Matthias provides his personal summary

When mapping from the interaction by apps to the protocol level, the mapping depends on the protocol. This could be very simple for JSON based protocol payloads

Dave: where is the IoT platform identified?

I would expect a link to a platform identifier

Zkis: we have properties, actions and events for the interaction model, do you see a reason for exposing capabilities?

Matthias: I will let Michael respond to that one

The same capability could be exposed via different interaction models

Michael: we could refer to a shared vocabulary for the capabilities

It could be useful to include this directly

Dave: this is really part of the semantic models

Zoltan: do we need standard vocabularies for capabilities?

Matthias: this is something from groups that define domain specific vocabularies, and not something we will do in this group

<DarkoAnicic> +q

Zoltan: an example is an on-off capability

Matthias: this could be used as part of a semantic query

Zoltan: how is this attached?

Matthis provides an explanation …

Darko: capabilities are essentially semantic annotations

<zkis> * DarkoAnicic please move closer to the mike

This is to be discussed

We need to look at how the annotation mechanisms

Dave: we need to distinguish interaction models and semantic models. The semantic models describe the capabilities and how a specific device implements these in its specific interaction model that may vary from one device to another

Not all apps will need the semantic models, so we shouldn’t require them to be included in the interaction model

Sebastian: such apps could ignore the semantic annotations
... what is the status of the node-wot implementation in respect to the OCF binding?

Kaz displays a slide by Kajimoto-san on a protocol binding building block

This has a protocol binding module that in turn binds to IoT platform specific modules.

Examples include oneM2M with JSON over HTTP, OCF with CBOR over CoAP, WoT with CBOR over CoAP, WoT with CBOR over HTTP, and WoT with JSON over HTTP.

Kajimoto-san describes his ideas for identifying the IoT platform, transport protocol, serialization format and security technology

He shows a slide with mapping from abstract operators to HTTP/CoAP Methods

Panasonic have been exploring some ideas for implementing this, along with the details for the thing description

Dave: the protocol and serialisation could be part of the platform identifier, and the operations could be implicit, resulting in considerable simplications in the thing description.

Matthias: yes, there is a choice in how this is done
... there are many web platforms, where the transformations are very simple

Michael_McCool: this could be a useful default, as a further means of simplifying the TD

Kajimoto-san: my approach is applicable to the Mozilla proposal

<inserted> kaz: right. that's why I also confirmed at the end of the morning session that Mozilla's proposal was about inter-component I/F

Sebastian: …

OCF Binding Prototype - McCool

<kaz> scribenick: kaz

mm: [Outline]
... goal is working perfectly at TPAC
... [Goal]
... consume OCF metadata
... output a TD
... attempt *automatic* translation of metadata
... for better scalability
... [Prototypes]
... ocf-bridge, ocf-generator and ocf-client
... different project for ocf generator
... also testing
... issue on name collision
... [Architecture]
... issues come from multiple places
... need to extract OCF metadata from multiple sources
... integrate instance metadata, type metada and OCF standard metadata
... how to get introspection
... which resource is actually useful?
... implicit in the spec
... most of them are currently encoded in my code
... some additinla hand-written metadata required per OCF "resource type" still needed
... annotation metadata
... would make it (hand-written part) as small as possible
... [Annotation Metadata]
... semantic tagging, which resourece types should be exposed?, which combinations of interfaces make sense?, actions/events, names and writable properties?
... [Annotation Example]
... currently doing some cheat and would like to gather information automatically in the future
... a bit different from what Koster does
... protocolCOntent shows mapping between protocol and data format
... [TD Example (one Interaction)]
... [Prototype Limitations]
... one complication
... extension mechanism of OCF
... doesn't handle multiple rt/if combinations
... including some unnecessary "OCF internal" resources in the output
... [Issues]
... [TD Example (one Interaction) - revisit]
... offline device joins the network
... [Suggestions]

<dsr> OCF device identifiers are dynamically generated each time the device boots

mm: protocol binding templates as strings
... separate template media type that can be converted to wire media type
... alternatives: make template always be JSON, get rid o template and make it equivalent to parameter map, e.g., make generation of payload the full responsibility oof the driver
... add additional "driver" parameter so that target device ecosystem, e.g., OCF, can be identified
... [Next Steps]
... update to intercept protocol binding protocol
... implement protocol binding templates
... implement oocf-gather to ingest existing OCF type metadata
... additional semantic annotation mechanisms
... pull request on node-wot
... try some other IoT standards
... [Conclusions]
... it's possible to do mapping automatically
... but OCF is relatively easy
... since webish
... need to repeat this exercise with additional standards

lindsay: would go back to some slide

mm: [Prototypes]

lindsay: have to have some software package?

mm: modular decision
... rather than implementing bridges
... you can use bridges
... consumes OCF TD
... generator is more online

<inserted> scribenick: dsr

Kaz: how to integrate this work with the plugfest?

Mm: ideally we would get this running with a variety of devices for the next plugfest

Matthias: we need to agree on the details for that

mm: more generally we need a translation, OCF is an easy case, so we need to look at a more challenging IoT platform

Matthias agrees

mm: we can say it is the driver’s responsibility to create the payload, so we can then drop the details in the protocol binding

Matthias describes how whether we use JSON or CBOR, we can keep the translation simple

mm: JSON over CBOR is straightforward, but for other cases the driver could transform from JSON to the on the wire format

mk: LwM2M is such an example

Dave: as we expand beyond REST, we will need a more general approach - an identifer for the platform and the associated metadata

mk: some of those platforms are migrating towards IP and REST

Sebastian: iot would be helpful to have a set of online devices that we can experiment with

mm: we can do that for OCF

using virtual devices.

Sebastian: we want this for a broad range of platforms

mm: if anyone wants to look at code and has any questiions please contact me
... I am thinking now about other platforms

LwM2M is a good candidate as it also uses CoAP, as is oneM2M

<inserted> [ break ]

IoT Marketplace

<kaz> scribenick: uday

Seba: Need standard way to deploy IoT capabilities
... there is also an economic perspective to IoT Marketplace
... describes the motivation and scope of IoT Marketplace

Philip: what other marketplaces out there?

Stefan: lots of marketplaces but none for IoT data

Matthias: should consider this while designing TD

Mccool: can distribute scripts, thing and data
... Bid IoT mostly concentrates on data but can share other oarameters to

parameters

stafan: cannot share code

Seba: need to setup a charter, what to be in the charter, licensing info, pricing info etc.,
... Describes the architecture
... marketplace to be aligned with WoT concepts, thing's metadata ...

Dave: idea to allow people to design services and instantiate it with specific devices, discover and consume these services. Then what kind of APIs doe we need to support that?

Darko: Most will be covered with the idea of recipies

Lindsay: description of data in the project called "Inspire"

<dsr> I very much support starting work on this and will also do my best to channel the lessons learned on IoT marketplaces that we learned in the EU Compose project on highly scalable IoT cloud based platforms

Kajimoto-san: Marketplace is a good idea, can refer to advertisement technology

Seba: software not in scope. Idea is to have semantic description to setup and interact with a service

Mcool: to limit the scope, search which connects to linked data- discovery

Seba: Marketplace is just a href

Matthias: could use manager thing mechanism

<dsr> Dave: there is a business opportunity for installable services, e.g. to install them on a home hub, perhaps from the vendor’s websiite or in the case of native apps, from Google Play or the Apple app store etc.

<dsr> so I respectfully think it would be a mistake to preclude installable services

stefan: discovering things is linked to TD

Nimura-san: missing point would be related security. How do we deal with this and also the payment?

<mjkoster> sebastian: download a servient component in the process of receiving a service

<dsr> Sebastian: the metadata could list preconditions such as services or drivers that need to be installed. These could be referenced and hosted elsewhere

<McCool> McCool: I think that a marketplace that just includes existing services and data makes sense to START; but it naturally leads to installable services

Seba: consumer has always to request the thing to get the data

<McCool> however, there are some preconditions to installable services: a secure runtime implementation that can run untrusted third-party code

<McCool> accomplishing that will probably require some collaboration with eg. OpenFog, etc.

Seba: should be complete independent of the protocol used
... who do we address: IoT Platforms, Cloud providers, Infrastructure providers

Dave: also add search engine providers

Seba: is WoT the right place?

Mcool: falls in general category of discovery, so in scope

<dsr> Search engines will be interested in indexing services advertised via metadata on vendor’s websites

stefan: as long as open issues in TD it may be early, but if TD is done then this might be the right time

Matthias: might be implications on requirements, good startting point if Big IoT could share their findings

Stafan: decided not to limit to things, want to deal with data from many things

Seba: most of the content is the same as current TD

Matthias: good to have pointers form project working for the future

Seba: its a bit early now, might meet after 6 months to move forward
... can invite e-commerce partner as well

Local device protocol

Mcool: could a thing access interfaces of the device

Matthias: how to handle local hardware is 1 year old discussion
... too big of a topic. Interaction to local hardware should also go through the thing.

Mcool: should we define standard local things?

Dave: W3C has experience with APIs which can be used

Mcool: GPIO thing accessible to the outside world is chaotic. Good to have it within the local network
... Can I put in examples in node-wot folder?

Matthias: defining various API should be marked in a branch

<inserted> scribenick: dsr

Dave: we can provide some guidelines, but we can’t preclude IoT platforms from exposing their own APIs (e.g. Arduino modules) locally to application scripts.

<kaz> WoT Stack

<uday> Kaz need some help with scribing

Michael and Matthias discuss the idea of some standardised local things

<uday> thanks Dave, please add what you can!

Matthias: as Dave mentiioned we could consider adopting the browser APIs for local hardware and seeing what we can learn from their approach to security and privacy

<inserted> scribenick: kaz

Kajimoto-san: [WoT Model Description and APIs]

<inserted> scribenick: uday

Kajimoto-san: explains two API concept. one for physical world and one for cyber world

Mcool: treat both physical and cyber things same, so we can have a common API

<inserted> scribenick: dsr

mm: the conclusion from the Panasonic F2F was to use things and thing descriptions for both

<inserted> scribenick: uday

Dave: what about arduino, rasberri APIs

Mcool: can wrap them to have access to the hardware

Matthias: need the API available everywhere, gets hard with individual APIs

Mcool: we need to make a list of resources

<dsr> Dave: we need to clarify our messaging: things provide an elegant means to wrap access to local hardware, but platform specific APIs are also going to happen, and will require care with security

Matthias: more important to document the learnings

<dsr> Matthias: the thing approach offers greater portability

<kaz> [ Tech Day 1 ends]