Meeting Minutes === :::spoiler Document Usage This document is used for all minutes of the WoT CG. After the meeting, the contents will be copied to the GitHub with a PR. === ###### tags: `Meetup` :::spoiler Document Usage This document is used for all minutes of the WoT CG. After the meeting, the contents will be copied to GitHub with a PR. For one week, changes can be requested and then the PR will be merged. After the PR is merged, the content here can be deleted. Document Access: - Everyone has read and commenting access - Cristiano Aguzzi and Ege Korkan can edit the document - Other people can request write access for a meeting - The scribe of the meeting will have write access <!-- Do not change this spoiler container when writing an instance document --> <!-- See https://github.com/ikatyang/emoji-cheat-sheet for list of emojis --> ::: :::info :date: **Date:** 14 February 2024 ### :bust_in_silhouette: Participants <!-- This list will copied over from the meeting tool --> - Ege Korkan - Cristiano Aguzzi - ### :scroll: Agenda - News from the CG - Introduction of the Speaker - Presentation - Q&A - Discussion :writing_hand: **Scribe:** Cris :computer: https://docs.google.com/presentation/d/1qUbYJ6OEp_SSnnXiSUqQJjdpONAfnGh6wE9NhfYsLDY/edit?usp=sharing ::: ### Introduction Ege: Welcome 17th meetup, it is nice to see a lot of people in the room Ege: as usual you can find us in different online places. You can follow us in different social platforms. Ege: minutes are public ### News Ege: next week we are going to host another meetup with the university of Bologna. If you want to present something next you can talk with us. Ege: please join the community group. #### Speaker Introduction Ege: Today we have Micahel Freund part of the Data Spaces and IoT group at Fraunhofer ISS. He also has a solid pod (link pending) ### Presentation Michael: Today I'll talk about how we integrated WoT with solid and its benifits. First we give a background introduction about WoT and Solid. Later we explain our solution to bridge the two world and finally I will describe our pratical usecase at the Munich Airport. Michael: WoT is technology to describe any kind of API for IoT decives. You can use properties, actions, events model to develop complex applications. > Michael shows a Thing Description example Michael: Next up we have Solid. Solid is a set of specifications that enable a secure, decentralized, acces-controlled Web dta storage. Solid decauples data and applications. Michael: I can define also Access Control List on resources. Michael: but how can we combine WoT and Solid? the goal was to store IoT data for a long period and enable fine access control to particpants (or applications) interested in this data. Michael: we used limted devices the challege was to offload data from those sensors to other part of the system. > Michael shows the system architecture Michael: at the bottom we have Things (constraint devices described by a Thing Description) Michael: Then we have an Orchestrator at the edge which acts as a bridge between Things and the Solid server. Michael: Solid server is basically our cloud space which stores stati and dynamci device data in RDF. Michael: Users access data thanks to the Solid API, but also run commands. The orchestrator fetch the tasks in the Solid server and exec the actions on things. Michael: with this solution we were able to long-term store IoT data and have fine grained access to Things. Michael: There were two type of applications latency-sensiteve (they need short feedback loop) and Data Intensive applications (need long term data for analysys). Michael: the logical solution was to deploy latency-sensiteve application on the edge with consistent API access at the edge and the cloud Michael: we also introduce the concept of Mediator which helped to create an uniform API with RDF as data format. Michael: Edge orchestrator discover all the things and create an API using Thing hierarchy (guided by sosa:host and sosa:isHostedBy annotations) > Showing an example of a composite Thing and API generation Michael: But now how we map different protocols to HTTP? not all applications can support all protocols. An example is BLE. Therefore, we did a protocol mapping based on WoT abstraction. We were able to succefully map BLE to HTTP protocol. Michael: Then we mapped different data format to RDF thanks to RDF Mapping Language (program called FlexRML - in house developed for constraint envs). Now we have data in RDF, protocol mapped in HTTP and a generic API across IoT spectrum Michael: In our prototype we wanted to take pictures of luggage and extract features from Munich Airport. We installed 3 RGB:D cameras with a camera controller plus a phtoeletric sensors. On the edge we have a Edge PC with the orchestrator + 2 mediators. In the cloud we installed the community Solid Sever. > Showing deployment architecture Michael: in the cloud an application is capable to extract the luggage size and color wheras another one is identify the luggege type. > Shows picture of the prototype Michael: we stored RDF data in the solid server. Michael: We are at the conclusion of our presentation, we demostrated that we were able to store IoT data in long-term and we have the same api structure from the edge to the cloud. ### Q&A Pat: Do you have link to that Uniform API (I assume it's on GitHub somewhere)? Michael: yes I have a [link](https://github.com/FreuMi/uriGeneration) C: Could the application you presented be built completely in cloud? Michael: for this control loop it could be implemented only in the cloud (the latency should not be that much). We wanted to start from this but we are going to add other applications. Davi: Solid give you the ability to have user informatio togheter with application data. Have you thought to combine those to improve the User expirience? Michael: great idea, we didn't explore this yet. It would a great idea to include the passenger to this process. Davi: who owns the pod that caputre the data? Michael: it is only internal. It would be nice to use the full power of solid and use multiple pods Biagio: Can't we store the data in a pod that is specifically from one particular passenger. Michael: that's another great idea. If we had the opportunity to interact with the airline componies we could extend the expirement and have user data involved. Biagio: what is the best architecture? a pod for each passanger or a pod for each iot device? Michael: from a privicy prospective the data should be at the passenger pod, but the airport would need control over the data. Biagio: how to integrate new IoT devices? Michael: We can basically support all the protocols that web of things support. If we want to support new protocols we need binding templates. Fred: How do you manage each separate piece of luggage as a subject and handle retrieval once there are many thousands of them in the pod? Also, in the data, how do you connect the data to the particular piece of luggage? Also, are you going to connect the passenger to the luggage? Michael: we have two sistems: cameras and bar code scanner. We positions them at the same position and with a timestamp we tried to match the images with the barcode. Thanks to that we tried to create a 1-1 mapping. Plus we have two LDP containers with a metadata file which contains the description in RDF. There was no limitation (no performance issue). We have many images, but the resolution of the camera is very low. We used graphDB. Joel: we have many buildings in our campus that generates a lot of points. We struggled a little bit to map identifiers of digital assets with physical properties. It seems that you have a way to map ids to quad. Your system need to have the full hierarchical path for a leaf call, but is there a service that is capable to give me a property that is inside the whole subtree. Michael: I am not really sure. Joel: if you want to have help on mapping Thing descriptions to particular protocols I have expierience in that field. Michael: We built a dashbord on top of the graph with grafana. Joel: we used oxygraph and redis for cache storage. Davi: Can you tell us more about the service and the scale that you expect Michael: we are limited to terminal 1. We have 4 checking modules with 8 checking counter each. The plan is to deploy our solution in all checking counter. 32 in total but we want to add also a picture at the end of the process. We then we can try to find lost lagguage thanks to the information stored in our graph. But in the end we are going to process a lot of images per days. We can also think about users trying to describe its lugagge and using the database we can try to indentify it. Davi: it seems that a lot of coumpute power is going to be needed, where is going to be hosted? Michael: in the cloud probably. Ege: I noticed that you are using a sic device, they are working with WoT. Are you in contact with them? Michael: I know but we are not currently using wot ready devices. The devices are old, in the future we might use new devices with wot already embedded. Andreas: we have some painful expirience with identifiers, we tried to tackled it by not embedding dynamic parts in the URLs. Ege: can you show an example of a group of thigs? Michael: we have camera controller > cam 1 . Cris: Have you used the fine grained access control? Michael: not now, but in the future we can share access information about a paritcular machine only during maintainece. Ege: you have TDs with bluethoot with URI schemes. It seems that you have already a binding template. Michael: yeah a lot of them are using Bluethoot. We like the binding templates idea. Ege: do you have public some where? Michael: in public paper. A collegue of mine worked on that and the raw byte mapping. Ege: RML, we had a lot of discussion about binding differnt media types. Michael: it's an issue that I also encountered. No IoT device will send IoT data, but you actually can with off shelf component. Describing RDF data in TD is going to be challenging. Ege: you mentioned discovery, which mechanisms did you use? Michael: What we do link following, we used a crawler. It checks only if the next link is application/json+td. With that we can discover the whole strucutre. Ege: with bluethoot you can do discovery. Cris: have you considered using Multicast DNS discovery? Michael: we don't need it right now. ## :ballot_box_with_check: Resolutions ## :exclamation: Action Items ## :envelope_with_arrow: Feedbacks - They have a bluetooth binding template -> public in a paper ## Presentation Summary Ege questions do you have bluetooth TDs? so a bluetooth binding? Can you share an example? Do you use discovery? Also is there a northbound td? what is a thing having other things inside? Example? RML for content type bindings? I see SICK sensors, who have also presented their WoT usage some time ago. Are SICK devices WoT-enabled here? Do you store TDs in solid servers as well?