WoT IG F2F -- 21 Apr 2015

<dsr> we have the registration info, and Siemens will have a complete list

<tidoust> scribe: tidoust

Introduction

Joerg: [going through the agenda]

Smart control of washing machine

Dave: It's a smart power example. User wants to wash clothes, over night to reduce power cost. Washing machine has very simple user controls as you do not want to complicate things there.
... The idea is thus to deport advanced settings to a remote UI, for instance on a tablet.
... The machine has some ability to sense what might soon break, how many times it was overload. Privacy issue when it comes to sharing info with the manufacturer for warranty purpose.
... [going through the rest of the description on the Wiki]

Joerg: Questions or comments? Probably we will discuss the balance between use cases as proof points and whether it's realistic. Balance between future-oriented and realistic today.

Carsten: Once we start using these use cases, perhaps not this one in particular, it would be important to answer questions such as how many sensor devices does that require.

@1: @2

Joerg: We have to agree on the best way to use these use cases.

Automated shutters

Joerg: User controls the shades of shutters. Interaction with the light. The expected behavior is very individual. When devices are installed at home, there is a discovery challenge, and then the user must have some way to adjust rules. From the technical point of view, there must be automated means to create mashups between the things and web based information (e.g. daylight). Some aspects not considered [see Wiki], including installation and what happens if somethi

ng goes wrong.

Frank: combinaison?

Joerg: It might be interesting to really collect. I'm looking forward to seeing how we're going to use this use case.

Kaz: How to identify reviewers for each use case? In the Web and TV IG, use cases are reviewed, sometimes by 4-5 reviewers.

Joerg: True, I think it would be really useful to do that.

Kaz: A starting point might be to have one individual reviewer for each use case. Also it might be useful to have the name of the person who makes a comment next to the comment.

Joerg: Right. I try to have a list of inputs first, but that seems useful, yes.

<wonsuk> (use cases) Public transport info via physical web: https://lists.w3.org/Archives/Public/public-wot-ig/2015Apr/0037.html

Public transport info via physical web

Wonsuk: Many people in the room probably already know about the Physical Web concept by Google. When someone wants to share some info or service in a public place, he may install a beacon that broadcasts a URL.
... If the user goes to the place, the phone may pick up the signal and alert the user about the service.
... The browser then dereferences the URL.
... If may display bus information, tax service.
... It's just a hyperlink followed by some instruction about the service, very similar to a search engine in some ways.
... In case of a beverage machine, we can imagine that the user sees the menu, makes his choice and pays through his mobile phone. Lots of different use cases.
... One of the key considering issues is the security issue. If an attacker puts a beacon that broadcasts a URL to a malware Web site, the user could be tricked into going to that Web site.

Bernard: Could we consider this use case as a framework infrastructure environment and the other one as home automation. Does this one fit in transportation or generic infrastructure?

Wonsuk: Good question. This kind of architecture would be useful for home automation too.

Osamu: Very good point about authentication. We need some authentication mechanism. If using the home network, question is "what is a local network" especially when many devices connect to that network. So authentication is key.

Oliver_Pfaff: Let's assume I receive a notification on my mobile phone and I want to interact with that service. When doing that, would that be a direct interaction with the component or would a broker component be an option?

Wonsuk: Good point. Google users can filter which results appear near the top. In case of beacons, we may expect that devices can recognize the distance between the device and the beacon. That would make one of the important factors to sort results.

Johannes: Malware could be a problem. Physical Web allows anyone to post URLs everywhere. I think what is missing in the setup so far is some kind of user preferences to filter out what is not interesting.

Joerg: I would propose that you make some additional notes from this discussion, Wonsuk, so that we can come back to it. Can you be the maintainer of the use case?

Wonsuk: Sure.

Remote health monitoring system

<dsr> Such filtering needs to be context dependent.

