We zijn bezig met het opzetten van een datauitwisselingsformaat (https://www.csdif.info) op basis van SensorThings en SensorML. Het doel is om meetgegevens van allerlei community/citizen science initiatieven beter uitwisselbaar te maken, voorzien van rijke metadata over gebruikte sensoren, methodes, meetopstelling, etc. We hebben deze zomer een eerste ruw voorstel geschreven en zijn nu bezig met een proof-of-concept-implementatie om te kijken waar we tegen aan lopen. In deze post wil ik één van die dingen aan jullie voorleggen, op zoek naar input en praktijkervaring op dit gebied.
Binnen SensorThings/STA (en OGC O&M) bestaat er het concept “ObservedProperty” om aan te geven wat een observatie/meting precies geobserveerd heeft. Binnen STA ziet dat er bijvoorbeeld zo uit:
{
"name":"temperature",
"definition":"http://qudt.org/vocab/quantitykind/Temperature",
"description":"Temperature",
},
Hierbij zou volgens mij de “definition” leidend moeten zijn, de “name” en “description” zij bedoeld voor weergave, maar zouden de betekenis van de ObservedProperty niet moeten veranderen.
Voor die definition kun je diverse URIs gebruiken, het systeem van QUDT quantityKinds leek ons hier het meest compleet en stabiel. Echter, als we deze quantityKinds gebruiken, missen we nog wel informatie en context over wat er gemeten wordt. Twee voorbeelden waar we tegen aan lopen:
- Hierboven wordt aangegeven dat er temperatuur gemeten wordt, maar wat voor temperatuur is dat? Is dat de luchttemperatuur? Watertemperatuur? Bodemtemperatuur? Temperatuur in een opslagtank? Etc.
- We meten ook fijnstof (particulate matter), en gebruiken hiervoor nu
definition="https://qudt.org/vocab/quantitykind/MassDensity", maar het is relevant om aan te geven dat het gaat om deeltjes van een bepaalde maat. De gangbare term daarvoor is bijv PM10 voor deeltjes tot 10μm diameter, maar in QUDT kan ik daar niets voor terugvinden.
Mogelijk dat deze twee voorbeelden niets met elkaar te maken hebben en verschillende oplossingen hebben, maar in de basis gaat het in beide gevallen om kwalificeren wat er precies gemeten is.
We kunnen niet de eerste zijn die hier tegenaan loopt, dus hoe lossen andere mensen en systemen dit op (icm SensorThings of wellicht andere OGC-gerelateerde standaarden die ook uitgaan van een vergelijkbaar datamodel)?
Een aantal oplossingen die we voor ons zouden zien:
- Een andere ontologie dan QUDT zoeken die dit soort kwalificaties expliciet maakt in de gebruikte termen. Dit wordt bijvoorbeeld gedaan in het samenmeten platform van het RIVM, daar gebruiken ze bijvoorbeeld “https://www.eea.europa.eu/help/glossary/eea-glossary/pm10”. Dit is pragmatisch, maar leidt mogelijk wel tot een ratjetoe aan verschillende ontololgieën als je voor alles gaat rondshoppen naar waar iets gedefinieerd is. En het is weinig generiek: Het is gebruikelijk dat er gemeten wordt in bijvoorbeeld PM1, PM2.5, PM4 en PM10, maar er is niets dat me er van weerhoudt om een PM8-sensor te maken en die data te willen bewaren, dus een generiekere oplossing zou wellicht de voorkeur hebben.
- Als variant op de vorige optie zouden we onze eigen ontologie kunnen definieren voor alles, maar dat is veel werk en beperkt uitwisselbaar met bestaande datasets. Eventueel kunnen we dit alleen doen voor termen die we tekort komen.
- Door middel van parameters extra kwalificaties toevoegen aan de URIs, bijvoorbeeld
https://qudt.org/vocab/quantitykind/MassDensity#pm_size=10ofhttps://qudt.org/vocab/quantitykind/MassDensity?pm_size=10. Dit heeft als voordeel dat de kwalificatie op een generieke manier in de URI verwerkt is (en consumenten die gewoon matchen op URI zien verder geen verschil). Echter, dit zou ik alleen willen gebruiken als de ontologie die de basis-uri definieert, ook specificeert wat voor parameters er toegevoegd kunnen worden en wat hun betekenis is. Zijn er ontologieën die dit doen? - Op een andere plek in het datamodel deze kwalificaties toevoegen. Voor het onderscheid tussen bijv “luchttemperatuur” en “watertemperatuur” zou het wellicht zuiver zijn om dat als eigenschap van de “FeatureOfInterest” te modelleren. Echter, in SensorThings is “FeatureOfInterest” gereduceerd tot een (GeoJSON) locatie en is het me niet duidelijk of het gangbaar is daar nog dit soort extra attributen aan toe te voegen. Een andere plek zou kunnen zijn in de (SensorML) beschrijving van het Sensor Object, of wellicht in het “parameters” veld van de Observations (wat bedoeld is als parameters aan de “ombserving procedure” denk ik, dus wellicht niet helemaal de goede plek aangezien alle observations in de datastream dezelfde parameters zullen hebben).
Ik hoor graag jullie ideeën en ervaringen!