property SF_SpatialSamplingFeature.shape verwacht een subclass van GM_Object als range

[gezever]

Er is een is een locn:Geometry als range gedefinieerd. Op zich vind ik een locn:Geometry goed. Als value van locn:geometry kan je gewoon een wkt meegeven. Kan eender welke locn:Geometry ook een http://def.isotc211.org/iso19107/2003/GeometryRoot#GM_Object zijn?

[GeertThijs]

Hierover dit:

• SF_SpatialSamplingFeature.shape verwacht volgens de rdf specificatie inderdaad een iso:GM_Object.
• We overschrijven deze range echter in de SHACL door een semantisch equivalent maar meer praktisch datatype locn:Geometry.
• In de usagenote van locn:Geometry wordt gesuggereerd om deze te substitueren door Literals bvb vh type geosparql:gmlLiteral OF door subklassen van geometrische primitieven zoals Punt, Curve, Vlak etc. OF door klassen als schema:GeoCoordinates met aparte lat long attributen in WGS84.
• De literals optie hebben we in OSLO Generiek gerealiseerd door toevoeging van attributen geosparql:asGML en geosparql:asWKT omdat substitutie wat te vrijblijvend zou zijn.
• Qua RDF is dit niet helemaal correct, domain van iets als geosparql:asGML is immers geosparql:Geometry en niet locn:Geometry. Om dit op te lossen zou locn:Geometry equivalent moeten gesteld worden aan geosparql:Geometry (hoewel het een breder is dan het ander), maar dat kunnen we zelf niet.
• Verder voorzien we enkele specialisaties van locn:Geometry, nl subklassen van sf:Geometry dat op zijn beurt een subklasse is van geosparql:Geometry, oa sf:Point, sf:Linestring en sf:Polygon. Bedoeling is om niet locn:Geometry te gebruiken maar een van deze subklassen. Is ook zo bij iso: iso:GM_Object is daar zelfs abstract.
• Sf staat voor SimpleFeatures en is een vereenvoudiging van wat onder GM_Object aan subklassen valt. Betekent dat voor elke subklasse van sf:Geometry wel een equivalente subklasse van iso:GM_Object te vinden is.
• Wel is het belangrijk om bij de interpretatie van OSLO Generiek te blijven, want waar locn:Geometry voor staat is ruimer dan iso:GM_Object.
• Voor meer info over Geometrie in OSLO Generiek en meer info over GM_Object, locn:Geometry, sf:Geometry etc zie onze nota Generiek-geometrie.pdf (uit 2017 maar momenteel nog steeds toegepast).

[gezever]

@GeertThijs 'We overschrijven deze range echter in de SHACL door een semantisch equivalent maar meer praktisch datatype locn:Geometry.' Dat begrijp ik niet. Op welke manier gebeurt zoiets in shacl?

[GeertThijs]

Het is te zeggen: we pasten dit aan in het UML-diagram (samen met nog een aantal andere gevallen, zie modelleerrapport). Zo komt het automatisch in de SHACL terecht (die weliswaar slechts een template vd uiteindelijke SHACL is, niet normatief dus). De range van SF_SpatialSamplingFeature.shape aanpassen in de door ISO aangemaakte RDF is niet mogelijk uiteraard.

[gezever]

Dit is toch niet ernstig. Ik denk dat het geen zin heeft om nog issues aan te maken op die manier.

[GeertThijs]

Dit is toch niet ernstig. Ik denk dat het geen zin heeft om nog issues aan te maken op die manier.

Wat is hier precies niet ernstig aan? Je zegt zelf dat je locn:Geometry goed vindt, is inderdaad equivalent aan iso:GM_Object. Maar de RDF van ISO aanpassen zoddat iso:GM_Object ipv locn:Geometry wordt gebruikt kan helaas niet. Maar we hebben ervoor gezorgd dat in de SHACL die door de Toolchain wordt aangemaakt wel locn:Geometry als datatype als datatype staat.

[GeertThijs]

Dit is toch niet ernstig. Ik denk dat het geen zin heeft om nog issues aan te maken op die manier.

En persoonlijk vind ik passief aggressief taalgebruik zoals "dit is toch niet ernstig" en "het heeft geen zin om issues aan te maken" ook weinig ernstig en zinvol. Het doet het OSLO-project onrecht aan en is beneden het niveau van dit kanaal. Ik denk dat ik steeds een weloverwogen en uitgebreid antwoord geeft, ik verwacht van wie de issue indient of eraan bijdraagt hetzelfde.

[gezever]

Het zijn de oplossingen die je voorstelt, die beneden alle peil zijn. Inconsitenties tussen vocabularia en applicatieprofielen, die bewust als oplossing worden voorgesteld, zijn beneden het peil van onze organisatie. Degene die daar terecht bedenkingen bij heeft, doen geloven dat het probleem bij hem ligt, noemen ze gaslighting.

[GeertThijs]

Je hebt wel gelijk dat de huidige oplossing niet ideaal bleek te zijn:

• We gingen er eerst bij OSLO van uit dat inconsistenties tussen SHACL en RDF zoals hierboven beschreven voor doorsnee gebruik geen probleem zouden vormen. Dit leverde een Observaties & Metingen versie 1 op.
• Voor de technisch meer gesofisticeerde toepassingen zoals die van jou is dit wel problematisch gebleken. Daarom (en ook omwille van ISO uri's die niet dereferenceerbaar zijn) komt er van Observaties en Metingen zo snel mogelijk een versie 2.
• Die zal zich baseren op SSN/SOSA, toch voor de subset van klassen en eigenschappen ervan die ook in Observaties en Metingen 1 voorkomen. En dat zijn ze zeker niet allemaal, voor de rest gaan we zelf uri's moeten minten.
• Verder nog vermelden dat in SSN/SOSA nergens een attribuut definieert dat naar geometrie verwijst. Een klasse met geometrie als ISO:SpatialSamplingFeature (met ISO:Specimen een subklasse van SSN/SOSA:Sample) bestaat er niet.
• Die subklassen zijn echter wel nodig voor andere VOC's en AP's en we gaan er zoals gezegd dus eigen uri's voor moeten minten ter vervanging van de niet dereferenceerbare uri's van de ISO.
• De klasse die we nu voor geometrie gebruiken kunnen we dus in principe blijven gebruiken Dit is Locn:Geometry, een generieke klasse van SEMIC waaraan we attributen toevoegden om de geometrie als wkt of gml te serialiseren.
• Locn:Geometry kan indien gewenst ook gesubstitueerd te worden door Point, Curve, Polygon etc van de SimpleFeatures ontology van OpenGIS of als een geometrietype daar niet voorkomt (bvb Solid) door deze van de gmlowl ontology.