GeertThijs
commented
8 months ago Hierover dit:
- In de WG is alvast geargumenteerd dat het verkeerd zou zijn om geobserveerdKenmerk naar een Agens te laten verwijzen zie bijgevoegde nota. Je kan bvb niet zeggen dat je de Ammoniak van iets observeert. waarbij Ammoniak dan een instantie is van de klasse ChemischeStof), een ding kan geen kenmerk zijn.
- Wat je wel kan zeggen is dat je bvb de concentratie van Ammoniak in iets (Rivier, Watermonster etc) observeert, Het geobserveerdKenmerk is dan bvb Concentratie of Vracht. Maar het klopt dat je dan nog ergens moet kunnen zeggen " Concentratie van wat"? Een verdere specificatie van Kenmerktype met een attribuut "agens" is inderdaad een mogelijkheid.
- Deze oplossing is geëxpoloreerd door de WG (zie bijgevoegde nota) maar werd niet behouden. In verkeersmetingen hebben we dat echter wel gedaan: daar werd een subklasse Verkeerskenmerk van Kenmerktype gemaakt met een attribuut type voor het Verkeerskenmerk zelf (bv gemiddeldeSnelheid) en bijkomend voertuigType.
- Een subklasse Waterkwaliteitkenmerk met attribuut type en bijkomend attribuut agens zou daar analoog aan zijn. de WG vond dit echter wat te geëlaboreerd en beschouwde agens eerder als een kenmerk van de Observatie, vandaar de attributen ChemischAgensConcentratieObservatie.agens en ChemischAgensVrachtObservatie.agens. Met eigen uri's elk.
- Een globale property agens met range Agens (maar dus zonder domain) gaat nog een stap verder en zou betekenen dat je agens als kenmerk kunt opvoeren van om het even wat, bvb de agens van een Waterobject. Of de Agens van een Observatie, of uiteindelijk ook de agens van een Kenmerktype.
- Het huidig model zou inderdaad zelfs niet aangepast moeten worden. Het globale attribuut agens is dan een term in het VOC en in het AP hebben we ervoor gekozen om het als attribuut van ChemischAgensConcentratieObservatie en ChemischAgensVrachtObservatie op te voeren.
- Probleem lijkt echter te zijn dat de toolchain geen domeinloze termen kan creëren. Een workaround daarvoor is rdfs:Resource opgeven als domein via een domein-tag. De tags "domain" en "range" zouden in de nieuwe versie van de toolchain echter niet meer ondersteund worden. TODO: te checken.
- Alternatief is de rdf handmatig aanpassen door het domein van het attribuut te veranderen. Dit schept echter een probleem van onderhoudbaarheid. Bij een volgende run van de specificatie van het VOC (bvb bij een editoriale wijziging of een volgende versie van de standaard) wordt het domein weer overschreven.
- Momenteel worden VOC en AP ook vanuit hetzelfde EAP-bestand gegenereerd. Als we het model onaangepast zouden willen laten wordt eenzelfde attribuut agens gedefinieerd in zowel ChemischAgensConcentratieObservatie als ChemischAgensVrachtObservatie. Workaround: apart EAP voor het VOC? TODO: te checken.
Er valt dus wel nog wat uit te zoeken om dit te realiseren en vraag is of hier het sop de kool wel waard is?
Kan je https://data.vlaanderen.be/ns/waterkwaliteit#ChemischAgensConcentratieObservatie.agens hernoemen naar https://data.vlaanderen.be/ns/waterkwaliteit#agens en de domaindefinitie verwijderen aub?
We willen die property hergebruiken in de context van een sosa:ObservableProperty