WoT IG F2F -- 22 Sep 2016

<dsr> scribenick: dsr

Welcome

Joerg introduces the meeting, mentioning the successful plugfest during the plenary day on Wednesday.

Joerg displays the IG’s roadmap and walks us through it

In summary, we started by collecting atomic use cases, we then explored them experimentally through plugfests, and went on to prepare a charter for working group to drive the initial standards.

The working group charter is currently being reviewed by the W3C Advisory Committee.

We now are looking forward to next steps for the WoT IG, e.g. reviewing the building blocks in the current practice document, to propose improvements, and to review the architecture document.

<ningxinhu> could someone share the slides links?

Joerg displays the F2F agenda

<yingying> https://www.w3.org/WoT/IG/wiki/F2F_meeting,_September_2016,_Portugal,_Lisbon#Agenda

<michael> Is there a teleconference or hangout for remote participation?

<JonathanJ> https://www.w3.org/WoT/IG/wiki/F2F_meeting,_September_2016,_Portugal,_Lisbon#WoT_IG_Agenda

Joerg: we will now have a sequence of invited talks from guests

Joerg runs through the rest of the agenda and introduces the breakouts. We have a separate space which is a little hard to find

<michael> I would follow on webex if it was available

<michael> Thanks looks like member login

Spatial Data on the Web WG

<jhund> michael, its on the members list a mial with the webex data

<jhund> *mail

Kerry Taylor introduces herself - I am the co-chair of the spatial data on the web working group.

A few of you came along to our face to face earlier this week for a joint meeting.

<michael> I don't think I have the login

We’re a joint group between W3C and the OGC. The group is chaired by myself and Ed Parsons of Google, our W3C Staff contact is Phil Archer

We have a lot of deliverables in our charter.

