WoT IG F2F (Day 2) -- 22 Apr 2015

<dsr> scribenick: dsr

F2F planning

Joerg asks for feedback on the frequence of face to face meetings. So far we have talked about a Summer meeting and then to meet during TPAC.

Wonsuk: I agree with having an IG F2F before TPAC.

Johannes: F2F meetings are very productive, but they are quite an effort to set up. One meeting before TPAC would be fine.

Joerg: what about the F2F organization, should we follow the open day + 2 IG meeting days, or should we do it differently?

Carsten: IETF Prague could be an opportunity forge stronger communication with the IRTF groups.

Joerg: do you have comments on the organization of the face to face?

Carsten: at the IETF we have several kinds of meetings, e.g. WG meetings focused on progressing specs, research meetings, test fests and workshops.

The approach taken yesterday worked well.

Kaz: I am neutral and would like to hear other people’s opinions.

Edoardo: the open day was good, we might ask for posters next time.

This time not everyone got to see all demos, so maybe continuing the demos during the next 2 days could help with that.

Joerg: could we focus on the building blocks?

Edoardo: yes.

Dom: Plus 1 for another face to face before TPAC. The next F2F would be more concrete and should be very productive. I like the open day despite missing it. It would be great to have a plug fest and create some momentum for interoperability.

Claes: a Summer F2F is a nice idea, but July is the main holiday period in scandinavia. I would like us to use IRC for queue management.

Taki: I also support another F2F including the open day.

Daniel_Peintner: co-locating the F2F with other events could be a good idea. But maybe it is good to have the next one in America to make it easier for American companies to join in.

<kaz> s/people's opinions./people's opinions. personally think having the structure for this meeting is nice, though./

<JonathanJ1> +1 another F2F meeting before TPAC

Sebastian: for the next meeting, I would like to see one or two main topics e.g. security and framework and focus on just those. I like the idea of working closely with the IETF.

Joerg: I understand that a US meeting would be valuable to community outreach. On the other hand co-locating with the IETF in Prague (July 18-19) would also be valuable. The question is how to resource these?

The proposal is to have an IG F2F in early July in US west coast and a smaller group of use to also meet in Prague with the IETF.

Alan: the first week in July includes US holidays. The last week in June or last week in July would be better.

Claes: The last week in July is probably okay for me, but we should do a poll.

Joerg asks for show of hands for last but one week in July?

a good number of people.

Joerg asks for the last week in July with similar results, but a few more conflicts.

Joerg: the week starting 6th July seems the best overall.
... should we have 3 days for the IG or stick with 2 (following a open day)?

The proposal is July 7-9.

Next time we will aim to provide the agenda much earlier and invite comments.

Joerg: I would like some of us to meet in Prague to forge stronger links with the IETF.

Carsten: we would need to find a way for W3C to co-host a meeting.

Alan: we would need to ask within the W3C staff for precedents and possibilities.

<scribe> ACTION: Dave to check on possibilities for a W3C/IETF meeting at the Prague IETF [recorded in http://www.w3.org/2015/04/22-wot-minutes.html#action01]

<trackbot> Created ACTION-7 - Check on possibilities for a w3c/ietf meeting at the prague ietf [on Dave Raggett - due 2015-04-29].

Osamu: we could have a similar meeting at the following IETF meeting in Japan (the week after TPAC)

Carsten: it would be useful if this current meeting were to provide some guidance on topics on a joint W3C/IETF meeting, e.g. security.

Joerg: yes. we could perhaps get the task forces we’re about to set up to think about that.

Deliverables structure

Joerg reviews what we discussed yesterday. This includes freezing the number of use cases for now and focus on a use cases and requirements deliverable.

We also need to work on writing up the ideas on architecture that we’ve heard over the last 2 days.

The immediate step will be to circulate ideas and then freeze and write up.

The 3rd document would be on the web of things framework. The proposal would be to ask those working on the building blocks to contribute.

For the next weeks we need to review what we learned and then figure out the framework document structure at the next F2F.

Joerg asks if the framework break out can result in some new documents.

Dave: yes we should be able to do that (the session also included discovery and provisioning)

<robert> for sure we need such a document as i) common understanding of the Web of Things ii) roadmap for the task forces in the next months

