T2TRG IETF 103 Chairs: Carsten Bormann, Ari Keränen Note takers: Christer Holmberg, chairs Jabber scribe: Francesca Palombini Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-t2trg-ietf-103-consolidated-slides-00 Intro, RG Status (Chairs) Upcoming meetings: Work meeting on Friday Regular WISHI calls Virtual meetings with OCF Virtual meetings with OMA SpecWorks (pending) IETF #104 (Prague) WISHI hackathon continuation planned Co-locating with academic conferences 2019 (pending) RESTful Design for IoT status FETCH/PATCH method considerations and Caching considerations added. CoRE Apps draft for more details on how to define IoT hypermedia apps in a structured way. Addition of IoT details discussed at IETF #102 (Montreal) Next steps: Experience from building IoT systems with (constrained) RESTful+ methods W3C WoT, OMA SpecWorks, OCF, IoT platforms,....? More outside reviews (e.g., from micro service community) Ready for publication by IETF #105? Report from WISHI and Hackathon (Chairs, various) Since IETF #102 Four web meetings, discussing different things (see slide 12). Notes on Semantics and Engineering principles (upcoming). Will be collected on the wiki — may end up in a draft. Hackathon at #103 4th time; 8 participants (2 remotely). Connecting different eco systems. Improvement of existing applications (TD, RD) Discussions: Semantics to binary data, hypermedia safety for IoT (not protocol safety, but usage safety — is it safe to perform an action, and how is that information provided to machines etc making decisions) Learnings: Semantics is hard(er than you think) Pre-setup and testing for hackathons helps a lot Potential new research topics Padhu Subranami: Similar work on semantic interoperability ongoing in OMA SpecWorks Ari: good to have a look at this together brief iot.schema.org update (Michael Koster) Status SSN Workshop at ICSW2018 Actions, events, properties terms are heavily overloaded. Organization W3C CG Charter Integration with schema.org Developer tools How to apply iot.schema.org definitions to existing device ecosystems and FoI definitions Work on API automation Setting up infrastructure for community to contribute Upcoming teleconferences Guest speakers: Dr. Amelie Gyrard: Semantic WoT -- survey on how semantics are used across industry Bruce Nordman: Device descriptions for energy monitoring Hannes Tschofenig: saying that this is not a new standard. Same as if would put LwM2M in the center and map everything else there. Had a star in the IoTSI report. Everyone is saying they are the big star but not another standard. Creates unfortunate situation, have in CoMI, that we do add another standard that fragments the ecosystem. Ecosystem that focuses on standards based solutions should have more collaboration across SDOs. Enemy is not another standard rather than proprietary solutions. Better if we use what we have and make best out of that. There's long list of data model standards that no one is using. Padhu: Do you see the need to have multiple interoperability mechanisms/definitions, or is it possible to use a single one? Michael Koster: not making monolith, idea is that people from different app domains can bring their own definitions. First time around was serialization and tools. Also semantic categories. We want to find things that are common. Have discovered that all standards do same thing; turn on light, set brightness, etc. Hope to normalize based on semantics. In workshop we had stars, discussed adaptation, normalization, translation. Need to support all of those. Trying to bring things together and have new layer -- not competing on same level of standards. Zach Shelby: going to be controversial. As Internet engineers want to control all bits and pieces. Recently started working with data scientists. All millenials. Math people. Work with Python. Look at data in completely different ways than we do. I see some warning signs on how people have to make use of the data we generate. What tools they use. Use machine learning etc. Eventually what matters it that someone can generate value out of the data. Data scientists don't care of exact semantics. Dump all in big table and they'll figure it out. Useful to have documentation of the semantics, where it comes from, is it trustable. But don't care of every bit of information. Think that big data collection and interpretation are different problems. Michael: asking for in review of semantic categories to have data plane and control plane separate. People who work on data can use just the semantics of data. Have simple hints; not full ontology. Useful to have standard to not worry about interaction model and just deal with data. Zach: good point. Difference between control and data plane. Have been throwing our tools to data scientists, showed SenML and they were impressed how much information we have, units and all. So might not want to put the bar very high. Dave Oran: how about interactions, as opposed to data? Interactions become data Zach: need documents to explain how they relate. There ontologies maybe make sense. But that's more for humans. New thing that has not been taken into account. Big data has been main focus. Don't know the answer, so good thing for the RG. Matthias Kovatsch: don't see any conflict between what Zach said and what Michael presented. Idea here is that you annotate small pieces of information so that they are useful for data users. Not doing full world. Schema.org example where share small pieces of information annotated so that search engines can make sense of that. Closed world assumption: just to identify and know what we agree on and do operations on that information. Carsten: many things you can do with IoT. One thing data gathering. Tools for gathering inconsequential. Different area than what discussed on Saturday. There might be actuations also that have significance, so should not get them wrong. For example, get many calendar invitations by mail. The AI in the mail program can also make appointments from plain text. Useful, but sometimes gets wrong. Still need human in the loop. The direction we need: make easy for developers to use data that may have high consequences. W3C WoT update (Matthias Kovatsch) Status update: WoT mission & deliverables: e.g., architecture, TD, scripting API, security & privacy guidelines TD Overview: Semantic annotations, data schema, hypermedia controls Enables powerful tools such as SPARQL queries Recent changes: features (event parameterization, URI templates), term alignment, new terms W3C WoT Roadmap W3C WoT workshop planned for May, to discuss the future work (new features etc) Features under discussion Meta-interactions URI template abstraction - how far should it go? Shu: How do you add a device identifier to a TD? Matthias: we define ID field and you can put any URN/URL there. Gives you a unique ID usable also in semantic web. Also plannning for model number / serial number kind of construct. Shu: but URL can change? Matthias: here use URNs, names that can not be automatically resolved. Draft from Jari Arkko on device URNs that is the best candidate on how to do that. Only the identifier, not locator. There are mechanisms similar to CoRE RD to resolve. How to discover TD is not defined. Can take most of the solutions from CoRE WG to do discovery of TDs. Shu: hard to build uniform platform for resolving the IDs? Matthias: at Siemens do lots of prossional building systems. Many systems that need to interact. Need consistent view of the system, e.g., for diagnostics queries. But need to figure out what other things are needed. Currently for integrators primarily. WoT has been very helpful. core-apps, CoRAL — take on as RG documents? (Chairs, various) CoRE Apps is a way to describe hypermedia driven applications. Alraedy referenced by RESTful Design draft for guidance on defining hypermedia apps. Planning to adopt as RG document. Working on CoRAL in IRTF and IETF. Have used link format for representing link information, but maybe useful to use CoRAL instead since it has more capabilities. CoRAL - The Constrained RESTful Application Language. Draft by Klaus H. Hypermedia representation format for the hypermedia model descibed in draft-hartke-core-apps Can be also used for composition. When have small amount of information, more efficient to provide information in the file itself rather than a link. CoRAL makes this efficient and clean. Concise form instead of compression (that might be hard for most constrained devices). Content Data and interaction model Compact, binary format: the interchange format. Main deliverable. Lightweight, textual format (easy to read by humants) for discussions and design. But have dangers, like hand-made examples that don't really conform to the structure that would be present in the binary version. URIs in CoRAL are IRIs. In binary format CIRIs: pre-parsed format. Zach Shelby: looking through CoRAL. Was thinking "yet another text format". Why can't use HTML5 links? "Forms" the answer? Why can't use actual text link format that could be used to convert from/to CoRAL. Bigger web world would benefit from a CoRAL-like thing. Carsten: one of the submissions to IoTSI WS had title "Semantic noise hurts". Since textual language is only for examples, is optimized for the purpose. JSON and XML formats had the problem that could not reuse that. Always needed a tool. Some time later RelaxNG was designed: compact syntax was defined. That's the model we often have in mind. And the model that guided this design. Zach: but why we couldn't use existing format? And make it useful rather than inventing a new format only for text representation. Don't have to be pretty. Carsten: link format a way to do that Zach: can't HTML5 links do this? Carsten: HTML5 has lots of other problems. And really presentation language. But good research problem. Can you come up with HTML5 version that can be written on whiteboard? Zach: when working with RFC 6690, lots of effort was spent to work with web guys. Don't see the two worlds as separate. Would be good to have a look did it matter? Matthias: I had big hopes that TD links part could use link-format JSON. And JSON schema and others. Now hear that it's going to be own format. There will be some JSON format that describes this. And we have these forms here. JSON representation will pop up. And need to have translators. Christian Amsüss: Make sure that all that can be expressed in CoRAL can also be expressed in RDF. Could roundtrip to anything that can be captured in RDF, like HTML. Matthias: In TD tried to combine links with JSON-LD. Hard work there. Carsten: Coral->RDF->JSON-LD conversion possible Matthias: JSON-LD underlies lots of expectations, e.g., that it's all triples Carsten: JSON-LD really attempt to smuggle RDF to JSON minded people. Matthias: maybe expect JSON-LD be full represention with triples. Can attach meaning to existing JSON format. Can attach meaning that goes to machine intelligence systems. Have interference compatibility. Carsten: please all read the CoRAL draft, have all the information there. If CoRE WG decides to pick up the work the binary one would be the normative. Also good for the group to understand how CoRAL can be used for RD and pub/sub broker. The RG should look at the wider use of CoRAL. How can be used for new applications and do the translations. Form relations not yet fully defined. Intro to Friday's work meeting (Chairs, various) Agenda (slide 64) Plenary Edge Computing discussion teasers: Problem statement of IoT integrated with edge computing EC an emerging technology in IoT Use cases of EC in IoT video demos Computing at the edge Look at EC from a compute perspective to determine the network needs What would it mean to deploy cloud applications (containers, VMs,...) at the edge. Automated IoT security Enabling network access for IoT devices from the cloud (meeting ended)