# WISHI virtual meeting

February 20th (Thursday), 7:00-8:00 PST (16:00-17:00 CET)

Draft agenda:
* Data model design considerations (cabo)
* Versioning
* Number spaces
* Semantic Proxy with OneDM: hacking plan (MJK)
* Planning for OneDM joint activities

Attending:
* Ari Keränen
* Carsten Bormann
* Michael Koster
* Solomon Kembo
* Bruce Nordman
* Klaus Hartke
* Niklas Widell
* Christer Holmberg
* (your name here)

## Data model design considerations (cabo)

Also a new draft on this topic: how to version features to SenML.

Discussed versioning at large earlier. Now focusing on what that means for OneDM in particular and modeling / model instances. Need to distinct versioning of models and versioning of language. Easy to confuse these. Also for model could have different kind of capability sets. Need to be careful thinking which part we are discussing.

Last talk was recommending using features instead of linearly moving forward on "version line". Indicate what using. Offering capability (in particular for model version). Unidirectional announcement. "I can do something". Peer can always ignore capability and nothing bad happens. Different from feature that says "we are doing things differently now". New version of language, say Python 2 vs 3, the writer and intepreter of code need to agree on that. Result of negotiation. Common context: feature is there and in force. Needed to avoid false interop.

Both kinds make sense, and we need to be aware which one we're talking about.

Versions and features are dual to each other. Could be feature string "SDF2.0" that would be both. We don't need versions if we have features. Rest of talk only about features.

Here talking versions of protocols. Also revisions for specs for example; update for copyright year, for example. Important changes in file, but not changing feature set of protocol. But some typos do change data; in SDF "writable" written wrong way. When change that, you do have new feature of language. If someone (machine) uses the new spelling and someone expects the old, we have failure.

May need to model capability indication at the model level. Different from implementation capability.

At language level, always declaration of model file that is using particular language features. Unidirectional declaration. Usually no negotiation. In SDF for instance, we could have something in header component that says what model features beyond basic features are needed. Would give us some evolvability. But needs stability of the overall syntax, for example distinction between header and other elements needs to stay invariant. But relatively easy to structure models that way. With JSON we don't have changes in surface syntax. Removes one source of instability. Proposal here is to have something like "require" element in the SDF header. Indication of which language features beyond base are required to interpret this model.

MJK: require reminds how RDF instances are construcured, by pulling in vocabularies. This is like modular and pluggable. Couple of qualities, like base SDF and required features, one could be particular kind of ID numbering syntax. Could someone not using ignore? Would need special processing on some of these to even understand contents of SDF?

Cabo: interesting question if can have ignorable features. Conditional semantics. But basically meant to be modular so that can add features what want to use, put them in require header, and receiver can check if have all the needed features. Optional features maybe worth expanding on.

MJK: protocol binding for example would not change the base spec. Could use URIs for them or arbitrary strings.

Cabo: easier to coord feature names with URIs. If some central entity evolves SDF, could be priviledged to use just strings. But could be something like protocol binding feature but impementations that don't understand bindings could still use the model. That would make sense.

Niklas: as models grow and get more features, trying to figure out compatilbity gets more complex. Good examples what happens with lots of features?

Cabo: bits you set or resets you can compare like versions. If feature is a subset of another, you have all you need. Not particularly difficult. But want to do roll-ups eventually. Features don't necessarily complicate things much. Maybe some restrating is a good recommendation here.

Ari: SenML versions a good example here; limited by the lenght of the value used for bitmap.

Cabo: currently a proposal

Klaus: how much value indicating features vs just using them and getting an error?

Cabo: would be distributed feature mechanism. If you have interpration of something more strict, hard to tell if that feature is used or not. Sometimes just convenience. If know SGML, that had humongous thing that you could put on top to declare all kind of features and limitations. But you don't want to do that. Argues for restraints. Detecting that you don't have a feature that is needed to correctly undertand model is difficult.