<JonathanJ1> deliverable Plans in charter - http://www.w3.org/2014/12/wot-ig-charter.html#deliverables

<kaz> kaz: also we should think about how to manage issues and action items raised during this meeting. some groups use issue tracker and some use bugzilla for that purpose

Dave: for me the biggest uncertainty is around security and privacy, and we need to find time to study that.

<JonathanJ1> we can also use github as a issue tracker

Joerg: we need to have that discussion before we can determine what impact it would have on deliverables.

<JonathanJ1> https://github.com/w3c/wot/issues

Joerg: we have a couple of volunteers for the github use cases document. We ought to do the same for the building blocks, perhaps today for the architecture document.

<inserted> Joerg asks for

<Alan> i/Joerg asks for/Topic: Next Meeting Discussion/

Richard: a lot of the use cases have security requirements implicit, and perhaps the use case document should make this explicit. We should also look at current efforts elsewhere that we could benefit from.

Joerg: the question is how to organise work on security, and to ensure that this is well coupled with the other groups.

Are there volunteers to identity the security requirements from the use cases and building blocks groups. I am really concerned about having an isolated security group.

Carsten: the challenge is to identity the real problems and objectives and translate them into the language that security experts understand.

XY: we should aim to cover security in all of our deliverables.

Joerg asks for a show of hands. 8 people put their hands up to help with the security discussion.

Oliver volunteers to act as the chair for that group.

<Alan> rrssagent, draft minutes

The names of the volunteers include: Carsten, Soumya, Richard Bailey, Dom, Claes, Dave and Oliver.

Joerg: HP may have someone to contribute
... we will have 2 kinds of groups. The task forces and other groups that “take care” of some specific topic.

Edoardo: should we separate security and privacy or not?

Joerg: we should keep them both together for now.

Edoardo: please add me to the security/privacy group.

Joerg switches to discuss the plans for this mornings break out sessions.

Joerg: did we change our understanding of the building blocks?

<JonathanJ1> Report on Things Description Language breakout session - https://lists.w3.org/Archives/Public/public-wot-ig/2015Apr/0041.html

AA: we need to work on the purpose of TDL and how it would be used

Carsten: there is a bootstrapping problem.

<JonathanJ1> Protocol Mapping Break Out - https://lists.w3.org/Archives/Public/public-wot-ig/2015Apr/0040.html

Carsten: the same will be true for security & privacy. we need to understand cross cutting concerns

Joerg: I would propose an iterative approach approach with successive stages of cross group consulation to share understanding and identity topics needing further discussion.

Carsten: I would agree with that approach as it is what we have used in the IETF.

Joerg propose that we split into the same groups as yesterday afternoon for this mornings break out slot.

Use of teleconferences and other working practices

Joerg: I would propose we reduce the full group teleconferences and instead focus on task force specific calls.

Suggests having full group calls every 2 weeks.

Asks if we should continue with alternating the time slots.

Dom: there isn’t a satisfactory way to have a single time slot

Soumya: I would encourage us to have alternating time slots.

Joerg: could we just advance the time of the call by 8 hours each call?

Dave: I would need to check what the admin system can support.

Joerg: for now lets have alternating time slots every 2 weeks.
... any other issues in respect to the IG working mode [none raised]

<tidoust> scribe: tidoust

[group looking at "The Web as the Solution" diagram]

Carston: the term IoT device may be confusing if these devices can talk any sort of protocol.

Dave: the diagram is generic. Under the gateway, any sort of protocols can be used and will continue to be used.
... We have not decided to which protocols we want to define bindings.
... "Gateway" could be renamed "device abstraction layer" if needed.

