Re: [TF-AP] minutes - 7 Oct. 2015

this touches on something i've been meaning to find a moment to suggest.

one of my main use cases is "is it safe to leave the house?". i'm sure like
me you'll get to the front door and wonder whether the back door is open or
whether the oven is off, all that. the resolution would be to provide a
list of known Things and their status.

this use case is handily satisfied by most of the stuff under
consideration, but it leads to an issue where an application providing a
summary of Thing state doesn't know which properties to display. which are
important?

and so my suggestion, (which, naturally, is implemented by Monohm's
Sensible framework, grin), is property priority. how important is any given
priority? so the summary application would show top priority items, but
ignore others.

in the case of the "leaving the house" example, a top priority property for
a Things such as a door would just be open/closed, and for an oven would be
on/off - you don't care what temperature the oven is at, just whether it's
on or not. when you're controlling the oven, you can dig into properties of
lower priority.

make any sense?





On Thu, Oct 8, 2015 at 6:45 AM, Bassbouss, Louay <
louay.bassbouss@fokus.fraunhofer.de> wrote:

> Dear all,
>
>
>
> Please find attached Mockups for a use case addressing the usage of the
> Thing API proposal.
>
>
>
> Regards,
>
> Louay
>
>
>
> *From:* Kazuyuki Ashimura [mailto:ashimura@w3.org]
> *Sent:* Mittwoch, 7. Oktober 2015 18:55
> *To:* Public Web of Things IG <public-wot-ig@w3.org>
> *Subject:* [TF-AP] minutes - 7 Oct. 2015
>
>
>
> available at:
>
>   http://www.w3.org/2015/10/07-wot-ap-minutes.html
>
>
>
> also as text below.
>
>
>
> Thanks a lot for taking notes, Francois!
>
>
>
> Kazuyuki
>
>
>
> ---
>
>    [1]W3C
>
>
>
>       [1] http://www.w3.org/
>
>
>
>                                - DRAFT -
>
>
>
>                      APIs and Protocols Task Force
>
>
>
> 07 Oct 2015
>
>
>
>    [2]Agenda
>
>
>
>       [2] https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/0007.html
>
>
>
>    See also: [3]IRC log
>
>
>
>       [3] http://www.w3.org/2015/10/07-wot-ap-irc
>
>
>
> Attendees
>
>
>
>    Present
>
>           Dave_Raggett, Kaz_Ashimura, Louay_Bassbouss,
>
>           Takuki_Kamiya, Yingying_Chen, Francois_Daoust,
>
>           Daniel_Peintner, Johannes_Hund, Claes_Nilsson,
>
>           Joerg_Heuer, Kazuaki_Nimura, Ari_Keranen, Arne_Broering,
>
>           Darko_Anicic, Michael_Koster
>
>
>
>    Regrets
>
>    Chair
>
>           Johannes
>
>
>
>    Scribe
>
>           tidoust
>
>
>
> Contents
>
>
>
>      * [4]Topics
>
>          1. [5]Plugfest preparation & pre-hackathon on TPAC
>
>          2. [6]Technology landscape
>
>          3. [7]Scripting API for WoT model
>
>          4. [8]On-going deliverables of the Task Force
>
>      * [9]Summary of Action Items
>
>      __________________________________________________________
>
>
>
>    <scribe> scribe: tidoust
>
>
>
>    Johannes: [going through agenda]
>
>    ... I note Claes request by mail on documents under
>
>    development. Other additions?
>
>    ... [none heard]
>
>
>
> Plugfest preparation & pre-hackathon on TPAC
>
>
>
>    <kaz> [10]Plugfest wiki
>
>
>
>      [10] https://www.w3.org/WoT/IG/wiki/F2F_meeting_29-30_October_2015,_Sapporo,_Japan#Plugfest
>
>
>
>    Johannes: I think that we have the requirements for the demo,
>
>    is that correct?
>
>
>
>    Kaz: Basically, the setting should be ok.
>
>    ... The demo lists the demonstrations that will be made on the
>
>    first floor.
>
>
>
>    Johannes: We could do a hackathon to prepare the plugfest. Some
>
>    exchanges about rooms.
>
>
>
>    Kaz: The room next to the main demo hall will be available.
>
>    That is a room for storage and to keep devices.
>
>    ... The meeting planning team suggested to use that room during
>
>    the day and in the evening.
>
>    ... Maybe we can start the preparation at around 3PM.
>
>    ... The network will not be available on Sunday though.
>
>    ... Same thing for the AC supply.
>
>    ... Of course we could bring our devices to the room, but
>
>    Sunday will not be a good time.
>
>
>
>    Daniel: Last time we discussed, there was the question of
>
>    Internet connectivity.
>
>
>
>    Kaz: For the plugfest within the meeting room?
>
>
>
>    Daniel: Yes.
>
>
>
>    Kaz: We could use wired connections and routers to create wifi
>
>    networks if needed.
>
>    ... If we can clarify needs, we can talk to the systems team.
>
>
>
>    Daniel: And we need to decide who is going to carry around a
>
>    router.
>
>
>
>    Kaz: Another question is whether we need Internet connection
>
>    for the external network.
>
>
>
>    Johannes: I think we added a column to the table. Soumya does
>
>    not need connectivity apparently. Let's ask others to fill the
>
>    column as well.
>
>
>
>    Kaz: Jonathan filled out that table, need to check with him.
>
>
>
>    Daniel: Also, if there are too many devices around for
>
>    discovery, that may be a problem.
>
>
>
>    Kaz: Right, small local network should solve that.
>
>
>
>    Johannes: Takeaway is that we could use that storage room with
>
>    no time bounding. We need to decide whether it's Tuesday or
>
>    Wednesday.
>
>    ... Which would be better, Tuesday or Wednesday?
>
>
>
>    Kazuaki: I can do both.
>
>
>
>    Louay: Also available on both days.
>
>
>
>    Johannes: Others are not on the call. For Siemens, both days
>
>    are possible as well.
>
>
>
>    Kaz: in that case, I suggest to try Tuesday first. If that
>
>    fails, we have Wednesday as a backup :)
>
>
>
>    Johannes: Right.
>
>    ... Any other issue on the topic?
>
>
>
>    Dave: The request for demos for monday evening. Is anyone
>
>    willing to provide a demo for the developer event?
>
>    ... See mail I sent earlier on. Just a reminder here.
>
>
>
> Technology landscape
>
>
>
>    <inserted> [11]Technology Landscape wiki
>
>
>
>      [11] https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Technology_Landscape
>
>
>
>    Johannes: We have different consortia that are using different
>
>    technologies. Several protocols from the ones we've identified.
>
>    If people who contributed to this landscape could also
>
>    cross-reference the other IoT efforts so that we know which
>
>    supports which model.
>
>    ... We need some more depth for the technology landscape.
>
>    ... We had some discussions on CoAP for instance. If we could
>
>    complete the Wiki, that would give us more food to make
>
>    recommendations.
>
>    ... Do we have people who can contribute more to this?
>
>
>
>    <kaz> scribenick: kaz
>
>
>
>    johannes: coap section
>
>    ... Dave and Claes?
>
>
>
>    <tidoust> scribenick: tidoust
>
>
>
>    Claes: Yes, I can write something down
>
>    ... Do you want a separate page for that?
>
>
>
>    Johannes: No necessarily, sub-bullets would be fine.
>
>    ... What would be very good would be to identify criteria that
>
>    could be applied to all these protocols, such as availability
>
>    for wide area networks.
>
>    ... That would create a list of questions to answer for all
>
>    these protocols.
>
>    ... We already discussed them for CoAP, but they probably apply
>
>    for WebRTC, MQTT, etc.
>
>
>
>    Claes: OK, I'll see what I can do.
>
>
>
>    Johannes: Same thing for OneM2M, it would be good to list what
>
>    protocols they are using.
>
>
>
>    Michael: I would be happy to add some stuff on IPSO and on
>
>    OneM2M as well.
>
>
>
>    Johannes: That would be great, yes!
>
>    ... Criteria applied to all of these would be quite good.
>
>    Volunteers welcome!
>
>    ... Regarding the tech landscape, I think it would be good to
>
>    detail the different stacks and protocols.
>
>
>
>    Dave: Do we have an entry for AllJoyn?
>
>
>
>    Johannes: Not yet. Do we know someone who is involved in that
>
>    effort?
>
>
>
>    Dave: No, but Qualcomm is involved in that organization, so we
>
>    could get in touch with their AC Rep.
>
>
>
>    <scribe> ACTION: Dave to ask Qualcomm about contributions to
>
>    Tech landscape about AllJoyn [recorded in
>
>    [12]http://www.w3.org/2015/10/07-wot-ap-minutes.html#action01]
>
>
>
>    <trackbot> Created ACTION-11 - Ask qualcomm about contributions
>
>    to tech landscape about alljoyn [on Dave Raggett - due
>
>    2015-10-14].
>
>
>
>    Michael: They have also something called data driven API, which
>
>    seems interesting to us.
>
>
>
> Scripting API for WoT model
>
>
>
>    Johannes: I think that Louay has a proposal here.
>
>
>
>    Louay: [presenting slides on WebEx]
>
>    ... Same presentation as I presented two weeks ago in the
>
>    Discovery call.
>
>    ... Idea of an API for the browser to discover and access
>
>    things
>
>    ... Some of the concepts are taken from my involvement in the
>
>    Presentation API.
>
>    ... Working on a plug-in for Cordova
>
>    ... The main idea is to define a JavaScript API that allows Web
>
>    pages to discover and interact with things. Main point is to
>
>    consider security and privacy by design.
>
>    ... Second point is to abstract from the underlying protocol.
>
>    ... The API could be implemented on top of different protocols.
>
>    ... Mainly useful for things that are not registered with a
>
>    particular server, such as things using Bluetooth Low-Energy
>
>    ... [Louay explains the Presentation API, scribe suggests to
>
>    look at minutes of Discovery call where this part was minuted
>
>    in more details]
>
>
>
>    -> [13]http://www.w3.org/2015/09/24-wot-di-minutes.html#item01
>
>    Minutes of Louay's Thing API presentation in Discovery call
>
>
>
>      [13] http://www.w3.org/2015/09/24-wot-di-minutes.html#item01
>
>
>
>    Louay: Focus of Presentation API is presentation of web
>
>    content. Audio/video content will be considered afterwards. We
>
>    have a Cordova plug-in implementing the Presentation API.
>
>    ... Chrome, Firefox implementing the Presentation API right
>
>    now.
>
>    ... The idea with the Thing API is to use the same concept,
>
>    because there are common features between the two cases.
>
>    ... The first analogy is linked to the need to discover
>
>    displays/things. The second analogy is linked to the need to
>
>    have a communication channel.
>
>    ... A "ThingRequest" constructor would take a filter object
>
>    that describes all things that are of interest for the app.
>
>    ... When the app starts the API, the user agent discovers the
>
>    things that match the filter. The user selects one thing
>
>    (possibly more than one) in the list.
>
>    ... When the web page gets access to a thing, it gets an ID
>
>    that it can use later on to access the thing again later on.
>
>    This is useful for usability, as starting otherwise would
>
>    always display a dialog to select a thing, whereas for things
>
>    you may want to give access for a longer period of time.
>
>    ... Then the Web page gets a Thing instance, on which it can
>
>    read/write properties or call actions.
>
>    ... The web application will be notified when things are no
>
>    longer available.
>
>    ... We started to implement this as a Cordova plugin, here only
>
>    on top of HomeKit, so only available on iOS.
>
>    ... This is one showcase we want to present at TPAC.
>
>    ... The goal is also for the Cordova app to serve as WoT
>
>    Servient that offers a Websocket server or HTTP server to
>
>    enable access to the things from other clients.
>
>    ... So it's not only an application but also a Service.
>
>    ... This is the reason why we need to run the app in the
>
>    foreground on iOS.
>
>    ... I received feedback from Francois and Dave.
>
>    ... Dave's comments are centered on JSON-LD. I don't think they
>
>    apply to the API itself.
>
>    ... Francois wondered whether selection of multiple things
>
>    would be useful (in the Presentation API, only one display may
>
>    be selected). I think that's a good idea for things. For the
>
>    API, instead of one Thing, the application would simply receive
>
>    an array of Things.
>
>    ... Second comment was about how browsers may handle a large
>
>    number of things that they discover.
>
>    ... I think the API is more applicable to
>
>    sensors/actuators/things that are not registered on the
>
>    network, for home automation. That's the main goal of this API.
>
>    ... Last comment was about the dialog display being shown to
>
>    the user each time the thing is first accessed. The ID
>
>    mechanism that I described would give the app the rights to
>
>    access the thing later on without prompting the user again.
>
>    ... The Generic Sensors API addresses sensors that are
>
>    available on the device where the browser is running. Here it's
>
>    more related to discovery new things and interacting with new
>
>    things.
>
>    ... In the Generic Sensors API, there is no discovery. You can
>
>    directly check whether a sensor is available.
>
>    ... Questions? Comments?
>
>
>
>    Johannes: Can we view the API in two parts, the native
>
>    selection box and the Thing API itself?
>
>
>
>    Louay: Yes.
>
>
>
>    Johannes: Then there is the ability to expose the discovered
>
>    Thing as WoT Servient. Is that part of the API?
>
>
>
>    Louay: The API addresses the first two parts. To offer the
>
>    thing to other applications, I will implement another layer.
>
>    This is really for the plugfest, not part of the API.
>
>    ... All the information you need will be in the Thing
>
>    description file
>
>
>
>    Johannes: The reason for my question is that this would enable
>
>    Thing-to-Thing communication in a very unified way.
>
>    ... This would provide a way to discover things, wrap them for
>
>    exposure, and expose them to other things.
>
>
>
>    Louay: Yes. You will need specific protocols for discovery and
>
>    controls, but exposing could use existing standards more
>
>    easily. The Thing API I propose is not a solution for all the
>
>    features discussed here.
>
>    ... We need other parts for registering things. Not part of the
>
>    browser API, I think.
>
>
>
>    Johannes: OK, but you form a proxy for the thing.
>
>    ... I wonder why the split between the two parts.
>
>    ... Risk of fragmentation depending on protocols used.
>
>
>
>    Louay: Yes. That is a problem with the Presentation API as
>
>    well. From an application perspective, you would be able to use
>
>    the same API but may not end up with the same list of available
>
>    displays depending on protocols supported by the underlying web
>
>    browser.
>
>
>
>    Johannes: If you were to implement a thing such as a lamp. You
>
>    would have another API to expose a thing. Why not have only one
>
>    API.
>
>
>
>    Louay: I agree. This is a basic idea. If you can inject your
>
>    ideas to extend my proposal, I'd be happy to discuss that next
>
>    time.
>
>
>
>    Dave: Just a question about the style for accessing things. To
>
>    some extent, I think this should be language-independent. Also
>
>    the question of synchronicity as developers will be more
>
>    expecting synchronous properties for instance.
>
>
>
>    Louay: If I set a property and then call an action after
>
>    setting the property. If I don't wait for the property to be
>
>    set, how can I be sure the action takes place at the right
>
>    moment?
>
>
>
>    Dave: Well, you may not be the only one accessing the thing in
>
>    any case. There may be something behind the scene.
>
>
>
>    Louay: You propose something such as "thing.colorTemperature =
>
>    42"?
>
>
>
>    Dave: Right, for devs, I think it makes sense.
>
>    ... One question is to what level we need to standardize this
>
>    API. We need to define a data model, sure. What else? Open
>
>    question.
>
>
>
>    Louay: We could use the event on Monday to get feedback from
>
>    developers for instance.
>
>
>
>    Dave: As an IG, we should explore different options, I think.
>
>    ... I need we need to get practical implementation experience,
>
>    so congrats for this work. The plugfest is a nice experiment.
>
>    We need more of that to point out these issues.
>
>
>
>    Johannes: Would it be possible to upload the script examples in
>
>    your slides to the GitHub pages?
>
>
>
>    Louay: Yes, I will do it.
>
>
>
>    <kaz> scribenick: kaz
>
>
>
>    tidoust: tx for mentioning all my comments
>
>    ... please note Generic Sensor API work handles similar topics
>
>    ... could converge common APIs
>
>    ... upcoming draft will be published soon
>
>    ... TPAC would be a good opportunity to start discussion
>
>
>
>    louay: Generic Sensor API focuses on reading data
>
>    ... while WoT APIs handle accessing actuators
>
>
>
>    tidoust: right
>
>
>
>    <tidoust> scribenick: tidoust
>
>
>
>    Kaz: Unfortunately, DAP will not have a meeting at TPAC, but
>
>    Tobie will be there.
>
>    ... We can probably have some joint discussion on Tuesday or
>
>    Wednesday with him and other people from DAP.
>
>
>
>    <kaz> [14]ad-hoc meeting proposal (Tuesday)
>
>
>
>      [14] https://www.w3.org/wiki/TPAC/2015/ad-hoc-meetings#Generic_Sensor_API
>
>
>
>    <kaz> [15]Breakout proposal (Wednesday)
>
>
>
>      [15] https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Generic_Sensor_API
>
>
>
>    Joerg: Maybe we should have a short list of ad-hoc meetings to
>
>    the IG agenda. Already a couple planned.
>
>
>
>    <kaz> +1
>
>
>
>    Johannes: skipping tooling for today in the interest of time.
>
>
>
> On-going deliverables of the Task Force
>
>
>
>    <kaz> [16]Claes's message
>
>
>
>      [16] https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/0011.html
>
>
>
>    Claes: I had a look at the documents referenced by the Wiki and
>
>    I wondered which of them are still being pursued.
>
>    ... For instance, the Architecture Model, is that still
>
>    relevant?
>
>
>
>    Johannes: I would like to open that question for the group.
>
>    ... [no comment heard]
>
>    ... During the F2F meeting in Sunnyvale, we made an attempt to
>
>    bring different views for the Web of Things model and
>
>    architecture together.
>
>    ... However, we did not reach consensus to draw this into one
>
>    picture.
>
>    ... It's not very clear to me how we can move forward.
>
>
>
>    Michael: I would suggest that we list documents that have clear
>
>    group consensus and that we maintain.
>
>    ... Not doable overnight, but that's a question I got as well
>
>
>
>    Dave: Right, by charter, we also need to publish reports that
>
>    represent consensus of the group.
>
>    ... We need to make it clear what parts are work in progress
>
>    ... I think it's a question for the group as a whole.
>
>    ... Something that the Chair and TF leads could work on for
>
>    preparation for the F2F in Sapporo?
>
>
>
>    Joerg: The most pragmatic is to discuss this by email. Whether
>
>    the Wiki is fine, where we put parts which have consensus, etc.
>
>
>
>    Claes: That sounds good.
>
>
>
>    Dave: The different task forces are working in the right
>
>    direction, e.g. security
>
>
>
>    Johannes: Where do we have the reference? How can we ensure
>
>    that we have a good list of documents?
>
>
>
>    Dave: Maybe start from the group's home page with a list of
>
>    documents on the right.
>
>    ... And same thing on the IG wiki.
>
>
>
>    Johannes: Problem is to assess the maturity of documents.
>
>
>
>    Claes: Wouldn't it be good if task leaders take a stab at it?
>
>
>
>    <kaz> scribenick: kaz
>
>
>
>    johannes: I'd get an action item for that
>
>    ... to describe the status of the documents
>
>
>
>    claes: which document for us to contribute
>
>
>
>    johannes: could list the existing documents
>
>    ... that would be feasible
>
>
>
>    kaz: we can add links to the existing documents to the "Work in
>
>    progress" section
>
>    ... and the moderators can add brief description to each list
>
>    item
>
>
>
>    ->
>
>    [17]https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Work_i
>
>    n_progress work in progress section
>
>
>
>      [17] https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Work_in_progress
>
>
>
>    johannes: ok
>
>
>
>    claes: ok
>
>
>
>    johannes: other TF managers should also do that
>
>    ... and make the decision on which to be continued during TPAC
>
>    ... have we addressed all your points, Claes?
>
>
>
>    claes: yes
>
>
>
>    johannes: tx
>
>    ... we're getting out of time
>
>    ... any other business?
>
>
>
>    (nothing :)
>
>
>
>    [ adjourned ]
>
>
>
> Summary of Action Items
>
>
>
>    [NEW] ACTION: Dave to ask Qualcomm about contributions to Tech
>
>    landscape about AllJoyn [recorded in
>
>    [18]http://www.w3.org/2015/10/07-wot-ap-minutes.html#action01]
>
>
>
>    [End of minutes]
>
>      __________________________________________________________
>
>
>
>
>
>     Minutes formatted by David Booth's [19]scribe.perl version
>
>     1.140 ([20]CVS log)
>
>     $Date: 2015/10/07 16:52:05 $
>
>
>
>      [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
>
>      [20] http://dev.w3.org/cvsweb/2002/scribe/
>
>
>
> --
>
> Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI, Voice and Geo
>
> Tel: +81 3 3516 2504
>
>
>