Klaus: one problem: declarations can get out of sync with what is used in the actual file. For features, makes lots of sense to classify them. If feature changes the semantics of a document.

Cabo: using a feature that always causes error, might not need to be declared. But still useful thing to have that capability.

Ari: linter could be helping here at least for SDF

Klaus: Is breaking change if you later require new features? Define some data model for IoT device tht uses certain features but not other. Then in future require new features, is the DM still compatible with old model? Is it still same model? Same ancestry?

Cabo: might be able to interop with new model with something that is using the old model. Different levels of language and mode evolution. Could maybe use a new language feature to clean up a model but would be able to interop with older impls.

Klaus: do we use features for both langauge or model features and how we tell them apart

Cabo: both, but no proposal yet how to indicate model features yet

Ari: sounds like interesting idea to spend time whiteboarding in the Friday meeting

Cabo: need some concrete models and think how they would evolve and the apply this thinking

MJK: need to test them out. Can try to think through but doesn't work well. Should have test cases and run though. Also "require" could be something that is required and then another one like "uses" that is optional.

Ari: we do have already real SDF models and some examples of evolution for IPSO models for example

MJK: could also try protocol bingings etc. That's especially example where we maybe rather have mapping file but having example of both is good to find out what's easier. Might be default protocol binding but could also have 6 bindings in one file? Idea of bindings being a separate thing like for TD.

### Numbers and code point spaces

Probably would be part of protocol bindings. We should be able to cater for two different kind of spaces. One is of that used by an ecosystem. Make sense in the ecoystem but not necessarily elsewhere. Need to attach those to model. But might also have global numbering. Something that is part of the model. Model says "we have 3 different colors, red is 1, blue 2, green 3". And numbering would not change for ecosystems. Same true for strings. Data needs to be managed in the model. Numbers don't always go to mapping files.

For ecosystem specific numbers the question is where to put those. Putting them in common models you have all the info in common place (good) but adding ecosystem means a new model (bad). Merging problem. Not a good way.

Bette way: put those numbers to separate files that are ecosystem specitic. But need hooks to tie these numbers to. Hooks need to be global. Would need essentially generate code point space we use. In some places comes free of charge: we already need naming scheme for models. IPSO models could hook up there. But in other cases might need additional work.

MJK: in SDF we have each definition with unique path. JSON pointer one way to express that. Way mapping files work: each path can have ecosystem specific IDs that attach to that. Is that sufficient?

Cabo: might work. We should look how brittle those are.

MJK: in general true. We're currently using as the unique ID. Would use in RDF ID strings. We should really think the implications of having these paths for decades.

Cabo: maybe design requirement for componets of modeling language that need to keep the JSON pointers non-brittle.

MJK: doing that implicitly in iotschema. Really good to make a line item of this.

Ari: took this approach with the IPSO model conversion

MJK: generally as "here's URI to my thing". RDF wants to be flat for this reason. We need to look how stable are our path hierarchies. We should look into this. How stable are these paths is the question.

Ari: we have ecosystem specific prefix and then A/E/P followed by that's name

MJK: in JSON pointer easy to have unique names. Explcitly labeled. Each node labeled with SDF name like odmProperty. The fact that these IDs follow UML diagram may actually give us the stability. Maybe not a big problem due to the way we organize the namespace in SDF. The benefit of rolling up all contributed models to same namespace. Maybe it's already stable; need to look for corner cases though.
Sometimes numbers are global, sometimes context sensitive. Some things are like version numbers in models. Having name spaces and URIs and number being encoded as stable ID -- can use shorter numbers.

Ari: would suggest we take a stab at this at the hackathon. How ID files etc are done and used.

## Semantic Proxy with OneDM: hacking plan (MJK)

ODM meta model is rather stable now.

Idea of interfaces interesting. Model should be complete without interfaces. All should be able to be described without. But important to have. Virtualizing affordances; for example different protocol binding. Could be used to expose things only partially.

