# WISHI virtual meeting
June 12th (Wednesday), 7:00-8:00 PDT (16:00-17:00 CEST)

https://github.com/t2trg/wishi/wiki/Agenda-items

Draft agenda:

WISHI research planning
* Modeling data and interaction
* REST-based hypermedia
* Connectivity for IoT
* In-network and edge computing
* Security
* Terminology

Attending:
Ari Keränen (AK)
Carsten Bormann (CB)
Christian Amsüss (part time)
Klaus Hartke (KH)
Solomon Kembo
Michael Koster (MJK)
Matthias Kovatsch (MK)
Dave Thaler (part time)
Niklas Widell (NW)

## Intros

AK: Discussing the research agenda for WISHI and T2TRG at large. Asked some of you who have been active earlier to contribute short descriptions for potential direction, where to focus, what orgs to collaborate with, etc.

Current draft input:
https://github.com/t2trg/t2trg.github.io/wiki/Research-Agenda

## Modeling data and interaction

MJK presented https://github.com/t2trg/wishi/blob/master/slides/wishi-modeling-mjk-20190612.pdf

Data at rest / in motion kind of duality with interaction. Even REST is interaction model.
Affordances: parallel to design like knobs and indicators. How do you manipulate things and what do you do with it.

Not many existing documents on the ideas. IAB IoTSI workshop RFC only. Not good academic publications here.

Lots of SDOs working on this. OCF has own templating. Zigbee has publicly described models, like Bluetooth -- with terms of use. OMA has LwM2M management objects and IPSO objects. In OneM2M semantic models. All candidates to work with and contribute back to.

"Arch-SDOs" trying to avoid the +1 standard issue. Figuring out how SDOs can work together. OneDM collaboration of existing SDOs and focusing on devices. Also involved in schema.org extensions for IoT; focus on domain experts. OneDM, schemaorg, and W3C WoT using common metamodel. Trying to have common tools, methods, practices.

Other activities: one describing how sensing/actuation done, ranges and units. Another on sensing/actuation. Some ontologies where there was a pain point in automotive, for example, Genivi IVI. Lots of progress on connected buildings. Developed in W3C, connected to IoT schema and WoT. Semantics of things of what we call Feature of Interest.

Models in the purview of device manufacturer, connected to physical features (e.g., temperature). Then also models describing where things connect to. App domain specialist will develop the concepts and don't need to redefine sensing and actuation. Can be many-to-many mapping from different sensing to different FoIs.

Research questions: architecture; how to connect sensings and FoI models. What do the (RDF) triples say? How does app reason about those? We don't know anything of that. Not many working examples.
How can we build hypermedia controls, what is the architecture, with annotation? Data different from interaction? What do the APIs look like?

How can we standardize semantic modeling? How make models and languages evolvable? With reuse and evolution? Normalization and adaptation? These issues are coming up in the work where building common models accross SDOs and vendors.

Everyone looking for guidance from open broader orgs like IETF/IRTF. How we standardize hypermedia patterns? The Swagger APIs are not REST; just enterprise API management tools. How we integrate hypermedia here? What do the standard libraries do? How we get beyond NodeRED? How we connect FoIs with other descriptions? How to integrate discovery? Build semantic directories?

Can we build something that can live beyond our test events? Place for models? Doing research and understanding the issues beyond next quarter goals (that some other orgs have as priority).

CB: how many abstraction levels do you have to work on at the same time? When modeling a door, can model as number of sensors and actuators, and just incidentally link to feature that of a door. Or abstract from all details and "it's a door that can be opened and locked". Then don't need all sensor details, but higher level abstraction. Without "doorness" not easy to talk at that level. With RDF get sea of triples but not necessary all the abstractions nicely. Some apps really still can do useful things without fully understanding what job of the thing in the physical world is. Asset handler may be interested if door works and its physical location; when was it bought / who bought it. Don't know how to structure the heap of semantics. Sensor/actuator distinction useful but may not be the only one.

NW: is there a need for something like degrees of abstraction? Find out it's a door and drill down to details. "Open door" action maps likely poorly to how things work below. Push door or something else. Something to look into?