Question: Do device-to-device communications fit in that diagram?

Answer: For device-to-device communications, the device would embed the WoT stack. But we need to look at specific use cases.

Question: Role of browsers?

Answer: Web browsers run Web applications and will continue to do so. The question as to whether they will have direct access to things is open.
... The same-origin policy restricts the number of scenarios that can be enabled, although CORS may help.
... Extending security properties of the browser is done very carefully. That takes time. We need very strong use cases.

Carsten: These diagrams are very confusing as there is a third dimension: the layer at which you're looking at things.
... There may be layers with routers, gateways, etc. It would be useful to see the details.

Dom: Example of Bluetooth. If Bluetooth API is implemented everywhere, sneaking might be easy.

Dave: I encourage people to look at the Bluetooth API Community Group in W3C.

romain: Shouldn't Web of Things server rather be Web of Things agents? Do you agree that protocols may not always be HTTP or WebScokets.

Dave: Yes, the only point that I was trying to make here is that you need some sort of abstraction layer.

<domguinard> Bluetooth REST GATT whitepaper: https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCYQFjAA&url=https%3A%2F%2Fwww.bluetooth.org%2Fdocman%2Fhandlers%2Fdownloaddoc.ashx%3Fdoc_id%3D285910&ei=7l03Vf2MGIL0auHKgYAC&usg=AFQjCNEPvWUXl6NYv9s1HucZkEcngtRQUg&bvm=bv.91071109,d.d2s&cad=rja

Joerg: It's good to have an abstract architecture but I'm not sure we all have the same assumptions behind. Could we make explicit examples based on that to make sure that we share the understanding?

Dave: To make that more productive, it would be useful to share use cases against that diagram.

[Moving to Thingsonomies]

Dave: free text or formal ontologies

[Moving to Thing Descriptions]

Dave: metadata may change over time, so we may need events to signal changes.
... Properties of a thing may include data blobs that have a meaning and a content-type. When you transmit it, do you transmit the raw data, the data along with metadata, or the data using the appropriate content-type.
... Back to the diagram, the metadata, events, properties and actions are the main takeaway from the proposed abstraction.

Joerg: I really encourage you if you contribute use cases to use these blocks to come to a common understanding on this architecture.
... It may reveal that people have different understandings.
... It would also be a good way to start using use cases.
... Panasonic already did that in the breakout yesterday.

[Kazuo showing report of breakout session]

Kazuo: WoT framework assumes "Web browsers" access and control "Things".
... Analogy with classic Web: the browser accesses HTML document through the Web server, using a REST API. For the WoT, browser and applications access TDL documents through a WoT server with some abstract WoT protocol

<JonathanJ1> I modified my architecture proposal. It describe a concept of WoT Server - http://hollobit.github.io/swot-model/

Kazuo: We would like to make things clearer. WoT Server could be defined by combining finer components to map to real world. Would the protocol between browser/apps and WoT server be the same as the one between WoT server and WoT device or gateway?

Dave: Yes. For IoT devices, you have a number of protocols you may choose from. The abstraction bridges the details. You cannot just translate the protocols directly.
... In Web applications, there is a part that runs in the browser and on the server.

Dom: I would just forget that there is a gateway in order to make that as transparent as possible. Yes, there will be gateways but we really want to expose things at the WoT server and that's the part we should focus on.
... We should really define an API that works for both worlds.

Joerg: Would it be easier to say that this group assumes a WoT device, and that mapping to real world means that the WoT device can be an IoT device coupled with a gateway?

Edoardo: In our case, the gateway is something that we probably want to describe as a WoT device.

Carsten: Bluetooth can be used to connect to the network or it could be used to communicate inter devices.
... Same thing for other protocols.
... The diagram is wrong because it is at 2 abstraction layers.

Joerg: That's why I propose to remove the gateway. I think it's good to start with that part of the architecture and map use cases.

