WEBVTT 00:00.000 --> 00:12.400 So, hello everyone, my name is Maxime Volovinkel and today I'm going to talk about indoor 00:12.400 --> 00:15.000 environments and indoor positioning systems. 00:15.000 --> 00:20.640 Or more specifically, how I want users to be able to easily discover these environments 00:20.640 --> 00:21.640 and systems. 00:21.640 --> 00:27.480 Now, before I get into details, I'll quickly go and introduce myself, so I'm researcher 00:27.480 --> 00:32.120 at the fan of his dead bristle, which is not super far from here, and my interests 00:32.120 --> 00:37.480 may include indoor positioning systems, linked data, and the interoperability of positioning 00:37.480 --> 00:38.480 systems. 00:38.480 --> 00:44.600 Or more specifically, how I can exchange data between positioning systems in a way that you 00:44.600 --> 00:46.160 don't use too much information. 00:46.160 --> 00:51.080 Now, to help me with this, I created several open source projects and the main one being 00:51.080 --> 00:55.840 open HBS, which is an open source hybrid positioning system framework. 00:55.840 --> 01:00.000 Later to this, I have a Pozontology, which actually describes what a positioning system 01:00.000 --> 01:05.120 should be, what it should look like, and also important for this stock is the Sembeacon 01:05.120 --> 01:10.840 Specification, which is a semantic beacon specification, but I'll explain that in more detail. 01:10.840 --> 01:14.960 Oh, sorry, if I'll explain that in more detail later. 01:14.960 --> 01:19.840 Now with these three projects, I basically want to create a world where indoor environments 01:19.840 --> 01:24.720 and indoor positioning systems are as easily discoverable as their outer counterparts, which 01:24.720 --> 01:27.400 at the moment is not really the case. 01:27.400 --> 01:31.040 So if we take a look at the current state of geospatial data, we see that we have a very 01:31.040 --> 01:37.720 service-centric approach, where we have a lot of services that collect and crowdsource geospatial 01:37.720 --> 01:42.240 data, and you have applications that can easily interface with those services. 01:42.240 --> 01:46.840 Now some services may contain more data or more details than others, but in general, you're 01:46.840 --> 01:51.880 always capable of obtaining some form of data from a particular service. 01:51.880 --> 01:54.840 But the same can not really be said about indoor environments. 01:54.840 --> 02:01.920 There are also services that crowdsource indoor data, but it's more fragmented and not 02:01.920 --> 02:08.400 complete, some data is also private, some data requires very difficult procedures to obtain 02:08.400 --> 02:09.400 the data. 02:09.400 --> 02:14.640 So for an application, it's very difficult to rely on a single service to obtain indoor 02:14.640 --> 02:17.120 information. 02:17.120 --> 02:23.440 And to solve this, well, a similar issue or a similar story can actually also be seen 02:23.440 --> 02:30.120 with positioning systems, because outdoors we mainly rely on global positioning system 02:30.120 --> 02:34.400 or satellite-based positioning systems, but indoors we have a lot of different types of 02:34.400 --> 02:38.000 positioning systems, and there's not really a standardization that tells you hey, look 02:38.000 --> 02:43.240 for this particular building, you should use a particular positioning technique. 02:43.240 --> 02:48.680 For over these indoor positioning systems, often require knowledge about the environment 02:48.680 --> 02:54.440 or the infrastructure in that environment, which, again, goes back to our previous issue 02:54.440 --> 03:00.000 that this information is very fragmented across different services. 03:00.000 --> 03:05.560 What you then often see is for positioning systems that they have a very proprietary application 03:05.560 --> 03:12.800 that's proprietary for particular building, a particular framework, or even just a single 03:12.800 --> 03:17.520 positioning system for a single event conference or meetup. 03:17.520 --> 03:22.440 So what I want to do is I want to be able to discover this data without forcing building 03:22.440 --> 03:30.000 owners to put their information on a particular service or changing their data formats to 03:30.000 --> 03:32.480 another format. 03:32.480 --> 03:37.880 And if we talk about data discovery, we mainly see that we have global and local, this 03:37.880 --> 03:44.000 discovery, global is quite known, it's like a geocoder or geospatial query on a database 03:44.000 --> 03:48.520 where you just input a location, you get information, but with local discovery, I want 03:48.520 --> 03:55.160 to get more approximated based discovery where we can find information when we are actually 03:55.160 --> 03:56.160 at the location. 03:56.160 --> 04:00.760 And in the case of a positioning system or an indoor positioning system that makes sense, 04:00.760 --> 04:05.200 because we need a positioning system when we are at a particular location and at that 04:05.200 --> 04:10.160 point, we might as well also get some information about the environment. 04:10.160 --> 04:16.240 And I call this geospatial-centric data discovery where the actual data is presented by the 04:16.240 --> 04:20.840 very locations rather than using predefined services. 04:20.840 --> 04:22.240 But there are some challenges. 04:22.240 --> 04:27.800 How do we find this data without, again, relying on a centralized server and challenge 04:27.800 --> 04:34.120 to, once we get data, how do we actually understand it and how do we know how to use this 04:34.120 --> 04:36.960 particular data? 04:36.960 --> 04:43.240 Because there are a lot of different formats and specifications to represent indoor data, of 04:43.240 --> 04:44.240 course. 04:44.240 --> 04:51.640 Now my solution is a bit of a two-step solution where basically our buildings will 04:51.640 --> 04:56.240 advertise themselves or proximity-based advertising themselves. 04:56.240 --> 05:01.160 And we can actually ask, hey, look, I want more information about you, can you give 05:01.160 --> 05:02.160 me some information. 05:02.200 --> 05:06.240 And instead of directly giving some information, it will instead give you a source of 05:06.240 --> 05:09.120 information that you can then query. 05:09.120 --> 05:14.520 Now instead of just getting data and not being able to understand it, it will also provide 05:14.520 --> 05:20.440 you with a metaphorical handbook or a manual on how to actually read or understand that 05:20.440 --> 05:22.320 particular data. 05:22.320 --> 05:24.600 And to do this, I have several open source projects. 05:24.600 --> 05:27.720 And the first one I want to mention is OpenHPS. 05:27.720 --> 05:32.320 The OpenHPS is an open source hybrid positioning system framework, created in TypeScript. 05:32.320 --> 05:38.000 And it's very low level in the sense that you can create your own algorithms and change 05:38.000 --> 05:40.200 your algorithms in a pipeline. 05:40.200 --> 05:45.400 It provides you with a data structure to create positioning systems, but it doesn't provide 05:45.400 --> 05:50.400 you any applications or any UI elements or any UI editors to create these positioning systems. 05:50.400 --> 05:53.880 It's really a backbone for a positioning system. 05:53.920 --> 05:58.960 The reason why I want to mention OpenHPS is because one thing we noticed when developing 05:58.960 --> 06:05.520 OpenHPS is that despite all the standardizations, if location data and geospatial 06:05.520 --> 06:10.680 data, there's still the issue of positioning systems and not being able to exchange data 06:10.680 --> 06:14.840 in a way that you don't lose too much information. 06:14.840 --> 06:18.960 And to solve this, we created an ontology called Pozontology. 06:19.040 --> 06:23.360 Now, if you don't know what an ontology is, or if you've scared about ontologies, don't 06:23.360 --> 06:24.360 worry. 06:24.360 --> 06:26.360 I will explain it very briefly in a moment. 06:26.360 --> 06:31.080 But in general, it's a description of what a positioning system should be, what algorithms 06:31.080 --> 06:36.120 and technologies that are included in a positioning system, what the purposes of the positioning 06:36.120 --> 06:41.760 system or what it's actually tracking, and also where it is deployed, the environment or 06:41.760 --> 06:47.040 some other infrastructure that's required for this positioning system. 06:47.040 --> 06:53.160 Now, again, if you don't know what an ontology is, take it as you describe certain data 06:53.160 --> 06:56.120 by using other existing data that's on the web. 06:56.120 --> 07:02.720 So basically, what we do is we create a web of information or a semantic web of information 07:02.720 --> 07:07.000 where individual concepts are described by using other existing concepts. 07:07.000 --> 07:10.880 So if you don't know what an indoor positioning system is, for example, you might know 07:10.880 --> 07:14.800 what a positioning system is, and you also might know what an indoor environment is. 07:14.800 --> 07:18.840 Combined it together, you know that it's an indoor positioning system. 07:18.840 --> 07:24.040 And by doing so, we can actually provide some additional context about something. 07:24.040 --> 07:28.120 Now, this is a very visual representation of how it would look like. 07:28.120 --> 07:30.080 I will not go into full detail here. 07:30.080 --> 07:35.880 But for example, here we would have a subject that has certain position, a velocity and 07:35.880 --> 07:40.400 position, a velocity orientation and position. 07:40.440 --> 07:44.920 It has certain observations created using a particular positioning system, created in 07:44.920 --> 07:50.480 a certain reference frame, but it's a graph representation of what this data would actually 07:50.480 --> 07:51.480 look like. 07:51.480 --> 07:56.400 And now, importantly, we come to the sembeacon specification and surrounding tools. 07:56.400 --> 08:03.000 Now it's built on the notion that indoor positioning systems often make use of beacons, 08:03.000 --> 08:09.320 or in most cases they make use beacons, but these beacons are bit useless without an additional 08:09.320 --> 08:10.320 database. 08:10.320 --> 08:15.440 So, what sembeacon's does, it's advertisers and namespace and instance identify it. 08:15.440 --> 08:20.280 For an application and namespace and instance identify it doesn't give a lot of information. 08:20.280 --> 08:25.120 If you know something about this namespace and instance perfect, but if you don't know anything 08:25.120 --> 08:30.320 about it, then you just know that there is a beacon with a certain namespace, but you 08:30.320 --> 08:31.840 have no information. 08:31.840 --> 08:36.760 So what you can actually ask sembeacon and say, hey, look, I see that you're here, but I 08:36.760 --> 08:37.760 don't know who you are. 08:37.760 --> 08:39.800 Can you give me a bit of information? 08:39.800 --> 08:41.800 And it will respond with a URI. 08:41.800 --> 08:46.840 The simple URI that says, hey, look, this is where you can find more information about 08:46.840 --> 08:47.840 me. 08:47.840 --> 08:53.560 And this URI actually leads them back to this ontology or this linked data representation 08:53.560 --> 08:59.000 or this semantic web of information, where we actually describe the beacon, the environment 08:59.000 --> 09:04.760 to beacon is located in, but also other infrastructure, other devices, other points of interest 09:04.760 --> 09:06.720 that are within this environment. 09:06.720 --> 09:14.400 And we can then use that information to visualize or to discover these in your maps, but 09:14.400 --> 09:20.160 we can also use that to discover other devices and points of interest in that piece. 09:20.160 --> 09:24.400 Now these namespace and instance identify it as not just random numbers that we chosen. 09:24.400 --> 09:28.680 They are actually based on the resources or the URIs that you will access. 09:28.680 --> 09:35.160 So if you see two namespaces or two similar namespaces, you know that you only need to access 09:35.200 --> 09:38.240 the URI of one of them to fetch the information. 09:38.240 --> 09:43.160 And it's also backwards compatible with I beacon and alt beacon, which are common specifications 09:43.160 --> 09:45.840 used for indoor positioning systems. 09:45.840 --> 09:51.320 So you can use a beacon, a send beacon to provide contextual information about I beacon in 09:51.320 --> 09:52.320 your building. 09:52.320 --> 09:56.320 And it's not that you have to replace every existing infrastructure or every existing I beacon 09:56.360 --> 10:04.160 in a building to create or to create a contextual or geospatial centric discovery. 10:04.160 --> 10:09.560 Now, as I've already said, it's a Bluetooth specification, but it's actually a combination 10:09.560 --> 10:14.240 of alt beacon and a destone combines together with some additional flex. 10:14.240 --> 10:19.200 And what you actually have with a beacon is that you can advertise signal, passively, a beacon 10:19.200 --> 10:25.360 can just send signal, hey, I'm this, I'm this, but it can actually also respond to a scanner 10:25.400 --> 10:26.200 request. 10:26.200 --> 10:31.080 And with that response, we can send a different response than our normal advertisements. 10:31.080 --> 10:37.080 And we utilize this to send an additional URL compatible frame that contains this short 10:37.080 --> 10:40.520 resource URI that then resolves to this link data information. 10:40.520 --> 10:44.920 We also have a Bluetooth 5-pointed specification that doesn't use this scanner response. 10:44.920 --> 10:49.600 It's also not backwards compatible, but in this case, we can use, make use of the extended 10:49.600 --> 10:53.400 range to broadcast that information. 10:53.400 --> 10:58.960 And the flex basically provide more contextual information about URI, so that an application 10:58.960 --> 11:02.280 knows what to expect from the online data. 11:02.280 --> 11:07.200 For example, it can indicate if the beacon will contain a position, if it's part of a positioning 11:07.200 --> 11:13.360 system, or if it requires authentication to fetch the information. 11:13.360 --> 11:18.720 We also created the mobile application, and originally it started as a very basic way to 11:18.760 --> 11:23.360 simulate and scan for send beacons and to get some basic contextual information. 11:23.360 --> 11:27.880 But we kept on expanding it a bit more and more so that it can also visualize these 11:27.880 --> 11:32.800 in-nour environments that it can visualize the points of interest in those environments, 11:32.800 --> 11:36.320 the different floors of a building, the floor maps, and so on. 11:36.320 --> 11:41.120 And lately, we also expanded it so that we can link it to a personal data hold, call 11:41.160 --> 11:47.040 it, which is a vault, a personal data vault, where you can store data, binary data, 11:47.040 --> 11:48.720 but also linked data. 11:48.720 --> 11:55.800 And this case, it's cool because you can actually make certain data available for a group 11:55.800 --> 12:01.280 of people, or a particular user or a particular application, and you can provide authentication 12:01.280 --> 12:02.280 to that date. 12:02.280 --> 12:07.240 So the send beacon will still advertise the URI to everyone who is in proximity of the building, 12:07.240 --> 12:12.200 that only a certain type of people or certain people with certain rights will be able 12:12.200 --> 12:14.560 to access the information. 12:14.560 --> 12:19.120 Now, this might look a big scary, this is a very basic example that I will explain it 12:19.120 --> 12:21.960 in a second, or very briefly explain it in a second. 12:21.960 --> 12:29.320 It's a simple RDF representation of what a single floor would look like, where we have 12:29.320 --> 12:35.920 a floor map with schema.org, we have the geosparkle OGC, where we have the well-known text 12:35.920 --> 12:40.240 to represent a certain geometry, but this is just one example. 12:40.240 --> 12:45.720 The idea is that we can use the link data to say, hey, look, instead of writing everything 12:45.720 --> 12:51.000 like this, we just say, hey, look, I have an IMDF file that contains information about 12:51.000 --> 12:54.040 my indoor environments, do with it what you want. 12:54.040 --> 12:58.720 And maybe you can even provide multiple different data formats if they are available, but 12:58.720 --> 13:03.960 what we want to do with this link data representation is just make it clear or make it 13:03.960 --> 13:10.200 interoperable, that applications will be able to see, hey, look, what data is available, 13:10.200 --> 13:15.880 how can I access it, and if it doesn't know how what IMDF is, it can learn more about it 13:15.880 --> 13:22.880 by traversing the web and learning more how to represent or read this particular data. 13:22.880 --> 13:30.840 Now, the roadmap for the post-ontology, at the moment we have an open call for issues, 13:30.840 --> 13:38.520 or open call for examples or use cases, where we want to learn more about what do you want 13:38.520 --> 13:43.360 to, or what do you expect from a positioning system, but you expect from a vocabulary 13:43.360 --> 13:46.560 that can describe these positioning systems. 13:46.560 --> 13:52.880 We recently released a new version of our ontology design, which is also available now and 13:52.880 --> 13:57.160 get up, so if you have any feedback on that, that's also welcome. 13:57.200 --> 14:02.400 For Sembeacon, we have a few tools, so we have of course our mobile application that I 14:02.400 --> 14:09.920 showcased earlier, we have also there an open call for examples or implementations of unsupported 14:09.920 --> 14:15.520 indoor environments, so if you, if the application does not support a certain type of environment 14:15.520 --> 14:19.240 that you think should be supported, then it's definitely welcome. 14:19.240 --> 14:26.280 We are currently only have Android support, but we are partially implementing the iOS support. 14:26.280 --> 14:32.800 We have an Arduino library that can scum for Sembeacon, and that can also make the Arduino 14:32.800 --> 14:38.560 act as a Sembeacon, but at the moment it has no retrieval of the data, so it would be 14:38.560 --> 14:43.360 cool if the embedded device is still capable of obtaining a small subset of information 14:43.360 --> 14:49.600 such as the location or a simple geometry of the environment, because that would be quite 14:49.600 --> 14:50.600 cool. 14:50.600 --> 14:55.240 In a specification itself, it's also available on GitHub, so if you have any feedback there 14:55.280 --> 14:57.760 for improvements, that's also welcome. 14:57.760 --> 15:04.320 Let's do a quick demo, brace yourself, it's life demos, it's always a very tricky thing 15:04.320 --> 15:15.480 to do, but normally everything should go as planned, so this is a, oops, let me quickly 15:15.480 --> 15:19.440 go to my application, so I have two applications running, one to simulate the beacons, 15:19.440 --> 15:23.840 and this is the application that can actually scan, if I'm at the moment, if I would scan, 15:23.920 --> 15:29.360 I will see beacons that are available in this environment, which at the moment does not seem 15:29.360 --> 15:34.840 to be any, but I can start, for example, by advertising a few IBICs, so I will advertise 15:34.840 --> 15:41.280 a few IBICs, you'll see them popping up here on the screen, but contextually, they don't 15:41.280 --> 15:47.280 tell a lot, I can see how far they are, I can click on them, see, okay, yeah, it's 16 centimeters 15:47.320 --> 15:53.960 away, but that's about it, I have no information about it, but what I can do is when I 15:53.960 --> 15:59.160 now enrich or when I now broadcast a send beacon, I can provide information about the 15:59.160 --> 16:04.240 send beacon, but also about other beacons within that same environment, in this case, if I 16:04.240 --> 16:13.680 start the send beacon, then hopefully, then hopefully it will pick up the thing, or maybe 16:13.680 --> 16:21.120 I'm broadcasting a bit too much with one second, let's try this again, okay, welcome to 16:21.120 --> 16:35.440 live demos, okay, with one second, wait, I'm not clear everything, okay, wait, okay, so that's 16:35.440 --> 16:49.600 still going, so in general, the idea would normally be that it should pick up the phone, but at 16:49.600 --> 17:03.280 a moment it's working there, I would say, it's working, it's working, and we'll investigate 17:03.280 --> 17:09.920 the issue, but normally the idea would in that case be that we actually, I will quickly, 17:09.920 --> 17:18.880 still have a second, I will quickly do a very quick emergency up-info clear data that's always 17:20.880 --> 17:28.880 a good thing to do, I was testing it so much and it worked, so that's the issue of, okay, 17:28.960 --> 17:39.840 okay, let's start again, come, come, come, beacons, beacons, beacons, and now it is not working anymore, 17:41.120 --> 17:46.080 okay, well, I will leave it to that, but what you can do is you can download the application, 17:46.080 --> 17:50.480 you can try it yourself, and that way you can also investigate it a bit more in detail, 17:51.280 --> 17:57.120 because as you can see, life demos, you have to brace yourself, because you never know what's going 17:57.120 --> 18:05.520 to happen and where it's going to fail, so yeah, that brings me already a bit to the end of the 18:05.520 --> 18:12.480 presentation, so if you want to learn more about Pozo OpenHPS of Sandbeacon, you have some sites here, 18:12.480 --> 18:19.440 they're also available on the PhosDem sites, the QR code will just go to the slides, so you can also 18:19.520 --> 18:26.960 find it on the PhosDem website, but if you have any questions, let's me know, thank you for your attention. 18:34.400 --> 18:38.720 So are there any questions? Yes? How tightly is it tied to Bluetooth? 18:39.280 --> 18:43.840 Well, could you also run into my files, so the type of routers could announce themselves 18:43.920 --> 18:49.520 epic, it's only a large scale. Well, at the moment, well, the ontology or everything behind the scenes, 18:50.080 --> 18:55.120 that's on the web, so the only thing you need there is that browser doesn't even require these 18:55.120 --> 19:01.680 Sandbeacans, at the moment a specification is only made for Bluetooth, but we can indeed investigate 19:01.680 --> 19:06.320 seeing that the logic behind it is actually on the web, we can actually, of course, 19:06.880 --> 19:12.400 have a way to advertise you arrive via Wi-Fi, and that would also work the same way. 19:12.480 --> 19:17.280 We just have to make sure that it's, again, not something proprietary, that then requires 19:17.280 --> 19:21.280 a specific protocol, because of course, that would defeat the purpose again, of course. 19:22.880 --> 19:28.720 Yes? How does it relate to 5G and the function make sense, that are standardized? 19:30.960 --> 19:38.800 Well, the thing is that this, the DS5G, it will work for the positioning, it will also, in some cases, 19:38.800 --> 19:44.720 work for indoors, but at that point you don't get, you still don't get the environments, 19:44.720 --> 19:51.120 and this environmental data is still necessary or required. Let's imagine that you're at 19:51.120 --> 19:57.200 false them, you have to find this specific room. It's one thing to know, ah, you have this gray 19:57.200 --> 20:03.280 building, and your location is exactly somewhere in this gray building, but it's another thing to 20:03.360 --> 20:09.920 actually see the hallways, to see the rooms, so that you know where to enter, and it's not a door 20:09.920 --> 20:15.040 that was over there, where what I was trying, when getting into this specific room. 20:16.320 --> 20:22.320 So, you still need to wait to discover these environments, and seeing that eye beacon and beacons 20:22.320 --> 20:29.600 are still widely used for indoor environments, it seemed like an appropriate use to also just 20:29.600 --> 20:41.520 provide additional context alongside these vehicles. If a phone has access to access to the air pressure, 20:41.520 --> 20:48.560 yes. So, the same beacon is just the way to advertise, hey, this is available, and it can then 20:48.560 --> 20:54.640 use or describe a positioning system that's used indoors, and that positioning system can say, 20:54.640 --> 21:00.160 hey, look, I require data about Bluetooth beacons, I require data by Wi-Fi access points, and 21:00.160 --> 21:07.760 I require data about pressure if that's available. But that's inside the description of what you 21:07.760 --> 21:16.240 want to represent. This. Yeah, I have a building that I have this 21:16.240 --> 21:24.080 important. No, we tested it at our own building, because we also noticed, for example, 21:24.800 --> 21:31.280 that's for OSM, there's indoor data, for example, at my campus, but there is only one floor, 21:31.280 --> 21:36.080 of one building that has this indoor data, and it happens to be the floor where scientists or 21:36.080 --> 21:45.280 computer scientists are located. So, yeah, that's of course an issue, but what I really want to 21:45.360 --> 21:51.280 to focus on with this is, I don't want to force someone to use OSM or want to force someone to use 21:51.280 --> 21:55.440 a specific service. I just want to say, hey, look, create it, however you want. If you have 21:55.440 --> 22:02.880 cut drawings, be my guest, but I just want to make sure that a building owner can still decide, 22:02.880 --> 22:09.840 hey, look, I want to make this available public in whatever data format that I want, and not in 22:09.840 --> 22:13.440 a specific data format. Yes. 22:13.440 --> 22:17.840 I don't have to know if you have a comparison between the system that you have to read it, 22:17.840 --> 22:23.840 and then you have to have other finishing commercial projects that have tried to solve this 22:23.840 --> 22:28.880 in this position, and advertising won't be in terms of indoor data format. 22:28.880 --> 22:30.640 We have such an comparison. 22:54.160 --> 23:03.680 So, they have some of the voice management shopping modes, and all the data can also be public. 23:03.680 --> 23:11.920 If I would go back a bit to the example of how indoor data is available, what we often see is 23:11.920 --> 23:18.240 data can be available either via services, or often it's a requirement by a city or municipality 23:18.320 --> 23:25.680 to collect in this data. In Belgium, I know it's not super public always to get this information, 23:25.680 --> 23:32.480 but I'm not aware of 100% sure how it isn't China, but it could be that for example, 23:32.480 --> 23:38.240 that data is available for the public, or to those applications that want to use it. 23:39.360 --> 23:46.720 So, I'm not sure in that case, but I assume that it's more of an on a governmental level 23:46.800 --> 23:53.920 that they provide access, but I cannot really 100% be sure about that. 23:56.880 --> 23:57.520 Yes. 23:57.520 --> 24:03.520 What's wondering, if it could be used to track people, or if you have already, 24:04.160 --> 24:07.120 taking measures to maybe interest privacy? 24:07.120 --> 24:12.960 Well, there is what we do have in the mobile application, quickly go there. 24:13.920 --> 24:18.480 So, what we currently have is a deliberate tracking of people. 24:19.520 --> 24:24.240 So, what you can do, if you, for example, connect it to your own solid pods, is that you can 24:24.240 --> 24:30.640 advertise yourself, or your business card, so to say. So, what you can do is you can say, 24:30.640 --> 24:34.960 hey, look, I look into my solid pod, it contains information about you, and you can basically 24:34.960 --> 24:42.640 walk around advertising you as a beacon, as a moving beacon, which then allows others to 24:42.720 --> 24:48.000 easily get your contact information, but this is deliberate way of sharing your information. 24:48.800 --> 24:55.120 Now, of course, it can always be used negatively. Now, in the case of the mobile application, 24:55.120 --> 25:02.240 or the way how I envision it, the mobile application is just a way to scan for static beacons 25:02.960 --> 25:09.280 fixed with a fixed position somewhere in your environment. If it would be used the other way around, 25:09.360 --> 25:13.760 then it's usually for the purpose of tracking. For example, you could put the beacon on a dog, 25:13.760 --> 25:18.000 so that when the dog is lost, that they can get a contextual information and see, 25:18.000 --> 25:25.360 oh, this is the owner's contact information and so on, but that's more for deliberate tracking. 25:26.320 --> 25:31.680 You would actually have to advertise yourself in that case to share that information. 25:31.680 --> 25:39.600 Any other questions, or I think, at the end of the time? So, again, thank you.