MK: problem that these are different dimensions and hard to have order of abstraction. CB gave example of management of a door, MJK had FoI of door, could also be repairment part of a door. What app perspective come up with, different abstraction levels. But definitely interesting question how to model.

MJK: sea of triples quickly gets large. Even with property values. Different dimensions. Have applications that know semantically ahead of time where to look for. Need lots of bootstrap understanding. There get to events, actions,vproperties -- how to categorize things with objects that can identify to be related to a fairly narrow physical model, like temperature. Then we have operational stuff. Then we have MUDs, provenance data, service data -- with washing machine want all parts as an ontology. Some other app might have other context for "where a water leak is coming from". Have to get there. The meat of the research. What part can we do is a good question?

NW: not sure if dimensions problem. In any system any amount of viewpoints: operator, builder, owner will have different interests. One of the harder problems how to structure.

MK: Can take pragmatic and take Thing Description for a product and augment that. How we build domain specific objects, for example for shipping. How the patterns work? How we manage that is one of the questions? How we build tools and patterns that allow domain experts to bring their definitions.
Don't want someone in IPSO to worry about structure of washing machine, but provide tools to those who can do. So they can sit down with JSON and build definitions. Will need domain experts, and model loosely enough to not break things with small changes to the model.

NW: agree; when talked earlier about engineering principles, that's also important part. How to tell domain expert what is the good way to go forward with design.

MK: also interesting experiences when working with different domain experts. Building information modeling can specify how walls are constructed, for example. That info is then handed over to a construction company so that they build correctly. Installation company puts network in place and another one lightning. Interesting that they all depend on each other and have to exchange information. Different domains with different tooling. Hard to create something that goes through different stages and handles complex lifecycle. Another outlook: when building finished, have different views like fire/safety, room temperature, etc. Interdisciplinary approach interesting.

CB: lots of good points here where we could go and do. Was struck by MJK's statement that meta-architecture isn't written up yet. Maybe first step where we should go. Won't help with other interesting questions but maybe really important to start that going so that there's a doc. And relates to terminology work too.

MJK: not good open access documents. Some private journals maybe. Good opportunity to help.

CB: seems this is a core subject of WISHI and we need to make some progress and generate docs. Have good base but writing things up will likely uncover issues. Also need meetings with people who will do writing.

## REST-based hypermedia

KH: can talk what has happened so far. Didn't have research agenda yet, but general idea is to continue along the lines of work so far. Have had hypermedia calls with number of authors of different hypermedia formats: TD, JSON hyperschema, CoRAL, and with other experts. Purpose of the calls was to align with common terminology we're using in our specs. Made some progress with terminology and were presenting approaches. Would be something to continue. Another thing this year was after IETF in Prague: the editors of WoT TD and architecture docs met with T2TRG people and spend a few days in front of a whiteboard. Defining theoretical underpinnings of hypermedia and how they map, e.g., to RDF. One interesting outcome similar to RD discussions on directory of links vs. directory of resources: a link model and a resource model in RDF. Interesting to write up and bring this forward.

Some things discussed for a while has been benchmark scenarios in T2TRG to showcase hypermedia approaches and compare them. We never really found good examples. We had exercise with light bulbs but that turned out to be more complicated than we thought. Could here elaborate on Carsten's coffee machine. There was already a SPLOT modeling of Carsten's coffee machine. Tried to imagine how to do that with CoRAL. Something interesting we could further look into. Always automatically coming interesting questions up, but haven't written down those yet.

AK: Next steps: write some of the research questions down and gather interested people to work on this.

MK: part of hypermedia concept, tried to do my best to write something to WoT arch doc <https://w3c.github.io/wot-architecture/>. First doc where affordances are pinned down more. On the line between T2TRG and WoT, but something we should review in broader. On the track to make this a standard. More to continue. Recently discussed rechartering WoT and discussed hypermedia controls. CoRAL is a solution to point to multi-step process that is provided.

## Next meetings

CB: we have material for many discussions; could have a look at the cadence where we should meet to discuss these

AK: Wednesdays seem to be quite bad, but what days and cadence work for people? (Mondays and bi-weekly got support).

(call concluded)