[Looking at last slide from breakout session report]

Joerg: let's start with that and collect comments based on use cases

<cabo> At the WoT abstraction level, we are not seeing the peripheral interconnects, whether they are I2C, SPI, USB, UARTs, Bluetooth, whatever.

Towards a WoT standard (Dom, Evrythng)

Dom: we're still working on a document that comes from several experiences, including the COMPOSE project and company activities.
... In 2007, we published a first paper

-> http://webofthings.org/publications Towards the Web of Things

Dom: It took some time to get the paper accepted actually, only in 2009, complaints were around the difficulty to support Web protocols in such constrained devices.
... [describing the paper featuring an ambient meter on a Sun SPOT]
... Someone at SxSW DDoS-ed our demo to show that Web protocols can easily be hacked.
... A nice practical experience to learn about security.
... We have a reference implementation that was DDoS so many times that we had to remove it.
... [demoing http://devices.webofthings.io to access a Raspberry PI and retrieving sensor vales]
... I can do the same thing with an HTTP GET request retrieving JSON. This is something incredible. It makes lots of things possible, changing the world.
... So why do we need a standard?
... As WoT IG, we need to think of the application layer.
... In their own way, Web APIs have created semi-isolated silos. Taking the example of Facebook and Google+ APIs, they are both based on REST and yet are not interoperable.
... A place to start is a simple set of rules: protocol (REST with JSON over HTTP), resource models (what is in the JSON, we need an accepted definition of the payload), and then support for extensions.
... Going back to the levels I presented yesterday, I'm mainly talking about Level 1, and other levels on top of that need to extend it.

<JonathanJ1> http://www.slideshare.net/misterdom/w3c-f2fwotevtcomposestandard

Dom: In a nutshell, the proposal is to have blueprints on how to implement APIs for Web Things, that is to advocate the use of REST, HTTP, JSON. Using these in the right way is already a good step forward.
... Standard resources and data-model for the representations.
... What would this help for? It's important to understand what we want to achieve. In terms of blueprints, it becomes a no-brainer to brands to implement WoT. I'm talking about brands that do not have a big IT department and produce eons of products.
... If they can just reuse standards, that would greatly help.
... This would also enable the automatic generation of User Interfaces including 100% Web-based UIs. What if I could take my smartphone and automatically start to interact with the air conditioner in my hotel room in Japan?
... It would also make it possible to generate mashups automatically. That's what I researched during my PhD for instance.
... You also have a plethora of different APIs going to different clouds. A standard would allow API to API integration.
... Eventually, this would avoid horrible options that we had to implement on various devices.

[showing a diagram of the proposal]

Dom: At the base, there is the protocol, HTTP, or CoAP. Then Patterns describe requirements for Web things. Then API and data formats.
... Different use cases considered, either directly implemented on the device or through a gateway. It should simply be the same from an external perspective.
... Document is open for comments on Google Docs.

<JonathanJ1> http://bit.ly/wot-label

Dom: Looking at requirements for Web Things APIs, we classified them using MUST, SHOULD, MAY levels
... [see slides and doc for list]
... The Web streams protocol defines the resources exposed by a Web Thing, and also the semantics to some extent.
... Web products describe the class of things, Web Things are instances. Web Things have properties which I use here to mean configuration values.
... Then a Web Thing has links to other resources, which lead to actions and streams that encapsulate the dynamic state of the Web Thing.
... Streams provide the data points with a subscription mechanism.
... I encourage you to take a look at the document and comment.
... Next steps: comments, we want to do some work on merging subscriptions and WebSocets, discussions about major protocols integration (CoAP is an easy one, MQTT has been ignored in our discussions but is used in the real world and can easily be mapped to WebSockets)
... We need to look at integration points (e.g. semantic Web).
... We'll be working on a first draft by end of May

Carsten: One major architectural gap here is that you're embracing WebSockets. WebSockets are a pipe.
... WebSockets don't give you any of the properties of REST.
... Using WebSockets is a workaround to enable REST.
... We're going back to stream connections, and de-emphasing the regular Web protocol, so actually going against the Web.

Dom: Right. The subscription API is RESTful but the events go over WebSockets in the proposal.
... In the end, I want Web apps to be able to communicate with things, so there HTTP and WebSockets are a no-brainer.
... That's true for Web applications but also for native applications.

Kensaku: You're doing a Pub-Sub protocol on top of WebSockets. I think there is a mechanism that describes such a protocol. Sub-protocol?

Dom: Yes. One thing I'm missing from WebSockets is QoS. That's a property of MQTT that is very interesting.

Kensaku: Could WebRTC be used as well?
... For instance, ChromeCast is now using WebRTC.
... Some cameras are also doing that.

Dom: What would be the advantage of the WebRTC approach?

Kensaku: It can be used to stream data, audio and video.

Dom: So it's the bandwidth that you're interested in. Do IoT devices need that?

Kensaku: That depends on the use cases.

Joerg: We're running out of time but please continue the discussion offline or during the break.

Dave: I like the proposal. I think you're missing a level of abstraction. Things could be regarded as virtual abstractions.
... Conceptually, there is a big difference between events and actions.

Joerg: Thanks for the presentation. It's really useful because it deals with practical details and asks right questions. Who do we target? Etc.
... I propose to breakout as yesterday to work on organizing the work by the next F2F. Structure the discussion, identify lead contributors.

<domguinard> live stream of the wot presented wot device: http://devices.webofthings.io/camera/sensors/picture/

<JonathanJ1> I added some requirement from guinard's document and protocol references into my proposal - http://hollobit.github.io/swot-model/

<Alan> scribenick: Alan

Task Force reports

Francois reviews the agreements for the Framework

Francois reviews the agreements for the Discovery work

@@@: This will also cover the provisioning activities

Johannes: In the group on protocols and APIs we setup the structuring for actions, we'll then have access for APIs
... We have an abstract pattern
... We plan to have that for next f2f
... We will have bi-weekly calls and will use a mailing list with tagable subject

Joerg: This is the three main actions we have, beside that we have some groups of people on Use Cases and Security and they need to tell us how they will organize
... We should hear that on the next IG Telco.
... We have organized the discussions and inputs for the next couple of weeks. Unfortunately we can't have breakouts due to the strike.
... But we do have another contribution that will be presented by Dave.

Functional Semantics

Dave: Last year their was an IoT Conference that had a WoT track.
... We had a number of talks there including one from Simon Mayer.
... I encouraged him to put something together for this group.
... This is an approach to describing IoT services in a goal oriented manner.
... It has to do with how do you discover services and mash them up
... If you can describe what you want can it be put together.
... It involved a Fuctional Service Description.

[Dave walks through demo code]

Dave: Once the writers are happy with it I'll send a pointer to the IG list
... You want to describe a service and what it does and when that works you want to invoke the Restful interface
... If you want sematically rich queries there will be some system that takes human queries and turns it into things like this.
... The goal is to describe actions and turns them into events.

Joerg: I don't know if Dom triggered this with his talk before lunch.
... On one side we want it to be flexible but on the other side we have very elementary examples

<tidoust> s/Functionla/Functional/

Joerg: We don't have the breadth of complexity
... If you think about the devices around you and you want to do this mashup thing, the question is how do we take these and are they practical or not.

Dave: If you have some high level thing in a service how do you invoke that.

Joerg: It would be great to see a demo of this in six months. So what would be a realistic demo of this?
... From what we understand of this approach, how are we actually going to use this? Dom you had something similar in your presentation. Do you think at this time we're addressing the developer or do you think we're addressing the user?

Dom: I'm not sure what the question is. What's missing for the developer?

Joerg: No, what are we missing for the users.

Dom: This type of thing to me is step 5 and we're at step 1. I think we need to reach agreement on the intermediate things. I've never seen it working in practice.

Dave: I think Simon has built a system and tested it, but nothing in the real world.

Dom: It's finding a crunch point between heavy weight semantics and light weight that allow you to do this.
... It's not so much about the syntax but what's under it.
... The relationships and how you interface them that matters.

Dave: We have to have matching at a base level.

Dom: That's one way, to be totally open. Or we could provide more descriptive way to do it.

Dave: It sounds like you're saying we shouldn't work on the core.

Carsten: I don't know of a specific example but there are things that have to do with automation that benefit from things like this.
... You need to define the relationships. This hasn't quite made it to the IETF yet but their is a security discussion that will move close to this.
... I wouldn't write this off, but I agree with Dom that it's not at step 1.

Dave: !!!!!!

Carsten: What we're using now is called Interconnected-Asset Ontology but it doesn't have the actions.

Dave: We ought to see if we can schedule Simon to present this properly.
... It's not quite finished yet but we need to wait until it's done.

Joerg: What triggered me is we had in these 2 or 3 days a number of proposals that varied from research projects, to concepts to pilot implementations.
... We have what I think is a lot of activities that are pilots in nature, but what worries me is we had a lot of discussions on a fundamental or principle way.
... I don't know what's the best way to keep things pragmatic and what we are evaluating.
... I thought the demonstrations were great, but we do research projects and bring it.
... But at a certain point we need to take this with us and say is this practical or not
... By that I mean can we use it, can we make applications from it.
... What's the balance between the instructions and making a system out of it.
... What do we do to avoid being too scientific?

Dave: What we propose in W3C is to start simpler and go from there. Attempts to start big have failed.

####: I think you need to have point services and building blocks. Not impossible suggestions of standards.

Joerg: Can you give some examples?

####: When people say non-functional they point to things like $$$$.

scribe: I think we need to capture this formally.

Dave: There are going to be criteria for the real world and we need to find out what they are.
... One example was scalabiltiy in the number of sensors.

Joerg: Even if you start to have it simple that doesn't mean it's simple to have an app on top of it.
... I don't think the initial solution was simple but quite pragmatic.
... There are things going on outside, how do we do demos of this stuff as aggregation.

Dave: If you think about the Web it grew from open collaboration.
... We need to do the same thing here via hackathons and suck.

Dom: Last time we met we were talking about what label to put on this.
... We were thinking having a limited number or things with a toolkit that helps you build that.
... How do you get things adopted today? By having it documented so it's easy to grasp and a tool that lets you get there.

Dave: So what can W3C do to help in this?

Dom: So the things that would help us is having definitions of the basics and things can occur after that.
... If you look at CoAP that's where it came from. The base started it and then things grew from there.

Dave: I think we can be a little more practical. Our next F2F is in the summer, so could we get some basics implemetned to show that.

Dom: I think if we agree on the core ideas getting these built will be easy.

Dave: And I think the base of this is to have Use Cases that allow for the implementation.

Dom: Find a couple of Use Cases that people can really relate to.

Carsten: I would warn that to much focus on demonstrations leads to things that can be slapped together.

Joerg: So what we need to see if proof of direction and that we capture the low hanging fruit.
... To get more practical on that side.
... It's something we can look at and share after some experience.

Carsten: It's some times hard to get things done in a constrained environment, if we remove that it might be easier to get things done.

Joerg: I think this is part of the thinking we've been doing. It's something we need to agree to on our calls.
... So maybe it's food for thought for those heading to the airport.
... Do we identify these low hanging fruit, maybe we've already identified something, and think can we get more practical on these parts.
... I'd like to thank you for taking the time to be here. I hope this stimulates discussions in the task force.
... Have safe journeys home and thanks to the W3C team for their work.

[adjourned]

- DRAFT -

WoT IG F2F (Day 2)

22 Apr 2015

Attendees

Contents