Significant issue comes into consideration together with the idea of Sensor Catalogue. If a lot of sensors from different providers are registered in the catalogue and therefore theirs metadata are accessible from one point. How to make sensor data accessible at the same point? And more complexly, how to access sensor data from different providers that are published using different protocols? It means from the user point of view the problem with different publishing protocols is delegated on the catalogue side. No necessity to have several applications for many of used protocols as the sensor data consumer. An user having an application communicating over one protocol can access wider range of sensors by the catalogue access point. It can be radical benefit on the client side.
But the problem is growing on the server side of the catalogue access point. We are discussing two basic concepts of this solution in the process of the OpenSensorsNetwork pilot. Simple diagrams for each concept can be found below.
Concept 1 – data harvested to main repository
Concept 1 supposes harvesting of data from registered sensors in the catalogue to the main repository administered by the sensor catalogue provider. This concept is straightforward solution – what is registered is available. But this concept places demands on main data repository that is always limited.
Concept 2 – requests and responses transformed between APIs
Concept 2 doesn’t store registered sensor data physically at the access point of the sensor catalogue and thus it eliminates limitation from the data storage capacity. But this concept places demands on complex transformations between used protocols and formats.
If you are interested in questions like these, it will be our pleasure discuss these topics at the upcoming Baltic Hackathon.
