Solid for IoT data publication

[FlorSanders]

Hi all

For an internship I’m currently working on a PoC implementation to use Solid as a publication platform for IoT data.
The idea is to have a Solid pod as a data storage and sharing platform for the data by consumer IoT devices (e.g. weather stations, air quality sensors, activity trackers, power consumption, etc.).
This data could then be shared by its owner with third parties like research groups, companies, cities, etc for use in applications or research (s)he believes in.
My belief is that this could possibly simplify the process to setup a citizen science or voluntary data-driven research experiment while offering maximal transparency of the data the user is sharing.

Up to this moment I’ve succeeded in saving sensor measurements (translated from SenML to either SAREF or SSN through an RML mapper).
There are however a couple challenges I’m currently thinking about and hoped I could draw inspiration from this community.

1. The SenML messages contain quite little metadata. The sensor isn’t required to present itself before publishing messages and at most sends the unit of measurement along with the measured value.
   I believe for the data to be more useful, it should be possible for the user to add some metadata (sensor description, what’s being measured, sensor location) at the moment of sharing.
2. Once the IoT data is stored on the pod, some mechanism must be in place for the third parties to fetch the data and pull it into the data processing application of their choice. But how do they know what resources on which pods are publicly available to them?
3. Since multiple ontologies exist for describing measurment data and only very few data processors support linked data yet, I suppose ideally the data ‘aggregator’ tool should have the means of retranslating it and exposing it in more classic formats.
4. If I understand correctly, access control on Solid pods is on a file-based level. So it currently isn’t possible to give access only to certain resources in one ttl file. If only the data for a single sensor is to be shared then, each sensor would need a corresponding file to store its measurements in.

This is the solution I could come up with for points 1-3:
Build a REST API which collects and combines the data from the resources it has access to and re-exposes it in JSON format through means of GET requests, in essence hiding the distributed working and rdf format of the data. This to make the process of getting the data less cumbersome for the people wanting to work with it.
To add metadata (sensor description, location,…) a simple web interface could be built to edit the resources and through which access could be allowed to the data aggregator to read its contents. A POST request could be sent to the API to add the resource to the list of resources the aggregator has access to.
While I think this would technically work, something tells me this isn’t the best way to go, hence this post.

Any feedback, questions, remarks, other solutions and resources you believe might help me are more than welcome. Please do keep in mind I’m still a student and this project (which I’m working out in the time span of a couple weeks) is more than anything a learning opportunity for me.

Best regards,
Flor

[Smag0]

Hi @FlorSanders , big project.
First I think you should try to as more generalistic as possible, and define your classes Temperature, Condition, Mesure, Accuracy, Location, TypeOfCatptor, Brand… then you could split classes as general folders on a Pod and linking your data to instances of these classes. Just an idea of how I would do that but perhaps is not the best… Let us know of your progresse

[FlorSanders]

Hey @Smag0, thanks for the reply.
I don’t think I completely understand what you mean by ‘define your classes’.
My interpretation of what you’re saying is the following (feel free to correct me as I might be dead wrong):

• Define a kind of data model for what properties/classes I want to represent my sensor.
  (e.g. A sensor has a location, measured quantity, description, accuracy, brand, unique identifier (e.g. mac address), etc.)
• Create instances of this data model for each sensor in separate files on my pod, and use that URI as a subject when adding my measurements.

So a sensor entry could look like this:

@prefix sos: <http://www.w3.org/ns/sosa/>.
@prefix om: <http://www.ontology-of-units-of-measure.org/resource/om-2/>.
@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos>.

<https://mypod.example.org/private/iot/sensors/sensor_id>
    a sos:Sensor;
    sos:observes om:RelativeHumidity.
    a geo:Point;
    geo:lat_lon '51.470,-2.5946'. 

And then add measurements which are sos:measuredBy <https://mypod.example.org/private/iot/sensors/sensor_id>.
This, in any case, is what I was thinking of doing but if so, I seem to need to find the ontologies necessary for the properties/classes I want to add. (E.g. above I used wgs84_pos additional to sosa since sosa doesn’t offer a way to add sensor location).

[happybeing]

At the risk of sending you down a rabbit hole, you might find something useful in RDF data cubes, but possibly more relevant is the IoT-Lite ontology. Good luck!

[FlorSanders]

Thanks for the links @happybeing.
I’d already come across the IoT-Lite ontology and it seemed really applicable since it is an instantiation of the SSN ontology I’m using already. Until I saw that it’s based on the 2005 version when it was still in incubation and that the structure has changed quite significantly in the meantime. So I don’t know how relevant it still is.

I’ll definitely check out RDF data cubes, even if only because it seems like an interesting read.

[Smag0]

I don’t think you focus/block on only one ontology. LinkedData is a combination of ontologies

[tanmay]

Hi @FlorSanders, this looks like quite an interesting idea. I am very much interested in learning about its current stage.

[jeffz]

Your choice of ontologies is quite critical as you want the data you generate to be maximally usable. I suggest you start by looking at the ISO 37120 Global Cities Indicators which pairs ontology terms with indicators for measuring liveability of cities including many kinds of measurements such as air quality and at the Ontology of units of Measure which has the pleasing prefix “OM” :-).

[jeffz]

Also pinging @pinfold because your project relates to his project with smart cities.