<danbri> ( OGC overlaps for e.g., sensor specs - http://www.opengeospatial.org/domain/swe )

https://www.w3.org/2015/spatial/wiki/Main_Page

Kerry summarises the current work items

best practices, semantic sensor networks, OWL-Time, and Coverage

The latter is related to satelite imagery

Kerry displays a slide on the semantic sensor networks ontology.

<michael> OK got the webex, thanks!

This was created in a W3C incubator group. It is a detailed ontology for the capabilities and properties of sensors.

with lots more besides - it is pretty comprehensive

The SSN ontology is an OWL 2 DL ontology.

We’re trying to simplify it, working on some extensions, alignment with our best practices, time ontology, provenance. We

We’re also working on a primer

Kerry: we doing some work on ONM

In out F2F this week, we discussed the WoT requirements. These are still too unstable to consider incorporating into SSN

We talked about the terms used by our group and the WoT IG

We looking at adding a link to a thing description

We also implementation needs that could be supported by WoT plugfests

Questions?

Michael_McCool: one use case is in robotics, have you looked at that? We should chat about it.

Kerry: we haven’t as yet

Sebastian_Kaebisch: I like the idea of integrating a TD pointer in SSN

Dave_Raggett: does SSN lend itself to fine grained modularity so that people can just use what they need?

Kerry: short answer is no, but we do have some course grain modules and continuing to discuss this, we welcome feedback.

There will be two versions of SSN, a simple one and a more comprehensive one.

Joerg discusses some next steps

He asks about implementation and what goals we could have for the plugfest

Kerry: SSN is used a lot in WoT applications, e.g. smart cities, building automation, etc.

Darko: we should consider how to use SSN for online plugfests and exploit geospatial data for sensors

Kerry cites someone in her group who she thinks would be interested in that

We thank Kerry for her presentation.

GSMA IoT security guidelines

Natasha Rooney presents

Full topic: Securing the Internet of Things, Applying best practice to reduce risks.

Natasha: today I want to talk about our security guidlines for the IoT

Mobile operators expect a lot of IoT data traffic on their networks. There are a lot of concerns to be addressed

We’re interested in low power devices, long lifecycles, low cost, and physical accessibility of devices

She presents a long list of key security considerations for developers

http://www.gsma.com/connectedliving/future-iot-networks/iot-security-guidelines/

Natasha: I will talk you through the steps for securing IoT services.

There are three documents you can look at

You need to evaluate the technical model, to review the service’s current security model, to review and evaluate our recommendations, ...

Our documents include an overview, end point ecosystems, service ecosystems and network operators.

The guidelines include some worked examples.

We have an IoT security self assessment checklist

You can use this to invite review from the GSMA

Nastasha skims through the Service ecosystem document

One example, is defining a recovery model following a security incident

You’re invited to review our documents and to provide us with feedback.

Dave: I was at IoTW in Berlin this week, and one thing I noticed was that human error is something really critical to cover, what do the GSMA guidelines say about that?

Natasha: we do cover it to some extent, e.g. the need for logging and the need to avoid SQL injection attacks

Johannes_Hund: do you see opportunities for standard building blocks

Natasha: trusted modules

Kaz asks about policy issues in respect to IoT security, e.g. for Government regulations on national security

Dom_Guinard: are you monitoring attacks?

Natasha: the questionaires provide some info

The GSMA intelligence service offers some info

IoT and schema.org

Dan Brickley (Google) presents

Dan: I work for Google in London, but today are representing schema.org

He asks for a show of hands on who knows about schema.org (many hands)

Schema.org is a website acting as a dictionary of terms, a collection of schemas used primarily on the public web, but also in email and other contexts

The project began in 2011. It is used by websites for signalling descriptions of the sites to search engines for smarter search results

We started using HTML5 Microdata, and later added support for RDFa and JSON-LD

The underlying approach is lightweight RDF

Our schemas are very widely used on the web

tens of millions of websites

We expanded the scope in 2013 to cover structured data in email

(HTML email)

This introduced the complexity of dealing with personal data

We found that microdata was then too verbose

Schema.org was founded as a collaboration between Google, Bing and Yahoo, and soon joined by Yandex

We use the W3C Semantic Web Interest Group as our public community

We build upon W3C standards but are not a W3C standards WG

We’re discussing with the W3C Staff about enabling W3C work to normatively reference schema.org schemas

We focus on extensibility and are somewhat relaxed about the formal standards

In particular, we found a need for an order of magnitude more terms than previous work, e.g. the Dublin Core

He mentions GS1 as an organization with an extensive classification for food products, e.g. a property describing the firmness of cheese.

Schemas from different organizations have minor differences of spelling and naming.

e.g. colour vs color

We’re now just starting to explore schemas for the IoT

Large scale vocabularies will always have some mistakes. We may have to retain these where many websites would be effected.

One open question is when terms should go into the main schema.org vocabulary and when they should go into docore specific modules

There is no hard and fast rule, so we take a pragmatic approach. We being the schema.org steering group

We would like people to use frozen snapshots of our vocabularies.

We now have a position paper on http://iot.webschemas.org

See http://iot.webschemas.org/docs/iot-gettingstarted.html

We want a framework where you can combine domain specific vocabularies with the core schema.org vocabs

The paper includes several example situations where schema.org could offer value

User data portability, Beacons and the description of the physical environment, Smart Assistants, On-device content, Sensors and the description of the physical environment, and Energy Efficiency

We have a public mailing list and encourage you to join it.

Joerg thanks Dan for his talk

Dave: two questions: one is there a commitment to providing a service on a long term, and second: to attract other industries, what are your plans in respect to governance and the composition of the steering group?

Dan: we’ve had discussions with other companies, and so far have decided against creating a consortium, and will keep going until we see this is creating a problem

Joerg: what makes the IoT different, is there something about machines rather than people as end points?

Dan: for resource constrained devices, we would need to be stricter about the formats for metadata

Dan talks about geospatial relationships that were raised in the spatial data on the web WG, and how he add these into schema.org

Fabien_Gandot: how do you decide how to address changes to schemas?

Dan: We use the SemWeb IG and github issues

Snapshots provide the flexibility to refer to a given version

Fabien: do you keep statistics on usage?

Dan: yes

<inserted> [ morning break ]

A year of Web Thing Model: reporting on learnings from the first W3C WoT IG submission

Dom_Guinard (Evrythng)

we break for coffee

Dom introduces himself. I am the CTO for EVRYTHNG

We have a WoT platform with some three million customers

Today, I want to talk about the Web Thing Model submission we have with several others to the WoT IG last year

Dom runs through the motivation and background for the submission

The submisson is at http://www.w3.org/Submission/2015/SUBM-wot-model-20150824/

This work was produced in association with the EU COMPOSE project on cloud based IoT platforms

We’ve used our approach with the Nest devices for smart homes

Some of the challenges include dealing with faults

We found it important to be crystal clear about the positioning

There are too many competing platforms and standards so this is essential to being heard

We need to show how integration with the Web brings real benefits

It is very important to engage with the developer communities

HTTP and WebSockets have become widely supported

We need a neutral body for the IoT interoperability layer standards, W3C is well placed for that

Joerg thanks Dom for his presentation.

Joerg: we’re not defining another platform, but rather a means to interoperate across platforms

Dom: there is a need for base constructs which complicates the explanation

Johannes: We start out by accepting the use of existing platforms

We should include integration with EVRYTHNG solutions in future plugfests.

Introduction to the break out sessions

Johannes introduces his breakout on subscriptions. This will take place in room 5A (the room we’re in).

Kajimoto-san introduces his breakout on thing description lifecycle

This will take place in the small room up the stairs just beyond the coffee area next to room 1.10

Subscription breakout session

chaired by Johannes Hund (Siemens)

Johannes welcomes everyone here. Today we will continue the discussion on subscriptions that we started at the Beijing F2F and continued in github

I will start with a recap

My aim is to define a uniform abstraction

We need to identify the requirements. An example is whether an update is self contained or is a delta of some kind

Another issue is whether it is ok for an update to be dropped or whether we need to guarantee delivery

Are updates sent when values change or are they buffered and sent at a regular interval?

Johannes displays some use cases

Yet another point is whether the updates need to be logged and there is an access to historic values

He runs through the respective use cases stating whether they use delta encoding, allow data discards, are sent at regular intervals and require a history

Dave runs the mic around - temporary loss of minute taking - please help by typing into IRC!

Michael: some features will only be available with particular protocols, this suggests the need for introspection by the application layer

Dave: we need a means for apps to state their requirements independent of the protocols, and for the platforms to indicate sufficient details for other platforms to communicate interoperably

Johannes recaps a proposal by Michael Koster

acl zkis

Zoltan (intel): a further challenge is the need for info for data format translation

and where does the computation needed for that translation take place?

Matthias: perhaps this can be out of scope for this particular breakout session?

Johannes: we need to come up with a model for expressing the info needed

We should focus on the requirements for the abstract messaging.

Michael: does the model allow for observing values?

Johannes: yes

We will then need to evaluate this against the use cases and particular protocols

Taki: sometimes the application is interested in the deltas

Matthias emphasises the need to agree on the abstract requirements

but also the implementation implications

<McCool> McCool notes we should also look at how to efficiently implement "named topics" that separate publisher and subscriber

<McCool> McCool notes that some general mechanism for timestamping events is needed... which also implies a mechanism to synchronize or transform clocks

The data stream may include first and second order derivatives, so it depends …

<McCool> McCool for dx/dt, note that in some cases you do not compute such things from values at different time, but sense them directly

Carsten talks about network latencies and tracking time

<McCool> for example, might sense position, velocity, and acceleration separately, rather than deriving them from postion over time

Absolutely

I think we need to be clear in distinguishing app level requirements from protocol/encoding metadata that is the concern of platforms

<yingying_> https://github.com/w3c/wot/tree/master/proposals/subscriptions

Johannes recaps the subscription proposal on github (see above)

<McCool> McCool notes that ROS has pub/sub architecture, used in semi-real time system, has situations where we want events to timeout if not delivered

Dave: I think we need to be careful about distinguishing app level requirements, e.g. for timeliness of updates versus metadata for describing whether the platform should use a pub/sub REST protocol

<yingying_> WoT Architecture doc

Johannes displays the architecture diagram from the architecture document

Dave asks we mean in that diagram by resource model — is it referring to the model of resources at the application level or the model or resources exposed by say a REST based server?

<McCool> McCool notes: yes, need to distinguish "what the app wants" from "how it is provided"; good example is "observing a value". Could be done with pub/sub, could be done by polling...

<Zakim> McCool, you wanted to comment on named topics and heavy streams

Matthias and Dave chat about the abstractions. Dave clarifies the we need to describe the intent at the application layer and how this is realised by a particular protocol at the platform layer

Matthias: we need to ground this in the use cases

Michael: what is the process for contributing to this work?

<yingying_> proposal folder in github

Matthias: everyone can out a proposal into github, and you can then ask to present this at a teleconference, and ideally to demstrate an implementation, e.g. at the next plugfest

We have some specific issues we should focus in today

Zoltan: we have many protocols, we can have apps provide hints and enable apps to see introspect how they have been fulfilled.

we need to ground this in the use cases

<McCool> Michael notes some topics I would like to see proposals for: timestamping; named topics; latched events; optional feature negotiation (that could be at a different level since it applies to other things as well as subscriptions)

Johannes: let’s start from the list of characteristics I showed earlier and add new ones

Michael: I would like to add some further things to cover: timestamping, named topics, latched events and optional features

<McCool> McCool notes forgot "heavy streams" like video...

Matthias: we want to use URIs for resources as a means to handle app level subscription requests (e.g. for events)

Dave: The meaning of the resource model is not that clear

<McCool> McCool notes that "named topics" perhaps can be managed by treating subscriptions/topics like named resources

<McCool> but we need a detailed concrete proposal

Dave asks Matthias whether the resource model he is talking about, the model exposed to applications or somything more about the models used at the REST level?

Matthias talks about URIs for resources

Johannes: the resource model is a platform level abstraction and isn’t exposed to applications
... we’ve found that an explicit resource model is valuable for simplifying bindings to REST protocols.

Some discussion about OAuth and security considerations

Johannes asks for people to curate particular topics

Michael volunteers for the topics he proposed

Matthias we need to set some expectations on timeline and goals

Intro for afternoon breakouts

<kaz> victor: explains the Hydra breakout

<kaz> johannes: explains the scripting API breakout

<kaz> joerg: scripting API here at 5A

<kaz> ... Hydra at the space next to 1.10

<kaz> johannes: IRC channel for this room is #wot

<kaz> ... Hydra uses #wot-td

Scripting API Follow-up

<dape> JH: see issues on Github https://github.com/w3c/wot/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20%5BScripting%5D

<dape> JH: Nimura-san has further feedback

<dape> ... more developer feedback ?

<dape> ... none so far

<dape> JH: recaps API description of current practices document

<dape> --> http://w3c.github.io/wot/current-practices/wot-practices.html#scripting-api

<dape> JH: API root object

<dape> ... allows to create composed thing or exposed thing

<dape> ... so far we did have 2 PlugFests with API support

<dape> ... based on 2 different teams

<dape> ... got feedback

<dape> ... details such as actions without parameters

<dape> JH: any feedback is welcome... please open github issue

<dape> ... also add "tag" on GH

<dape> JH: Would like to ask Nimura-san for his feedback

<yingying_> scribe: dape

Nimura: prepared slides...
... based on Bejiing meeting I think we need modifications

<McCool> McCool notes got one additional comment at demo yesterday on "create from name" which seemed strange; should creation always need a TD?

1. expose @type

scribe: in Exposed thing

2. w.r.t. property, getProperty without polling

JH: Thanks Nimura-san
... will create issue for @type comment
... think we also need allowing to set context... otherwise @type is not useful

McCool: "create for name" alone seems strange...

JH: There is the notion of creating a blanc thing
... then you can add properties, actions et cetera
... allows dynamic things happening
... still we discussed whether it makes sense to have a split between "static" and "dynamic" capabilities
... back to @type discussion

<McCool> maybe have a concept of "freezing" properties

<McCool> eg can create, modify, then freeze

JH: might be more complex ... @type is allowed for properties, actions also

<McCool> generically useful, as frozen resources can be freely cached, etc

JH: Second issue from Nimura-san was about polling
... "onGetProperty" is needed... kick in handler and then return result
... do we need to block before returning

Nimura: yes

JH: means we allow only one handler...

wonsuk: which framework is used for the implementations?

JH: runtime in Java with Nashorn
... Lets go back to issues, https://github.com/w3c/wot/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20%5BScripting%5D
... about 10 are open
... eg., https://github.com/w3c/wot/issues/233
... need to hook-in event handler
... one solution could be adding it to discovery

McCool: daemon interface should be standardized

JH: we have methods to discovery things
... in exposed things we should be able to react on certain actions

McCool: in use-cases of migrating serviants daemon interface should be standardized
... also examples like code migrations

JH: propose having written examples to avoid confusions
... we have local discovery

<McCool> using local discovery makes sense for this case, where "context" is local computing device

<McCool> however, I also think each compute node needs a special servient, the "servient-manager" (daemon, etc) that "manages" other servients

JH: next issue is https://github.com/w3c/wot/issues/234

<McCool> starting them, stopping them, etc.

JH: getting TD from Object

<McCool> anyhow... I need to check if that is already part of the proposal or not

<McCool> table it for now

<yingying_> https://github.com/w3c/wot/issues/234

e.g., with semantic annotations of TD

scribe: propose adding function like getThingDescription()

McCool: sync or async method?

JH: in this case it does not really matter

<yingying_> https://github.com/w3c/wot/issues/235

JH: next is https://github.com/w3c/wot/issues/235
... proposal from Sensor API WG ... getting closer to their interface
... wonder how portable EventTarget is...
... don't really have an answer

Zoltan: We did implement this
... target will remain in browser
... feasible to go around this issue

McCool: would aim for server-side script environments

<yingying_> https://dom.spec.whatwg.org/#interface-eventtarget

JH: would have choice target or emitter?

Zoltan: emitter can be done in browsers.. but not the way browsers usually do

JH: what is the right way forward?

McCool: suggest doing it in an abstract way.. fear that parts will be obsolete

Zoltan: would not spend to much time on that now...

JH: Shall we add abstraction level?

McCool: maybe having both (emitter and target)? Horrible?

Zoltan: promises and watchers ... and table it for now

JH: makes sense
... next issue, https://github.com/w3c/wot/issues/236
... API could be used in C and others as well
... add hints how to do stuff in dedicated language

McCool: guideline in safety critical C...
... kills callback functions

JH: think is difficult to handle .... in our scope

McCool: suggest having language independent hints: IF your language supports X do it that way..

JH: very good point
... next issue, https://github.com/w3c/wot/issues/237
... about adding query parameters ...

McCool: Wonder what we should define as parameter?

JH: would not go into those details.. just offerings passing parameters
... open questions: how to map to APIs and other protocols

Zoltan: suggest looking at actual candidates

McCool: also looking at use-cases

JH: Yes, let's look at actual use-cases

Zoltan: also maybe doing a poll in IG, what are the preferred languages

JH: can try... not sure if it changes a lot
... Next is https://github.com/w3c/wot/issues/238
... eg. consume thing on different thing.. interface changes
... need to be notified
... actions may not longer be available
... had call with SCXML...
... having state machine ... code is hooked up only
... next issue is https://github.com/w3c/wot/issues/240
... discovery should return callback (instead of promise)

Zoltan: cannot cancel discovery
... client can have timeout

<michael> need a promise model that allows multiple updates

JH: looking for a solution that works for on-going discovery and one-shot use-cases
... Have still a long list of open issues
... please provide feedback
... can discuss it at one of our web-confs
... also open new issues

Zoltan: propose adding "watcher" to github issues to inform mailinglist

<zkis> https://help.github.com/articles/managing-notification-emails-for-organizations/

McCool: what is the deadline for freezing updates.. Christmas was mentioned?

Joerg: will discuss that later
... also encouraging new implementations...
... so far we have 2 implementations

McCool: think we need open node.js implementation

Zoltan: plan to do an implementation (first Sensor API and then WoT)
... mainly scripting .. not TD

JH: will integrate issues raised today in issues
... target Christmas to resolve them
... thanks a lot for feedback

Joerg: continue half past 3

<kaz> [ afternoon break ]

<inserted> scribenick: kaz

Work organization

joerg: ToC
... WoT WG Charter
... Report from the Comm TF
... Open Tasks: security&privacy, implementations, liaisons
... WoT logo
... draft roadmap of PlugFest prep
... Meeting Logistics
... anything to be added?

(none)

joerg: let's talk about the WG Charter topic
... (shows the roadmap)

<ying_ying> WG roadmap

joerg: discussion about co-Chairs
... got nomination for the candidate co-Chairs
... Matthias, Kajimoto-san and Michael McCool as the proposed co-Chairs

-> https://www.w3.org/2016/09/wot-wg-charter.html proposed WG Charter

joerg: IG co-Chairs: Yongjing and Matthias
... IG deliverables: use cases, architecture, landscape and current practice
... (mentions expectations for the new proposed co-Chairs)
... any comments?

uday: work flow and collaboration between the IG and the WG?

<ying_ying> scribe: ying_ying

<inserted> scribenick: ying_ying

joerg: my understanding is that identifying building blocks in the IG.
... 1.5 years ago we started to identify the building blocks after the workshop in 2014.
... we identified those four. Do we think we cover the web of thing well?

<kaz> updated IG Charter

joerg: IG will work on identifying new things, plugfest. WG will work on development of the specs.

<inserted> relationship between the IG and the WG

joerg: any further questions?

dsr: first we need to make the WG charter on-going.
... we need to make member companies involved. In case there's comment to change the charter we need to bring back to the group for discussion.

<kaz> AC Review results (Member-only)

<kaz> kaz: we've got 7 supports so far. please contact your AC Reps and ask them to respond (positively :)

joerg: reviewing the rechartering of IG is like the exercise of reviewing the WG charter for AC.
... for the new chairs it's opportunities to talk with the member companies to see their expectations. Please use this month to outreach for the member company AC.
... appreciate the better setup of co-chairs. Thanks all the volunteers.
... we had several deliverables. for the landscape document, previous stakeholder Suomya changed focus to other things so that we need to find another volunteer.
... yesterday's PlugFest/Demo was good introduction to other w3c members. Matthias has made the report on the breakout report session.

Communication&Collaboration TF Report

joerg: IG blog: matthias has made a blog for Beijing F2F meeting. Will continue the work on blog.

<kaz> IG Blog

joerg: Call for implementation: we got quite a lot of response. This is the first point to collect all of them into wiki.

<kaz> List of existing implementations

joerg: matthias could you please give some summary of the PlugFest?

matthias: there are not many scripting. look forward more.
... realizing what is in proposals would be nice.
... is these be benchmark for implementations?
... we just have a list of implementation but really don't what they are doing. Is there any opinion on this?
... the overall goal is to promote what we are doing to a broader communities.
... what can we to help others to join in without coming to the F2F meeting?

Dominique: WoT label, implementation server @@1?
... this is the basic blocks that should be followed.

matthias: we released the current practice document for Beijing F2F and after that we make it to a living doc again.
... we will add new things. We need to make it more valuable for implementers.
... OK let's do that.

joerg: first step is to find the implementations. next step is to encourage the implementations to join our PlugFest.

matthias: not only open source but also internal/commercial implementations are appreciated.

ph: you need to prepare for what the WG will do.

McCool: agree.

dsr: Building upon what Dom said, I believe we should be more explicit, e.g. asking for implementations of the Current Practices, and a separate category for ideas around the Web of Things as input to the IG’s discussions

<dsr> s/@2/Building upon what Dom said, I believe we should be more explicit, e.g. asking for implementations of the Current Practices, and a separate category for ideas around the Web of Things as input to the IG’s discussions/

<dsr> s/be more explicit on our implementation/be more explicit on our implementation/Building upon what Dom said, I believe we should be more explicit, e.g. asking for implementations of the Current Practices, and a separate category for ideas around the Web of Things as input to the IG’s discussions/

dape: each time we need to identify what we will implement.

joerg: we need volunteer to work on it.
... daniel did it before alone. We need another one to help.

dom: people can go through questionnaire rather than go through everything.

joerg: yes. for the implementers they could ask instead of going through everything.
... could I ask Uday to do it together with Daniel?

uday: yes.

<kaz> Liaison wiki

joerg: liaison: we don't have contact persons yet from our sides for outreaching.
... can we put Yongjing's name for oneM2M.

McCool: I can be the contact person for OCF and IIC.

dsr: I want to add one which is OPC foundation. Please put myself for our side and @3 from OPC side.
... another one is @4.

joerg: for the OPC, siemens is also a member. Matthias can support the discussion. I would propose him to be the contact person.

dsr: I should be there as well.

joerg: For IPSo, Ari will edit it.
... when needing frequent exchange between the groups, it would be difficult if no contact person.

<akeranen> Fixed, thanks!

joerg: if there is name in the contact person of wot, he need to coordinate between these 2 groups. If not a name, it means we don't have close liaison.

<inserted> kaji: please add Echonet as well

joerg: send the information to yingying to add to the wiki page.
... another question is whether we should keep the joint meeting with other groups in W3C, e.g. automotive or device and sensor API WG. It would make sense to keep it.
... could McCool follow it?

McCool: yes, will do.

kaz: regarding the liaison wiki page, we can talk to the people during TPAC, e.g. Apple.

<kaz> W3C liaison table

kaz: btw, there are 2 layers for W3C liaison: interface layer(team contact) and technical layer(group members).

dsr: IoT event Berlin, we have the 2 page flyers and white paper for it.

<kaz> Event wiki

dsr: not only industry but also wot as foundation layer.

<dsr> IoTW conference http://industryofthingsworld.com/en/

<Zakim> kaz, you wanted to suggest we distinguish "events tbd" from "events done"

joerg: when you plan to join these events please let people aware of it and give support. probably we need to revisit this topic in our Feb F2F meeting. For the time being I would like to keep this topic informative.

<dsr> We had a W3C stand, a workshop on the web of things, I represented W3C in the standadisation panel, and the inventor of Industrie 4.0 gave us strong support positioning the web of things as the foundation layer for interoperability just above the industrial internet

s/ IoT event Berlin, we have the 2 page flyers and white paper for it. /We had a W3C stand, a workshop on the web of things, I represented W3C in the standadisation panel, and the inventor of Industrie 4.0 gave us strong support positioning the web of things as the foundation layer for interoperability just above the industrial internet/

<kaz> kaz: just wanted to suggest we put one line "Done" to distinguish the events already done from the events to be done

dsr: would like to have some words on joint white paper. This was a joint effort by 40 individuals from a wide range of organizations. The aim is to establish mindshare as to the meaning of the term semantic interoperabiity and why it is important for the IoT. I would like to link to it from our wiki as an external document as input to our discussions..

joerg: it can be input of our work and for our work as output.
...Flyers: you may already notice the flyers during our PlugFest.

<inserted> flyer PDF (Member-only)
...Flyers: Outreaching to W3C members for WG Charter is also a task for the TF for the time being.
... this is the status.

uday: considering the liaisons, we also need some fine-tuning work with lower layer alliance for our work. Do we also need some liaisons with lower layer SDO?

McCool: do you have something in your mind?

matthias: too much work. for the protocol bindings, we need to close to work with the sdo who make that protocol.
... if you have them, bring them.

uday: we don't have to do any work we just bring to our group what they are doing.

dsr: spread what w3c is doing with different level of liaisons.

joerg: we need to make sure what we do be supported by low layers.

matthias: the question is what is lower layers. We don't want to talk with radio layers.

cabo: one point could be security.

<dsr> s/@8/Carsten/

joerg: what are the objectives for these kind of collaborations?

<dsr> Dave: I am hoping to organise a further joint white paper, but this time around end to end security and the associated trust models. This would provide input to the W3C work in this area,

joerg: what is really meaningful for the group?
... we can sketch these for further discussion, especially for the security and privacy.
... we should be aware and think of what to move on.
... for next f2f we need to think about starting with 2 groups.
... what are the activities we need to do for it.

[joerg shows the tasks for next f2f meeting for both groups]

joerg: need to discuss how to pick up the activity for security and privacy.
... we had discussed already the moderation of liaisons and call for implementations.
... we need to discuss the preparation of restart IG incubation.

kaz: regarding the security and privacy topic, we had joint meeting with auto WG on Tuesday. Maybe we can continue the collaborative discussion with auto WG on this topic.

joerg: auto is quite obviously relevant. any other groups?

kaz: during the joint meeting with the Device and Sensors WG, there was a guy Lukasz Olejnik who was interested in joining the security discussion of our group.

joerg: Ari what is your expectation from your side as T2TRG?

carsten: it makes sense to continue our discussion on the security.
... some of the security works in IETF already in WG.

joerg: do you have any idea how it practically could be organized?
... try to understand what the architecture means. to use joint meeting?

carsten: good point to start the discussion.

joerg: any further comments to follow up on this?

matthias: hard to have people to work on it. don't have answer to this.

McCool: security is challenging for other orgs.

matthias: E2E security solution should be motivation to work together.

dsr: IoT Security Foundation

<dsr> Dave Rodgers is happy to work with us on security discussions for the web of things

joerg: we could continue the discussion with auto on security & privacy topic. is there any suggestion from auto people.

junichi: in auto wg we have the access control from OEM. in WoT world you can also consider the access control.

joerg: it is really the topic we need to think about how to proceed.
... do you have any comments on the handover of architecture and current practice document?
... joint with Yongjing, Matthias will think about how to restart the incubation tasks in IG.

[joerg shows the PlugFest preparation timeline for next f2f]

matthias: by tomorrow we will identify the new tech and features and solutions for current practice document.

WoT Visual/Logo

joerg: w3c marcomm said we should not use the icon as a logo for the time being.
... it will be discussed in the next 4 weeks in w3c marcomm but seems likely not logo supported. any alternative for this?
... maybe it could be a topic for dinner.

Logistics

joerg: meeting setup: how to setup the technical topics and organization topics in weekly webconf?

matthias: when there is recharter or f2f, there would be definitely org topics in the meeting.

McCool: tech topic could be done in small groups.

joerg: next f2f should be in US. maybe in California. We haven't yet a host.

McCool: will check if Intel could host it.

joerg: April meeting will be in Japan, Osaka. Date: 17-20 April.

<kaz> kaz: I thought there was some discussion during the Beijing meeting about the January meeting dates

<kaz> ... maybe we should conduct some questionnaire to gather preference to make sure?

<kaz> ... actually, I got an action item from the Beijing meeting for that but have not done it yet. sorry

<kaz> joerg: two possible options: 16-19 Jan / 6-9 Feb.

<kaz> ... maybe should go for the latter option (6-9 Feb.)

<scribe> scribe: ying_ying

<kaz> joerg: let's go for 6-9 Feb.

joerg: move Japan meeting to May?

[some discussion on the f2f meeting dates]

<kaz> (based on Sebastian's comment that there are only a few months since the Feb meeting if it's April)

<kaz> (TPAC 2017 in Burlingame on 6-10 Nov.)

<kaz> (AC 2017 in Beijing on 23-25 April)

[6.2.-9.2. US California, Intel?]

[15.5.-18.5. Japan, Osaka]

[24.7.-27.7 Germany]

[6.11.-10.11 TPAC2017 US California]

[adjourned]

- DRAFT -

WoT IG F2F

22 Sep 2016

Attendees

Contents