Claes: This use case is about remote health monitoring. In this example, an old man has sensors to detect fall using accelerometers for instance.
... There is a server in the cloud, health facility server. The connection to the cloud could be Bluetooth LE, direct communication, 3GPP MTC, etc.
... Prior to everything, there is an authorization phase. A normal Web browser would be used for that.
... Looking at technical issues, lots of talks of IPv6 as each WoT device can have an IP6 address. [going through the list of issues]. We're investigating whether OAuth could be used for authorization.
... If we use CoAP, what are the impacts? Do we need a proxy?

Dave: What is 3GPP MTC?

Claes: It provides IPv6 mobile network access to IoT devices. Network experts in my company think it has a lot of potential.

Dave: How does that compare with LTN?

Claes: I do not know.

<dsr> LTN is an ETSI specification for low through put networks, which is a bit like a long range version of BLE

Joerg: It makes sense to capture the relevant technologies that you listed on your slides in the textual description.

Community-based Flood monitoring

Edoardo: Slides extend what I shared on the mailing-list on Friday.
... Flood warning systems are often based on blanket reports based on sensors deployed. It is important to understand things at the street level but infrastructure is not there. The goal is thus is to use a community-based approach.
... Things in this domain are either fixed sensors or mobile sensors (attached to a drone for instance). Mobility aspect is potentially interesting.
... These sensors use low-power radio technologies.
... There are gateways as well, which you need to monitor as well.
... Then there are other things that you want to monitor such as rivers and canals, roads and railways, geographical areas, buildings.
... I'm just going through a broad list of things that are important to the use case here.
... What can be made smarter?
... We can understand correlations between events, improve accuracy, etc.
... The use case touches upon different domains, transportation of course, business, climate as well.
... Are there solutions today? There are sensors but they are very expensive and expensive to run as well.
... [going through interaction between things]
... Many stakeholders are involved in the use case, starting from the general public, but also media to report accurately on such events, local authority to organize response, etc.

Joerg: what is interesting with this use case is that it is a real-world use case. Quite helpful as it provides lots of background information.
... Could you merge the slides with the textual description?

Edoardo: Yes.

Joerg: It's clear that it originates from sensors, but defenses introduce actuators.

Edoardo: Lots of potential case studies. Monitoring is one, control of defenses another one. I'm happy to extrapolate if that can be useful.
... In a previous W3C effort, another person was curating the inputs provided. It proved useful, so I wonder whether a similar approach could be useful here as well. Just a thought.

Use case from the Waternomics project

Souleiman: Motivation for the user is to lower the water consumption.
... The user would set a monthly target and be kept aware of his consumption along with recommendations from the Web about best ways to improve consumption.
... First step is configuration. User has to set URLs to sensors, which are then registered with the home water management provider (POST request).
... The user can interact with the home water management service to set the monthly target.
... Then the sensors push events (JSON-LD could be used for the data) to the service.
... The cloud service can do some aggregation logic at this step.
... The user can then check the consumption. Also note that the things themselves could interact with the service.
... Based on that info, the thing could communicate with the user to advise him to use another program for instance.

Johannes: You mentioned that main idea is sensing with some acting.
... Any further thoughts on automation?

Souleiman: I think that's an extension to this use case

@1: It could be used to postpone some actions based on actions that are already running at the same time.

@4: Looking at the application layer. The model of a tap continously pushing data on low-throughput networks. Throttling events might be needed.

Souleiman: I think that can be a part of the configuration phase.
... I wanted to touch on something else. Event producers and consumers are semantically coupled. The original rationale for decoupling was scalability. [going through a set of slides to introduce models]
... [mentions free tagging, a scalable way of tagging since users do not have to agree on tags, could be used for thingsonomy as well]
... [scribe confesses being lost]
... For the WoT IG, the conclusion is to have a minimal description of format and semantics but leaves freedoms for things and events descriptions to enable some sort of free tagging.

Joerg: Could you turn the use case into a textual description? I'm not sure where it stops to be a use case and when it starts to be the description of an application.
... Maybe it should stay high level.

[session break]

