See also: IRC log from Day 1 and Day 2
<dsr> scribenick: dsr
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
<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.
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
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 ]
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.
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
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
[ Lunch ]
<kaz> scribenick: kaz
victor: explains the Hydra breakout
johannes: explains the scripting API breakout
joerg: scripting API here at 5A
... Hydra at the space next to 1.10
johannes: IRC channel for this room is #wot
... Hydra breakout uses #wot-td
dape> scribenick: dape
JH: see issues on Github https://github.com/w3c/wot/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20%5BScripting%5D
... Nimura-san has further feedback
... more developer feedback ?
... none so far
... recaps API description of current practices document
<dape> --> http://w3c.github.io/wot/current-practices/wot-practices.html#scripting-api
JH: API root object
... allows to create composed thing or exposed thing
... so far we did have 2 PlugFests with API support
... based on 2 different teams
... got feedback
... details such as actions without parameters
... any feedback is welcome... please open github issue
... also add "tag" on GH
... Would like to ask Nimura-san for his feedback
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
<kaz> ACTION: Johannes to integrate issues from the Scripting API breakout in Lisbon into the GitHub issues [recorded in http://www.w3.org/2016/09/22-23-wot-minutes.html#action01]
Joerg: continue half past 3
<kaz> [ afternoon break ]
<inserted> scribenick: kaz
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.
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
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: 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> Event wiki
dsr: not only industry but also wot as foundation layer.
<dsr> IoTW conference http://industryofthingsworld.com/en/
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.
<Zakim> kaz, you wanted to suggest we distinguish "events tbd" from "events done"
<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.
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.
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.
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> scribenick: kaz
kaz: I thought there
was some discussion during the Beijing meeting about the
January meeting dates
... maybe we should
conduct some questionnaire to gather preference to make
sure?
... actually, I got an
action item from the Beijing meeting for that but have not done
it yet. sorry
joerg: two possible
options: 16-19 Jan / 6-9 Feb.
... 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)
RESOLUTION: F2F plan
... Feb. 6-9 US California (Intel?)
... May 15-18 Japan, Osaka (Panasonic)
... July 24-27 Germany
... Nov. 6-10 TPAC2017 US California (W3C)
[ Day 1 adjourned ]
<inserted> scribenick: DarkoAnicic
Joerg: recap the activities from the first day W3C Wot F2F
Kajimoto-san: proposal on a lifecycle
model for TD
... the discussion on the topic will be continued via mailing
list
joerg: to demonstrate the lifecycle, we could try at a plugfest to connect things at have one thing changing the TD of another thing during the lifecycle.
Johannes: proposal on events/subscriptions - micro use cases/application patterns
<ying_ying> RESTful handling of Subscriptions
Johannes: we have identified 5 tasks and volunteers to work on
Dave: we distinguish two levels: application level and the protocol binding level
<ying_ying> scripting API issues list
<dsr> along with the role of simple negotiation, e.g. where app requests some characteristic and uses introspection to see what the given protocol binding is able to offer.
<ying_ying> issue 235
Johannes: we work on integrating into the API. Please provide your proposals by creating a pull request and discuss it over web conferences
Victor: report from the discussion on TD & hypermedia control (Hydra)
<ying_ying> TD vs Hydra
Victor: the question was whether we
can use Hydra to model TD interactions
... Hydra could be used for modeling operations of properties and
actions
... discussion on supported protocols by Hydra
... an extension of scritp API could enable Hydra
... discussion on Hydra will continue. bergi and Victor could take
action on the implementation part.
Dave: we should invite Hydra community to participate to our plugfests
<dsr> Dave: Hydra can be seen as another kind of netowkr services platform, and as such one that the web of things should be able to accommodate. We should consider inviting the Hydra CG to participate in a future plugfest to explore and demo such integration.
Cesar_Viho: presenting F-Interop platform - an EU H2020 project
<ying_ying> F-Interop Platform
Cesar_Viho: it is about a platform
for remote conformance tests for SDOs and SMEs
... different configurations will be possible to test
... 32 testbeds, 4755 nodes across Europe
... different standards are targeted, e.g., CoAP, 6TiSCH, 6LowWPAN,
ETSI. Posibility to include oneM2M and W3C WoT.
... we are here to explore this possibility.
Federico: presents an example of CoAP
test
... status - the infrastructure is under development (not yet
done).
... shows a demo for F-interop - interoperability test Copper
running against Californium
Joerg: how do you specify test cases?
Federico: 2 files are needed, the
test (description) and test analysis
... tests can be provided by anyone, i.e., not only platform
operators
... simpler than TTCN-3
... the platform will be available next year, for the detailed
timeplan see the slides
Cesar_Viho: please help us with
requirements from W3C WoT to be addressed in the platform
architecture
... contribution to provision of tests will be paid
Dave: thank you. The platform is interesting for IG and for the WG pretesting
<dsr> Dave: I note that the WoT IG could play a valuable role for exploring how to do testing in support of the WoT WG, which will formally define the set of tests needed for REC track specs
I am also interested in how tests can be applied to different layers in the abstraction stack
<Zakim> dsr, you wanted to ask about anaysis of testing use cases for patterns that could be used to define declarative test specifications
Dave: would be good to have a possibility to declarative specify tests
<dsr> I have two questions: the first is whether you have looked at about anaysis of testing use cases for patterns that could be used to define declarative test specifications
Federico: it needs to be discussed in the phase of defining requirements
<dsr> The second is how tests can be applied to different layers in the abstraction stack, and whether you have explored that in practice?
Johannes: a proposal to look for a language for behavioral tests
Joerg: could you please explain more the details about different components in the architecture, e.g., agents
Federico: agents support flexible testing.
Matthias: we want o support multiple
protocols. How to find a good strategy to define tests and not to
have explosion of all possible combinations of features for diff.
protocols etc.
... could you support the testing for online plugfests
Cesar_Viho: yes, we will work on
this
... we will work on a reference model to support multiprotocol
testing
Kaz: W3C has a test facility but your platform can extend our infrastructure. Hope it can be integrated.
Cesar_Viho: we need to study how the integration would be possible. But we offer a complete platform
<dsr> Dave: I see a need for work on understanding what kinds of instrumentation hooks are needed for Web of Things servients to support higher level testing. This sounds like it would need coordination with your group if we are to be able to integrate with your framework. How do you see such a collaboration working?
Federico: we are open for colaboration, let us talk.
Joerg: proposes to set up few simple tests from our existing test suit.
Cesar Viho: agrees with the propsoal.
sebastian: how to enable tests for small devices, microcontrollers w.r.t. authentication etc.
Federico: the authentication is needed, but we will find a way to make it working for small devices too.
Joerg: thanks, we will organize a
follow up.
... coffee break. WE will continue at 11:00.
<kaz> ACTION: Joerg to organize follow-up discussion on F-Interop [recorded in http://www.w3.org/2016/09/22-23-wot-minutes.html#action02]
<inserted> [ morning break ]
<ying_ying> https://www.w3.org/WoT/IG/wiki/images/e/ee/DemoScriptForLisbon20160922%28WotPUB%29.pdf
<inserted> scribenick: uday
yuki: UNI Universal natural
Interface, not only develops logic to IoT but also interface
... UNI projects real world onto cyber world
UNI product descriptions
address mapping of real world ip devices to UNI addresses
basic structure of vertex discussed
oVo - represents everything as vertex in graph data
oVo briefly dscribed
oVo- 32 byte ID 16bytes for UNI ID+ 16 Bytes for IPv6 adress of host
ovo is like apointer to memory
UNI software landscape presented
noifd is interface to kernel application
for WoT servient a new service can be implemented above the noifd
associations between UNI and outside UNI discussed
main customers are in healthcare and medical sectors
UNI system can communicte to external services over WoT interfaces, but currently they dont have it
but would like to implement in coming months
UNi system could run WoT script on UNI system
supports may languages and interfaces
all binary is stored in integrated server
UNI system demonstrated
Demo scenario: connect devices to UNI n/w with UNI UPnP
play song in multiple rooms
real time demo of network buldup
real time connection of new vertices
can play media on any device in the network
also gathers context and modifies play list accordingly
next steps: going to implement WoT interface
join next plug fest
Q1 2017- UNI peripherals SDK release
in design phase of other products- UNI ZMOT
UNI home server in design
Jorg: thanks yuki
sebastian: do you rely on existing ontology or do you define new one
yuki: can use existing semantic but user can add new
Johannes: what are different interfaces about
yuki: we have a translator ot the graph layer
johannes: is XPIF translated to any other protocol
yuki: explains path to talk between
devices
... internally there is own protocol but can have any external
protocol
... UNI has some part of propreitary
Kaz: Questions life cycle management of cyber mapping
yuki: have mechanism to update data itself, so easy to maintain for clients
Joerg: thanks, need follow up on this and good for plugfest activity
yuki: will implement WoT interface and would like to join next plugfest
Joerg: is interfacing vis OIC for protocol mapping possible?
yuki: yes we could
End of session
<kaz> [ lunch till 1pm ]
<kaz> scribenick: kaz
how to enter the PlugFest is not clear
mk: good to have strategy
... need to skim all the resources and see if need to update
... we could improve communication
Preparation feedback:
- How to enter the plugfest not clear
- simpler to find the plugfest page for implementers as landing page
- plugfest does not look in the Web as awsome as it looks in the clear structure in real
- The WoT Pitstop (e.g., Coap.tech)
joerg: volunteers?
<domguinard> EVRYTHNG would volunteer for that
mk: how/where to publish
things?
... would be better to have some official server?
jh: could host a gh-pages branch
dom: pretty easy
joerg: who would take the challenge
for this idea?
... Dom and Johannes?
mk: bringing our own wifi router would be easier
joerg: move forward to the technical topics
seba: maybe would make sense to restructure the Thing Description
mk: Experiment with Actions, Events
and Subscriptions
... monitoring, canceling, update as well
dsr: lifecycle concerns
kaji: depends on the demo
scenario
... Thing Lifecycle topic should be included in the "Scenarios"
section
jh: would make the preparation easier with PlugFest Buddy for new participants
dom: next step for complexity?
joerg: what is your proposal?
dom: we have lights and so on and they talk with each other
mk: what kind of interaction should be included?
dom: make sense to discuss the
scenario as the group
... beyond the device, there is a strong concept of connecting with
larger ecosystem like social network
... brainstorming on the scenario?
joerg: adds: bringing things to the Web. What could be a fancy one?
mk: Daniel has a robot. maybe would fit with the scenario
seba: should consider security more
joerg: adds: restart security
scenario based on the Nice PlugFest
... non repository-based TD scenario
mk: discovery API
jh: yes, discovery would be appealing
mk: maybe we could move one script API from a servient to another one
joerg: adds: existing/potential/upcoming runtime implementations: TNO, Siemens, Intel, Fujitsu
jh: we might want to brainstorm
this
... can join the plugfest by accessing a Web page, etc.
joerg: what about protocol mapping?
mk: proposals started but people are
busy
... maybe Panasonic and Fujitsu could work on Echonet Lite?
... to restart the protocol work
... UNI also might want to join
yuki: wonders
... probably we could work on some protocol for medical use
cases
... we can join the discussion on protocol binding
joerg: would be great
mk: what about Jonathan?
... you sent some idea to the ML
jj: we can use Web browser as a universal client for IoT
mk: we would need Web browser
vendor
... TD could be loaded and rendered on a Web browser natively
joerg: ok
... any other ideas?
(none)
joerg: we still have two topics
... reorganization of TD structure
... and synchronizing Things and Proxies
darko: joint discussion with geospacial
<JonathanJ> my proposal mail - https://lists.w3.org/Archives/Public/public-wot-ig/2016Sep/0032.html
<dsr> scribenick: dsr
Sebastian presents his proposal
Today we have a basic structure with the name of the thing, fields for describing how to access it, and the application interaction model (properties, actions and events)
<ying_ying> Thing Description Restructuring
<Maxime> https://github.com/w3c/wot/tree/master/proposals/td-restructuring
Sebastian: some people are unclear when to use properties or actions when you want to model something that is mutable.
Dom: in our experience, we require properties to be read-only
Carsten: we are not going to have some a clean world, there are going to be mutable properties
There will be many sequences of operations we want to support. I am in favour of unifying this somehow
Sebastian asks Dom for clarification on the EVRYTHNG approach
Carsten: in a Yang model you can say that a field is config true, but it doesn’t say how
<JonathanJ> IETF YANG - https://tools.ietf.org/html/rfc6020
Matthias: I expect that there will be a demand for a richer interaction model
<cabo> config true = "config true"
Matthias: we still have to have the synchronisation discussion
I see a separation between the informational and physical world
Dom: we use different constructs for those
Dave: there is a broad consensus across IoT work by many groups on the utility of properties actions and events, this is about the way people think about the world
It has stood the test of time for the GUI paradigm
act ta
Taki: I support keeping properties and actions separate, as programmers expect and understand these
Johannes: there are protocols like @2 where you have the split with properties and actions. There they distinguish between the desired state and the last reported state
<sebastian> q
Dave: you often don’t know the true state, only the last report of the state you have had
Dom: NEST also distinguishes these.
Failure is also hard to do synchronously
Dave: the thing description can provide synchronous checks on allowed updates, but errors may take time to report when the latency across the network and sleepy devices is involved.
<inserted> scribenick: kaz
kaji: how about generating a small team for further discussion?
seba: during the Sunnyvale meeting, there was the first version of TD
mk: do you have better ideas about the proposed interaction model?
<inserted> scribenick: dsr
Sebastian: I am not looking to collect or resolve all issues now, this is just the start of the process
Matthias: we should discuss accountability, and the ability to see who/what triggered some change, this relates to the notion of subresources
Sub-resources provide a means to help address distributed systems.
e.g. the fact that it can take time for changes to take effect
<kaz> scribenick: kaz
nimura: what is the actual Action to be implemented?
mk: would generate a table of expected Actions
seba: some points here have been
already touched
... so far nobody has used Events
jh: we're still working on protocol
binding
... maybe not "Events" but "Event source"?
... which way to be used for what?
... Events, Properties, Subscription
<Zakim> dsr, you wanted to note that the current representation uses an array of properties and allows multiple definitions for the same name, this feels wrong and is easily fixed
dsr: multiple definitions for the
same name allowed
... feels wrong and easily fixed
seba: container of interactions
... characteristic of "@type"?
dom: don't fully understand the difference between Property and Event
<dsr> Dave: we have thirty years of widespread experience with properties, actions and events, the GUI paradigm represents huge mindshare for developers and end users alike
<Zakim> jhund, you wanted to query about @type and semantic types for props/actions
<DarkoAnicic> +q
jh: uestion on @type and semantic types for Property and Action
da: what is the actual exchange in this sample?
seba: shows the current
structure
... and restructuring sample
... @type is just an array
... property and maybe event as well could be contained
mf: understand your point here
... but isn't there a concept model behind this proposal?
... what is the concept model of TD?
seba: shows the diagram on TD concept
zoltan: resource type is used for
discovery with OCF
... maybe "@type" is not a good name but we need additional
information for discovery
mk: we don't have good model for
vocabulary
... serialization as JSON-LD
seba: this is a very big topic
... proposed next step
... setup Web meetings about this topic
... get an agreed TD version till the end of Oct.
joerg: would be better to fix TD asap because it's a fundamental building block
mk: what's the implication for
implementations?
... easily extract patters?
<dsr> Dave: I think it is important to work on developing a rough consensus on the requirements for thing descriptions as an output to the WG, and this can be done independently of the serialisation formats
seba: how to organize this TD
call?
... separate call or part of the regular call?
mk: would suggest generating some
initial proposal by a small group
... and then bring your proposal to the main call
taki: Event and Property
... Event is not closer as Action
dsr: generate requirements for TD regardless of serialization would be good input for WG
<kaz> ACTION: Sebastian to organize a TD Restructuring call [recorded in http://www.w3.org/2016/09/22-23-wot-minutes.html#action03]
mk: we've already heard about
Property, Action and Event
... missing people for Bluetooth low energy
... volunteers on HTTP: Johannes, Panasonic
... CoAP
zoltan: Node.js based and browser based
mk: can join PlugFest?
zoltan: Michale Koster has generated a demo
mk: I've created Bacnet demo
... different protocols to be handled
... I can provide some experience on Bacnet
... Lemonbeat as well?
... Louay working on Homekit
... would have a new placeholder
dom: zigbee
... interested in how to implement demos
mk: flexible structure of
resources
... firstly we write demos manually
... for Bacnet there is a domain specific ontology
... you could implement clusters
... first manually and second automation
... Zigbee is good
dom: Zigbee and Bluetoogh
mk: sometimes you don't need discovery since everything is there
dom: our gateway converts these protocols
mk: offline conversion is
interesting
... welcome to the TF :)
... your name to be included
dsr: could we have better public pages with a view to inviting help from protocol experts?
mk: improvement of the current
practice document
... main thing I'd like to work on
dom: specification for the payload?
mk: can use content-type
seba: MQTT is one of the popular
protocols for IoT
... MQTT people should also involved?
mk: OCF or OneM2M is an example
(some more discussion on liaisons)
mk: there is nobody here who uses MQTT for products
dom: we use MQTT for products
mk: what do you connect with MQTT?
dom: from the cloud or gateway, easier to use WebSocket
mk: having a starting point would be
good
... who provides MQTT solution?
... customers already have MQTT?
frank: project collaboration
mk: it's beyond our Charter but bridging with MQTT would be interesting
<domguinard> this is what I meant as you can specify the sub-protocol, as the as part of the original handshake: Sec-WebSocket-Protocol: mqtt, wamp (for instance)
jh: maybe we could come up with a proposal to involve MQTT people?
<domguinard> https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers
dsr: there are many sub protocols
<michael> We do have mqtt protocol binding work in progress, is this different?
dsr: exploration by the IG would be useful
mk: any other comments?
(none)
matsu: discussion on deployment of
WoT systems during the Montreal meeting
... (shows the Architecture document: http://w3c.github.io/wot/architecture/wot-architecture.html
)
... 5.4 WoT servient on Cloud Server
... (goes back to the slides)
... Background
... synchronization between multiple WoT Servents is required in
some conditions
... WoT Servients has resources corresponding to devices
... Synchronie WoT Servients
... message handling
... two kinds of virtual devices: original one and shadow of
that
... Control actual device from App script
... Handle event from actual device
... when the legacy device generates an Event, the original device
gets synchronized with the shadow
... What should we do next?
... how to search original devices on GW from the cloud
... how to synchronize device resources between WoT Servients
... how to communicate via firewall between the Gateway and the
Cloud
... also should consider how to handle time critical devices from
the cloud
dsr: worth discussion on time-critical synchronization
matsu: many building blocks are involved here
mk: have quite a lot of ideas
<dsr> Dave: I too have worked on this and have implementation experience to share
mk: how to proceed?
<michael> I have had good results using a pattern like subscription with MQTT transport to synchronize state between gateways and multiple cloud servers
matsu: would prioritize the
domains
... there are many companies in PlugFests
... could be a target for the next PlugFest
jh: the question is how to describe
the situation?
... what if there are 100s of devices?
... might want to think about early prototypes
... for one of the future PlugFest
matsu: 1000s of devices are possibly
connected
... smart house includes many devices in it
... some kind of abstraction would be needed
jh: you have one thing and a
shadow
... could be for multiple devices?
matsu: it's another issue
mk: we have different building
blocks
... shadow replacing an actual device
... and a shadow app on the cloud
... kind of like the Microsoft architecture
<michael> this is how a lot of cloud services work today
<michael> the interaction is with the shadow
matsu: yeah, there are similar approaches
<michael> which is a proxy for the device
dsr: you have a gateway, cloud and
application server
... a long proxy chain
<michael> The app may not ever know the device address
dsr: definitely interesting to discuss
yuki: question on proxy vs actual
servient
... many proxies can correspond to multiple servients
mk: Matsukura-san, could you organize a call for participation for this topic?
matsu: yes
<kaz> ACTION: Matsukura-san to organize a Servient Synchronization call [recorded in http://www.w3.org/2016/09/22-23-wot-minutes.html#action04]
joerg: great discussions for this
afternoon
... tx for the staff's supports
... demonstrations and joint discussions during this week
... organizational topics as well
... tx for the staff again
(our pleasure :)
joerg: and tx again for all your supports!
cabo: IRTF joint meeting
Saturday/Sunday
... some of the discussions from this WoT IG meeting will be
handled there
joerg: tx again and have a safe trip back home!
[ meeting adjourned ]