W3C TD and Zigbee clusters aligned with this. Also IoT schema and what designed in smartthings.

Protocol bindings attach to these. W3C TD best example of protocol binding. If can convert SDF to RDF, for which we have format for in iotschema, then we annotate TD. Already node-wot tools that will read W3C TD and consume/expose instances of actual APIs. Node-WoT plumming allows you to do this. Consume one binding and expose another. Might be OCF protocol binding swagger-file style. OMA protocol binding could have LwM2M/IPSO numbers. LwM2M device could be consumed by OCF app or vice versa. Metadata is the same and RDF. That's all the app cares about. Application might be able to consume one protocol already but would do adaptation in the proxy.

Could be different ways organizing this. Could also be device that knows how to expose things with different protocols. Proxy basically just piece of software with different interfaces.

Operationally could be done in different ways. Node-WoT is good way to start. Could be short-cutting many ways, for example skip RDF part. But since all the plumbing exists, useful to use it. Also will have WoT folks joining hackathon activities.

Personal thing that working on: library that can turn RDF to different formats. See as open source tools. Prefer Python for own tools.

Turning SDF into different formats one thing will focus on.

Maping SDF to capabilities. Want TD to have annotations.

SDF OneDM terms would be turned into new terms in iotschema.

Current iotschema is experimental. Not yet accepted by schemaorg. Assumption is that actual models from iotschema would be OneDM models. Moving the process of model convergence back. Imagine that iotschema is mechanical conversion from OneDM.

If temperature sensor gets converged in OneDM, how goes back to OMA? Not the existing model, but a new definition. Everyone will have new models that are based on converged models.

Ari: could be adopted as a set

MJK: already a set of IPSO definitions for presssure, temperature, etc. Those could be adopted as interchangeable industrial models for industry. Could be different from smart home. Could be down-selection what models are adopted. Now with PCHIP will be bunch of devices using models already downselected.

Ari: could have convergence faster in the A/E/P level. For example "current value" is probably needed by all same way

MJK: yes, data types for example. Especially enums. Might be 100 different words for modes of fan but only 5 used; useful to have in one place. People have commented that redundant to have A/E/P and data types. But date types are useful since just raw data. Properties useful since provide read/write semantics. Capabilties useful since give level of composition. All three useful. Like promoting iotschema since can do many things with RDF when have ontology that is aligned.

SDF is kinda broken for enums. What we really want is URIs that map to different things. Issue with boolean: true/false, "true"/"false", 0/1, etc.

Ari: really protocol binding issue; just need to choose one for SDF

MJK: we should have next SDF version after the next meeting. WoT TD gives you schema / on the wire rep. TD is very much protocol binding. TD forms can have much more metadata; one for MQTT and one for CoAP.

Semantic API: in some level can discover these by property names. Adaptatoin the idea. Can read TD with protocol binding and transfer layer knows how to do the reads and write. Knows how to extract items from schema since annoated as ODM data or iotschema. One of open questions is adapation of data types and application level data. How to handle conversion of Celsius to Fahrenheit. Something that outputs ug/m3. Want to write a client that can say how wants to interpret data can obtain it. And can find out what is the shape of the data and meaning of it; units etc. In industrial control have arbitrary values; looking at something like that, where to adapt. IoT introduces additional problem; could be still reporting 40 mA.

Lot of the adaptation needs to be done in the semantic proxy component. Could be a library that is part of the app. Or might be built into the device if have lots of resources. Could do some parts in GW and others in the app.

Encapsulating the questions in this project is what this is about. Can work together to solve the class of problems.

Hopefully some of the implementation available before hackathon. Working on in-memory model and hooking different back-ends.

(running out of time)

Ari: Let's work agenda items for Friday meeting and hackathon details off-line. Could potentially have one WISHI call early during the week of hackathon.

## Planning for OneDM joint activities