Background of Japanese participants

Kaz: Our goal is smart homes use cases for actual use. [presenting slides]
... Would a Smart Home TF be a good idea? This could discuss basic architecture, possible APIs. Common platform based on use cases. Several concrete ideas from Panasonic and Fujitsu.

Joerg: Any special request to take some action?

Kaz: We can talk about it tomorrow during the TF discussion.

<dsr> Horizontal technical requirements and vertical business sector orientation

Use case for Home automation and architecture

Takuki: I have been more invovled in XML technologies (XML, XML schemas, EXI) in W3C.
... For home automation, the goal is to make things more comfortable or more efficient.

<dsr> OpenADR - VTN (top node) VEN (end node)

Takuki: One example is OpenADR (originating in California but now deployed worldwide). Each VTN talks to VEN (applications).
... Application run on top of devices. That's one possible configuration.
... Another possibility is to have applications run on IoT devices.

<dsr> (http://en.wikipedia.org/wiki/Open_Automated_Demand_Response)

Takuki: In each case, those VENs have to support various protocols to talk to each other.
... [presenting schematic view]
... Applications need to be able to identify and operate devices through the intermediate layer of platforms.
... One important aspect of standardisation work is to enable the division of work: we can work on the device interfaces, on the application interfaces, or on the abstract devices interfaces.
... This is something important to keep in mind.
... I wanted to mention briefly that there is already one realted standard named ITU-T Y.2070 that has become a recommendation this year.
... It defines the overall architecture.

Joerg: The architectural discussion is interesting but should remain separate from the use cases discussions.
... I would propose to separate things here. One part on the use case. A second part on the architecture.
... I think Dave has some parts in his slides, you have some, Carsten has some as well. It makes sense to bring them together.

Dave: It relates to IG deliverables. One on use cases, one of the architecture.

Joerg: Would it make sense to have a breakout session on architecture design?

Takuki: Yes.

Easy connection between smpartphone and peripheral devices

Kazuaki: The use case is house calls by caregivers. Patients have their own devices and can report them to back-end reporting services.
... In that case, the goal is to connect automatically the mobile phone and the back-end service.
... It is important to have building blocks that are OS-free and device-free, both for device drivers and for applications.
... Right now, connection requires dedicated applications for each type of device, leading to development costs and cumbersome user experience who has to download the application which we'd rather avoid if possible.
... What we think is needed: a Web-type driver architecture, and device plug and play manager to handle discovery and dynamic driver distribution.
... It would make everyone's business easier.

Claes: What you consider as device drivers, how do you define drivers? From the perspective I'm thinking, we need basic connectivity in the smartphone, e.g. Zigbee, then protocols on top of that.

Kazuaki: I think you're talking about the connection to the Wifi network. We need access from the browser.

Dave: exposing that in the browser seems to trigger security issue. However doing the same thing on gateways or other devices might be a better idea.

Carston: you need authorizaton, access control to devices. You really have to look at all the ends of the authorization space.

<dsr> [access control on resources]

Johannes: You also mention the upper side. I think we can broaden the scope to more than phones there. The goal would be to specify APIs to that developers do not need to care about the device model.

Joerg: 4 elements. The use case you started with. It's important to capture it. Then some discussion for tomorrow on device driver to define that. I'm not proposing to start a generic term definition section but to define terms when they arise.
... The security discussion. How to deal with security question? To my understanding, this is some kind of take-care task. It can be part of the building block discussion.
... I think it would be worth to work further on these points.

Oliver_Pfaff: I wanted to suggest that this should not be captured as free text but rather as a bullet list.

Edoardo: Axes for use cases with a matrix of requirements, to be able to strike use cases when requirements are already in the matrix.

Joerg: The security primitive approach is worth exploring.

Home automation

Kazuo: I made a presentation yesterday about home automation.
... It think some of the requirements make assumptions on the architecture.
... We already have many IoT organizations worldwide.
... Scheme, framework and semantics fit well in W3C. Home network approach has many regional organizations (Echonet, ZigBee, AllSeen Alliance, Smart TV Alliance, etc.)
... Then OS, Platform approach: Thread, Apple HomeKit, Smartthings, ARM mbded, most in the US.
... For applications: Home Connect, iControl, Control4, HomeChat
... [presenting a matrix crossing organizations and players]
... For UX devices, the application/cloud interface is type 1, with several organization working on that, including W3C.
... However, devices do not necessarily support HTTP so some sort of interfaces are required to bridge with the cloud of virtual thing representations (Type3) and with underlying devices (Type4).
... Another possible direct connected architecture would have the client HTML5 device directly access peripheral devices through relevant APIs (Type2).
... I'm wondering which approach to use.

Joerg: We will have some additional contributions in the upcoming session this afternoon.

Dave: We have different slides, we need to compare them with each other.

<dsr> compare architecture slides and work towards a common architecture

Day1 - PM1

Universal discovery and control of smart home devices, Robert Kleinfeld

<kaz> scribenick: kaz

robert: use cases on universal discovery and control of smart home devices
... attach beacons with physical devices
... discovery of devices
... interact with devices
... BLE, mDNS, UPnP and SSDP
... via IoT gateways, etc.
... access control and authorization
... device spam
... next step is how to build the mashups
... ideas on discovery
... generic approach for discovery
... regardless of network protocols
... also entire architecture
... how to make devices from different vendors interact with each other
... dedicated discussion on discovery during the breakout session

Joerg: comments?

ken: agree we need such discovery capability is the basis for home automation use cases
... devices and users are located within a specific local network regarding home automation use cases in Japan
... but these days remotely connected devices are started to be considered

robert: not only discovery for a local network but for that kind of situation as well

dominique: there are many technologies for discovery

<dsr> [discovery where devices may be on wifi, BLE, cellular network etc]

robert: this is a middle layer
... how to bring this later to the reality
... Google physical Web project is related to mDNS

claes: bluetooth?

robert: to support both

carsten: authorization
... discovery needs to be authorized

robert: right

crsten: IoT devices for home area were simple so far
... that is problematic
... children at home might want to use the system
... need to give a way for authorization

ph: wanted to note that we have a work on discovery within w3c
... have you checked it?

<dsr> [discovery authorization is related to privacy]

robert: not yet

Joerg: comments?
... quite an interesting use case
... two notions

<dsr> [DAP WG old work on network service discovery]

Joerg: probably available for multiple domains
... tightly covered by domain use cases
... important to link this with domain use cases
... how to proceed?
... might want to have a matrix for that purpose

robert: ok

Considering Fast Moving Consumer Goods in the Web o Things, Dominique

(2: 100% sciences)

dominique: what's interesting is there are things which are not really "electric"

(3: on the Internet, nobody...)

(5: What IoT really used to stand for...)

dominique: would think about that

(6: Sales of potentially connected objects, 2013)

(7: USE CASES)

dom: fast moving consumer things
... one day or one month

(8: Smarter homes)

dom: laundry liquid talks with washing machine
... many companies implement this kind of things

(9: A smart fridge - no, really!)

dom: this could happen if all the fast consumer things have ID

(10: An even smarter fridge!)

dom: fridge reads the data

(11: Smart insurances)

dom: what if you could register all the things?

(12: Smarter products)

dom: smart bottles

(13: BLE, Physical Web and iBeacons: FMCG discovery)

dom: coke bottles and physical web

osamu: do you mean interaction with EPC network?

dom: internet technology
... not necessarily Web
... transform proprietary identities to Web identities
... bring to the broader spectrum

dsr: the idea of Semantic Web

dom: very interesting

Joerg: you have a perspective of physical things
... identifying patterns would be helpful
... to understand this use case

dom: discovery is a bit different
... from normal IoT devices
... recognition of barcodes
... we embed URLs
... using NFC tags, etc.
... underlying technologies differ with each other
... how to retrieve the data and consume it?

Joerg: it could be used for smart things
... it would be helpful if you could describe the patter a bit more in detail

carsten: caring about the class of things
... and type of washing machine
... need to talk with specific instances

dom: some of them are not serialized while some are serialized
... things like cosmetics
... there is a special relationship

Joerg: use case from Martin yesterday
... smart devices which track indivisually

<dsr> [object histories with perhaps more than one persona per object]

frank: customers hate to install lots of apps rather just one

dom: need a specific serialization way
... for identification
... this is part of the discussion afterwards
... combining unique identities

<dsr> objects may have different associated meanings to different people, which opens lots of possibilities

Joerg: how we bring this into the shape for use cases?
... we're not doing only use cases
... we're interested in how to use them
... a proposal: not focusing on each use case, but think about a set of them
... steps with iteration
... to see if we're correct
... can we bring this to a document?
... and bring them together
... we talked about a matrix this morning

Document structure for dissemination of use cases, Johannes

jh: how can we disseminate use cases?
... actual structure

(3: Use cases are our reality check for technology picks)

jh: Why do we collect use cases?
... what technology is relevant?
... how to fit?
... appear in different use cases in different scenarios

(4: The future applications cannot be forseen now therefore we need reusable building blocks)

jh: Tim didn't have cat videos in mind :)
... different kinds of applications in the future

(6: Use cases and technologies are linked throught technological building blocks)

jh: same building blocks

(8: Examples for linking technologies, use cases and building blocks)

jh: how to do that?
... discovery: QR code, Pysical Web, UPnP, mDNS

(9: Examples for evaluating technology picks on the use cases)

table of UPnP, QR code, Pysical web and mDNS

jh: comparing use cases in the scenarios

(11: Document and Sources)

jh: W3C format
... document itself on Github

-> https://github.com/h0ru5/wot/tree/master/ucr-doc Github repo

jh: anybody can contribute to this
... and can make comments on the Github repo

(12: How to Contribute)

jh: go to the repo w3c/wot
... fork the repo to create your local copy
... add and commit your changes to the fork

(13: Questions?)

dom: one problem is rendering the HTML file

jh: you can simply commit your updated fork
... we could of course use some tool
... for more comfortable edit
... would take some more time, though

dsr: we already have an area for this IG
... would be useful to use Github to accelerate the group's work

jh: put some guides on the Github repo

dom: the main W3C repo as well?

Joerg: we have topics and matrix for use cases
... related to this document style
... this could be a possible solution

jh: Github usually have some issues

carsten: @@@

jh: can include HTML structure

carsten: probably as appendix
... issue tracker mechanism sometimes might be unclear

Alan: industry vs. technology
... kind of concerned
... huge opportunity space
... who is working on what topic

Joerg: most people in the room can imagine the urgency
... assume difficult to understand how to use this
... what is the value and benefit of the use cases?
... who is contributing the use case?
... we could finalize the issues when we've done the iteration
... right know providing use case itself is a bit vague
... hopefully we can finish the first iteration by June or July
... now we're having very broad discussions
... want people's input

dsr: what is the best clearest way?
... use cases across multiple domains
... the charter has a roadmap
... would have an architecture document

Joerg: this is a proposal to make progress
... if you have any concerns, please let us know
... we stay with email structure comments
... several people looking at them
... would ask for volunteers who look at this proposal

<dsr> the charter’s roadmap is now out of date and we need to provide a clear indication of the current roadmap along with a brief introduction to the web of things and matrix diagrams that relate use cases to capabiities, and technical building blocks to business sectors

(12: How to contribute)

Joerg: any volunteers from home automation use cases?
... taking care of contributions using this method?
... we try this

Kajimoto: (raised his hand)

Joerg: Johannes can help
... compare to use case discussion
... would like to start with two parts
... look at the schedule
... spend some time for collection of WoT landscape
... make sense to have an architecture
... who would participate in the discussion?

(many raise their hands)

Joerg: let's use 20mins to think about this
... would ask Dom to show some presentation
... also would talk during the breakout session
... could move synch from breakouts could be moved to tomorrow
... would start the discussion on architecture
... you all may have proposals in your mind
... would start with proposed aspects

dsr: can we print out posters?

Joerg: would go through different architecture aspects
... and see comments

dsr: would talk about how to make notes
... fundamental things like IRIs
... protocols

<JonathanJ1> https://www.w3.org/WoT/IG/wiki/F2F_meeting:_20-22_April_2015_in_Munich#Background_Materials

(Joerg starts to draw a picture on the flipchart)

Joerg: what kind of topology we have in our mind

carsten: high cost to upload properties to the GW
... would focus on the elements which fulfill our requirements

Joerg: we have constraints
... what kind of topology is available as step 1
... there are differences

carsten: not saying we should not discuss topology
... browsers use device drivers
... isolated with our requirements
... how to get this into WoT?
... certain minimum requirements
... hiding device drivers

dom: actually can convert existing device drivers to Web identities
... regardless of protocols

carsten: there is a difference between GW and Hub
... upgrading a proxy
... can translate between two different protocols
... cross-protocol proxy
... don't have to touch the proxy

dom: so we can translate between CoAP and Web
... CoAP is not HTTP
... if we want to translate it into HTTP, we need a proxy

Joerg: got important points
... different elements and topology
... things interacting with each other
... topology element
... this kind of topology pictures

dsr: each picture you draw has storage
... maybe need a bit different one
... would make it as simple as possible

[Web of Things Server] - [Web of Things Server] - [Web of Things Server]

that was the 1st diagram

2nd diagram

[Web of Things Server]-[WoT device]

+- [GW] - [IoT device]

<Claes> +1 for Dave's view

carsten: would revisit the 1st one
... resources?

dsr: Web of Things resolve resources
... may be Web pages

carsten: trying to understand the figure
... I don't have the URI

dsr: you could have it
... what do you want to put to this figure?

carsten: providing resources

dsr: resources related to what?

carsten: e.g., temperature of the room
... I'm not talking with device itself, I'm talking with resources

dsr: I'm talking about abstract things

osamu: is the "Web of Things Server" a new entity?
... we already have "Web Server" and "Web Browser"
... this "WEb of Things Server" is a new entity from that viewpoint?

dsr: yes

osamu: would know about the interaction among "Web Server", "Web Browser" and "Web of Things Server"
... can "Web Server" communicate with "Web of Things Server"?
... also can "Web Browser" communicate with "Web of Things Server"?

dsr: (@@@didn't cathch)

frank: a device might be connected with a module

dsr: (@@@2)

dom: you're talking about various protocols including HTTP
... when people ask me about what WoT is
... we need to know what we want to achieve

dsr: we have talked about various use cases

dom: HTTP is not hard to integrate with WoT

dsr: do people want to use XMPP?

carsten: archtecture doesn't care about protocols

Joerg: would interrupt
... how to deal with this discussion?
... need clarification on the 2nd figure

dsr: device might not understand Web

Joerg: multiple devices interact with each other?

<Claes> I strongly support Dave's view. We need to start as simple as possible with analogy with the existing web. Slide 3-8 in http://www.w3.org/2015/04/w3c-wot-framework-munich-2015.pdf should be the basis for our work.

Joerg: which ones do so?
... I'd like to follow up this one
... action for that

dsr: would see proposed architecture ideas and see the differences
... security model
... defining protocols

Joerg: how to achieve this?
... coming back tomorrow morning

richard: question on Web of Things Server
... between actual apps and devices
... what is the actual work?

dsr: need some kind of decoupling
... need abstraction layer
... watch, phone, desktop, ...

<JonathanJ1> I think we need clarify the terminology on WoT. What is "Web of Things Server" ? Isn't a Thing ? What is "WoT devices" ? where is WoT Client ?

carsten: physical details

Joerg: taking this as a starting point?

<cabo> Routers can be useful to abstract away physical details

<tidoust> scribe: tidoust

Kaz: Don't we want to think about requirements for this architecture based on the use cases first?

Joerg: I believe it might be worthwhile to discuss the architecture a bit to have a certain starting point. Then building blocks.
... I would propose to run discussions in parallel to some extent.

IoT and WoT

dom: Definition of WoT, goal is to create the most complicated way to switch a light on :)
... The WoT could be about bringing order by providing guidelines.
... What if we could just use Web protocols instead of various ones?
... Questions how do we connect things to the Internet? Already addressed to some extent. How do we connect applications to things is more interesting.
... Bridging the gap between Web and things should be our mission.
... My provoking definition of the Web: "If it does not speak JavaScript in the browser, then it's not really Web..."

Carlton: This is known as "Browser Web", not the entire Web, you know?

Dom: Yes.

Dave: Although we have made progress on background processes with Service Workers for instance, the Web in browsers is not designed to run 24/7, which we'll want to address.

Dom: Several aspects that we want to address in COMPOSE and other projects: programmable Web, semantic Web (really important), real-time Web (HTTP-only is not sufficient for some use cases), social Web
... Another way to look at this is to see that as clusters
... Level 1 is about access, with different technologies such as URIs, HTTP, WebSockets, NSD, etc.
... Level 2 is findability
... How do you discover things and understand what they are about
... Level 3 is sharing access to the different things, delegating authentication, etc.
... Level 4 is composition. What if we take these different layers and start to compose things using Node-red for instance.
... I wanted to put boxes to help us move forward.

Joerg: Thanks for these building boxes. We have something similar in the Wiki for the WoT framework.
... We need to come up with an understanding of these building blocks
... Is this list quite undestandable? Are there building blocks missing?

Edoardo: How do I combine these building blocks together?

Dave: We have different vocabularies. The Thing Description Language would have a specific content type.

Souleiman: If you know what thing and event you want to subscribe to @@

Dave: The real issue is query language but that's platform specific.

Dom: A simple way to describe things and their content, which we do in COMPOSE, is an interesting approach.

Dave: Yes, that's what I presented yesterday.
... Properties and actions, combined with a description of the thing.

Dom: It might be worth including the framework.

Souleiman: JSON-LD is a serialisation of RDF, so that's more a syntax problem. We could rename that part as ontologies/vocabularies.

Joerg: We need to focus on particular building blocks. The proposal would be to start with 3.
... Thing Description Language? [About 7 hands raised]
... Binding to scripting APIs and protocols? [About 6 hands raised]
... End user service creation? [About 2 hands raised]
... Discovery [9 hands raised]
... Provisioning and maintenance [4 hands raised]
... Ontologies and vocabularies [About 9 hands raised]

Dave: It's a question of best practices. Can you describe things in a way that allows real-time validation?

Dom: It's more or less linked with number one, right?

Dave: Not really. The framework needs a core vocabulary, but the goal here is to go beyond that.

Joerg: Top 3, Thing description language, discovery and ontologies. Probably overlap of people among these 3, so it might make sense to add bindings to Scripting APIs.
... Thing description language: does it refer to data modelling as well?

Carlton: There are several aspects to discovery. It can be about setting up systems, provisioning, about discovering things. I'm not sure that's the right package.

Joerg: There might be an overlap with the Thing description language indeed. A first step should be to scope each discussion.

Carlton: I have no problem with the breakout if they can decide to break up.

Joerg: Right. Tomorrow, we need to discuss task forces, so the more crisp the building blocks, the better.
... Back to breakout sessions.
... Thing Description Language: 9 people.
... Binding to scripting APIs and protocols: 9 people.
... Discovery: no one left.
... It's ok to focus on the first two already.

[session break]

[Breakout sessions]

Breakout session on API bindings

[summary to be provided]

- DRAFT -

WoT IG F2F

21 Apr 2015

Attendees

Contents