Dependency on non-authoritative ontology for samplingFeature

[rob-metalinkage]

http://def.seegrid.csiro.au/isotc211/iso19156/2011/sampling#SF_SamplingCurve

sf:SF_SamplingCurve rdf:type owl:Class .

this should be updated to

http://www.opengis.net/def/samplingFeatureType/OGC-OM/2.0/SF_SamplingCurve

but perhaps this itself should be moved to appschema:

options for samplingFeature:

1. move samplingFeatureType to appschema, load OWL model as well, and implement all the required artefacts for redirects (XSD, XMI, OWL, JSON-LD context) Note that JSON-LD context will be derived automatically from the OWL
2. move samplingFeatureType to appschema - leave as SKOS for now and put placeholders for required appschema resources
3. leave as is and leave as SKOS
4. leave as is, but build OWL model and load using existing
5. Wait for ISO to publish and reference that.

My preference is to kick off for #2 and ask for the SWG to fill in the gaps.

[dr-shorthair]

Note that OM SamplingFeature was renamed to sosa:Sample in the SSN ontology.
And the geometry-based taxonomy is not included in SSN/SOSA.

[sgrellet]

This issue applies to https://github.com/opengeospatial/GeoSciML/blob/master/ontology/minimal/gwml2_minimal.ttl
With @afeliachi we applied the method discussed in ELFIE (https://docs.ogc.org/per/18-097.html#ontology_from_uml).

As such, some aspects need iterative polishing, there may be "dependencies" with other non-autoritative ontologies to be refined but we prefered initiating momentum and avoid pulling a huge chain of ontologies.
-> So I'll exclude option 5

I like the SOSA idea but the SamplingCurve aspect was needed for Borehole/Well related aspects
I think we also discussed using sam-lite at some point.
@afeliachi, what do you think ?

[rob-metalinkage]

Hi - OGC has initiated conversation with ISO - who have a new leader in this space (Nick Car, who I work with in my other job so we have some influence here) and refactoring the ISO offering so we dont have to pull a huge chain is on the table here. We have asked for a position statement from them ASAP ... so there is actually an

option 6:

adopt an ISO namespace now, and have an import container that imports our own local defs of what we need for now, but is modified in future to point to clean ISO sources.