# WISHI virtual meeting

January 27th (Monday), 7:00-8:00 PST (16:00-17:00 CET)

Draft agenda:
* Upcoming meetings (AK)
* Next WISHI call: Feb 11th, 13th or 20th? Usual time, 90 min?
* Joint meetings with OneDM & WoT
* IETF meeting co-located activities
* Collaboration with OneDM (AK)
* Semantic Proxy with OneDM (MJK)
* see the [hackathon notes](https://hackmd.io/656Q6JeFRBiSOGQ3Swp3UQ) for details
* Data model design considerations
* Versioning (cabo)
* Number spaces (cabo)

Attending:

* Ari Keränen
* Carsten Bormann
* Michael Koster
* Michael McCool
* Lixia Zhang
* Klaus Hartke
* Sebastian Käbisch
* Ivaylo Petrov
* Niklas Widell
* (your name here)

## Upcoming meetings

Ari presented: https://github.com/t2trg/wishi/blob/master/slides/WISHI-20200128-slides.pdf

W3C WoT T2TRG joint meeting in Helsinki in June.

There will be WoT information night part of the ICWE conference. But Monday joint meeting is open to all.

WoT meeting during weekend and after Monday is WG meeting. Possible as IG members to attend as an observer; also non IG members possible.

# OneDM WISHI

Sebastian: Can someone give brief update on OneDM?

MJK: originally OneDM group came together to choose common models. Now project CHIP where focus on the short term. For OneDM work has not changed much but for people looking for fast converge are with PCHIP. This leaves OneDM more focused on actual common language of the original mission. Also rules and frameworks. Convergence of the models no longer focus.
Relative to TD, OneDM is more like what iotschema is. On the horizon there's a way to do this. We have achieved a language everyone believes can do the job, have set of models from different orgs. Number of orgs interested in doing this. Also accomplished that everyone will publish models in BSD3. Have achieved 1) common language framework 2) agreed to publish models 3) have good start for framework in place; github, CI tools by Joaquin Prado from OMA SpecWorks. We are rolling if you will. Last week had meeting where laid out what PCHIP does etc. Outcome was reaffirming commitment to whole idea of OneDM and will be participating. In terms of tech progress my presentation will have more details.

Sebastian: how plan to make data model; like schemaorg?

MJK: good part of discussion. Splitting off the connected home over IP activity, lot of the liaison aspects can be relaxed. Many were participating on the assumption they will contribute something going directly to their devices. That's why was closed; for IP concerns. But can be relaxed now. At some point OneDM participation more open. Some considerations to keep small to complete faster, but not so much concern anymore. Could work more with research orgs and be more open. Will have to think what that means in practice. Should be W3C CG? Everyone agreed on BSD license. Any kind of loose org should do. Even Github repo maybe enough. Lots of people want to know what they participate in; what is OneDM going forward. What delivering and demo'ing still being figured out. T2TRG, WOT, IoTschema are a group of activities that have decided to work together.

# Semantic proxy (MJK)

This group enables a workstream of semantic interop. And how we deliver that to stacks.
OneDM metamodel focuses on the style already done in iotschema, etc. Similar to Bluetooth and OCF models. Grouping of affordances to do something together like locking a door. Idea is to mix and match objects to create functionality.
Semantic alignment across industries is actions, events, properties. Using that here too. Similar to TD. But underlying data base of ontology that goes into annotating TD. TD describes instances of classes of this model. Short-cut lot of semantic reasoning. Define classes that you already know how to operate without needing lots of reasoning.
Abstract models will have protocol bindings, semantic proxy uses these. Proxy maps meta-model operations to protocol operations. To be implemented as GW or adaptation layer.
The different operations should be consistent across protocols.
Have done this in WoT but have not explored proxy pattern.

Would have two different TDs,one for consumed one for exposed. OCF app could talk to IPSO light device. Would consue light TD -- metdata same but protocol binding different -- would expose same metamodel with different properties. Need to figure out how to do all the mapping. RDF to the rescue here. Need some semantic statements.

Idea to start from RDF converter for SDF. Idea to take as a strawman, take oneDM SDF model and turn into iotschema descriptions. Want to make RDF statements that are useful with semantic tooling.
Trying to do bigger job that involves discoery. Not graph of descriptions of devices, but desciption of physical world. One thing to do is to map OneDM to RDF, iotschema style. But schemaorg doesnt want hundreds of property types, that need to be dealt with.

Some tools look promising: JSON-LD framing and RDF shape tools. Hackathon work looking forward to.

Enums going to be interesting. Typically enums are typed but we need to have them untyped. Idea to make URIs on enums.

Idea on Semantic APIs; human understandable. Using meta-model as programmign model. Seems NodeRED is good tool here. Declarative programming.

Cabo: definitions of 3 affordance types are little bit up for discssion. Agree, but they have to have some meaning. All three not the same thing. Need to distinguish the abstract model. If need BT command to do a read on property, that's fine, not taking abstract idea of reads. Need to maintain abstract model and be a little bit specific on that.

MJK: part of learning. Looking into incorporating pub/sub. Using model that sent the state to digital twin. From program point of view can provide same but protocol point of view looks different. Some interesting questions here. Also semantic grapsh where we connect physical things to devices. Recent work in industrial control suggests is to model plant with industrial control points. Looking back at BACNET etc architecture.

Sebastian: quite interested in tech details. Very close to what we do with TD. No surprise.

MMC: is it application of WoT. Use case for WoT proxy. One thing working on is use cases for WoT. Should incorprate semantic proxy to use cases. Should look closer how these connect.

MJK: Ege looking at proxy patterns. Ongoing stuff: intend OneDM be the way people write iotschema descriptions.

MMC: could propose link relation that points to SDF definitions. Need to discuss in WoT group. Would be helpful if SDF was standard.

MJK: need to add to discussion; e.g., link to point to. Already have that. Bigger problem relates to discovery. What we build to directory and what discover. Where we model physical world? We model in general RDF framework? Hope to make it to Helsinki WS.

MMC: two aspects to discovery: network, but what info is retrieved and how encoded. Want to keep separate. Don't want metadata to protocol. Need to think of TD SDF relation. In the same directory for discovery?

MJK: RDF and iotschema as what goes into TD

MMC: need to have this discussion in structured way. Could happen in TD call, WISHI, IETF. Would be useful if SDF was IETF draft. Would be able to refer.

MJK: let's have work stream on SDF standardization when we get together.

MMC: workshop good place for these discussions.

Ari: standardization aspects on agenda for the Friday WS

MMC: need to figure out what are the right places. In WoT group need to decide on the formal relationship. But TD calls now awkward time.

# Data model design considerations (Carsten)

Discussing this from OneDM PoV but applies wider.

Two kinds of versioning we need to discuss: model and language.

(We'll continue on this topic in the next call)