Modelling of monitoring campaign / activity / ?project?

[sgrellet]

As discussed in 2024-04-10 webconf

From various meetings, including the Observation event during OGC Delft Member Meetings, seems clarifying how we could describe/exchange those notion would help many communities.

We could link to the following elements involved in/acquired in a campaign

• Deployment of Sensors
• Sample Collection
• Observation Collection

Maybe not much need to model everything; some other things may already exist to which we could point to.
-> How does the group feel about this ?

We could build on

• INSPIRE:Environmental Monitoring Facility Monitoring Activity/Programme (see image below)
• OGC:STA+

Note : I know about EURIO ontology (https://op.europa.eu/en/web/eu-vocabularies/eurio) but seems to 'stop' at the notion of 'project'

[sgrellet]

other input from Simon Cox from the Observation event in Delft : "https://linked.data.gov.au/def/project which was my attempt to define a generic model for project, as a specialization of a prov:Activity (I don't think it has ever been used"

[dr-shorthair]

The general principle here is that prov:Activity provides a general basis for modeling time-bounded things, at a level above sosa:Execution.
proj:Project is an example of how a specialization of prov:Activity might be done.

[dr-shorthair]

I'm disinclined to try to address the general higher-level activities in the context of the SSN ontology.
I think we should stop at ObservationCollection and ActuationCollection.
The next level is too big of a scope jump.

[dr-shorthair]

Maybe an extension module?

[sgrellet]

@dr-shorthair : +1 on an extension module.

Let's discuss this in the next webconf to see who can contribute to this.

[sgrellet]

The general principle here is that prov:Activity provides a general basis for modeling time-bounded things, at a level above sosa:Execution. proj:Project is an example of how a specialization of prov:Activity might be done.

I recently discovered the EUropean Research Information Ontology https://op.europa.eu/en/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/eurio

=> they also defined a project Class that is (?will be?) used in the EU CORDIS system (https://en.wikipedia.org/wiki/Community_Research_and_Development_Information_Service) that disseminates info on all EU funded Research projects.

However, looking at their prefix, I don't see prov :(

[dr-shorthair]

Indeed. It does not appear to use PROV-O. That's a shame, a missed opportunity.
A very inhomogeneous set of re-used vocabularies.

@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix dg: <https://w3id.org/dingo#> .
@prefix eurio: <http://data.europa.eu/s66#> .
@prefix fabio: <http://purl.org/spar/fabio/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix frapo: <http://purl.org/cerif/frapo/> .
#@prefix oegp: <webode://droz.dia.fi.upm.es/Project+Ontology#> .
@prefix org: <http://www.w3.org/ns/org#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix vann: <http://purl.org/vocab/vann/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

I've briefly tried to find a github or gitlab repo to make this comment, but haven't tracked anything down.

[dr-shorthair]

Here's a minimal extension:

What are the essential properties of an Activity?

[sgrellet]

Thanks @dr-shorthair

Looking at the INSPIRE image above (yellow highlighted parts), I would say

• why : uFoI, ObservedProperties and/or media monitored, purpose
• when -> timePeriod/frequency => already there through PROV
• who -> responsibleParty (those askig for it, those paying)=> prov:Agent
• where : BBOX

[dr-shorthair]

Maybe also

• how: prov:used prov:Plan

[dr-shorthair]

Re: BBOX

In DCAT we recommend using the Dublin Core dct:spatial/dct:Location class, complemented by a new property dcat:bbox.

<abc123> a dcat:Dataset ;
...
dct:spatial [
    a dct:Location ;
    dcat:bbox """POLYGON((
      3.053 47.975 , 7.24  47.975 ,
      7.24  53.504 , 3.053 53.504 ,
      3.053 47.975
    ))"""^^geosparql:asWKT ;
  ] .

see https://www.w3.org/TR/vocab-dcat-2/#ex-spatial-coverage-bbox
We could do that, but it does create a dependency on dct:, dcat: and geosparql:.

DCAT also mentioned dcat:centroid and locn:geometry - see https://www.w3.org/TR/vocab-dcat-2/#Class:Location .

[KathiSchleidt]

Looking back at the INSPIRE EF model, in addition to the when, where, who and why listed by @sgrellet above, there's the link to the INSPIRE EnvironmentalMonitoringFacility, equivalent to SOSA:Platform, OMS:Host

It's often useful to be able to express what activities such facilities are engaged in

[sgrellet]

It's often useful to be able to express what activities such facilities are engaged in

Well spotted @KathiSchleidt
Especially given that some use cases (ex : many/most EU environmental reportings) do ask for the campaign/activvity along with the station (SOSA:Platform, OMS:Host) and the station network (domain network not IT notion of network) but NOT the Observations / ObservationCollections

[KathiSchleidt]

Does the location need to be a bbox? Could also be a polygon, e.g. study area.

What do we use to provide location to the basic SOSA classes (I know I should know this!), I don't quite understand why we use DCAT here, not elsewhere

[dr-shorthair]

What do we use to provide location to the basic SOSA classes (I know I should know this!), I don't quite understand why we use DCAT here, not elsewhere

We mention location in https://w3c.github.io/sdw-sosa-ssn/ssn/#location
Following the original idea from O&M, there may be locations associated with the Feature-of-Interest, the Sensor (or Platform), etc.
But as noted these use domain models, so prescribing the way to express location is out of scope for SSN/SOSA.

BTW - I was not proposing that we use DCAT, just showing how they did it.
I noted the risk of introducing too many dependencies.

[KathiSchleidt]

This why we haven't specified the geometry type in OMS.

• In the conceptual model, there is no location information foreseen, just the assumption that the feature defined as FoI is a feature in accordance with 19103, thus has some sort of geometry
• In the OMS basic model where we provide concrete classes one could directly implement, Observer (SOSA:Sensor), Host (SOSA:Platform) and the generic feature set up as an FoI have a location attribute of type Geometry

Thus, geometry is open to whatever the UC requires, point, line, polygon, solid, bbox...
Is there some such high level geometry entry in the semantic world?

[sgrellet]

I noted the risk of introducing too many dependencies.

+1 on this, we need dependancy on PROV for campaign. But, indeed, for the geom better just advise the same way DCAT group did

[dr-shorthair]

Is there some such high level geometry entry in the semantic world?

GeoSPARQL is the best option. Particularly as now it also allows GeoJSON literals as well as WKT, GML, KML and DGGS - see https://docs.ogc.org/is/22-047r1/22-047r1.html#_geometry_serializations_2

The basic pattern is

<my_feature> geo:hasGeometry [
        geo:asWKT """<http://www.opengis.net/def/crs/EPSG/0/4326>
            POLYGON ((
                153.3610112 -27.0621757,
                153.3658177 -27.1990606,
                153.421436 -27.3406573,
                153.4269292 -27.3607835,
                153.4434087 -27.3315078,
                153.4183848 -27.2913403,
                153.4189391 -27.2039578,
                153.4673476 -27.0267166,
                153.3610112 -27.0621757
            ))"""^^geo:wktLiteral ;
] ;
.

or

<my_feature> geo:hasGeometry [
        geo:asGeoJSON """{
                "type": "Polygon",
                "coordinates": [[
                    [153.3610112, -27.0621757],
                    [153.3658177, -27.1990606],
                    [153.421436, -27.3406573],
                    [153.4269292, -27.3607835],
                    [153.4434087, -27.3315078],
                    [153.4183848, -27.2913403],
                    [153.4189391, -27.2039578],
                    [153.4673476, -27.0267166],
                    [153.3610112, -27.0621757]
                ]]
            }"""^^geo:geoJSONLiteral ;
] ;
.

etc.

[dr-shorthair]

However, GeoSPARQL geo:hasGeometry focuses on coordinate-based location (or, in the case of DGGS, a system that has an algorithmic conversion to coordinates). It does not support place-names, administrative units, etc. which might be used to describe the footprint of a project or campaign. dct:spatial/dct:Location is more general.

[oldskeptic]

How about SpatialObject? I superclasses Feature and Geometry. It also avoids the underspecified nature of "Location".

[dr-shorthair]

How about SpatialObject? I superclasses Feature and Geometry. It also avoids the underspecified nature of "Location".

Yes, but while we have geo:hasGeometry to link from anything to a geo:Geometry, there is no GeoSPARQL predicate to generically link to a geo:SpatialObject, which I think is what we are looking for here.

@nicholascar amirite?

[ldesousa]

How about SpatialObject? I superclasses Feature and Geometry. It also avoids the underspecified nature of "Location".

Yes, but while we have geo:hasGeometry to link from anything to a geo:Geometry, there is no GeoSPARQL predicate to generically link to a geo:SpatialObject, which I think is what we are looking for here.

@nicholascar amirite?

In my view SOSA should at most include that predicate. But in general I would prefer no normative elements in this regard, leaving the user free to encode location as convenient. Some examples (like the ones above) would be useful as guidance.

[dr-shorthair]

SOSA should at most include that predicate

Which one?

• geo:hasGeometry
• sosa-act:hasLocation (i.e. a new predicate whose range is not prescribed)

Note that in Common Modeling Questions we showed an example of a sosa:Sample with geo:hasGeometry, but this is just a 'recommendation' not a 'requirement`.

[ldesousa]

Which one?

That would be sosa:hasLocation with an open range including geo:SpatialObject. I stress again the at most bit.

[ldesousa]

I gave a bit more thought to this. The old Basic Geo Vocab includes an object property named location that would serve this purpose. However, this ontology was never approved by the W3C as a recommendation or other.

GeoSPARQL does not include a similar, generic predicate. This could be understood as a loophole, however with the geo:SpatialObject class it is not really necessary. Anything that has a location or an area can be a direct instance of that class, or of one of its sub-classes. I believe this is what @oldskeptic alluded to above.

For now I think this question around location to be outside the scope of SOSA, if there is anything missing that would be on the side of GeoSPARQL.

[dr-shorthair]

I think we are broadly agreed that this is of interest, but not as part of the Core SSN ontology (i.e. terms in the SOSA namespace).

Perhaps should add a note somewhere around the Collections section noting that higher-level collections may exist, but are not modeled as part of SSN/SOSA.

[dr-shorthair]

Telecon discussion:

Perhaps add this into the work on #251
e.g. A more generic collection class could satisfy many of the requirements - i.e. collections of platforms, deployments, systems.

[sgrellet]

+1 on this

This would cover a good part of the issue. We'll need to cover what is 'semantically' a campaign / environmental monitoring activity.

IMHO with both we would have a 1st usable coverage of that issue

[dr-shorthair]

I've added a stub for 'higher level collections' in the introduction to Collections - see draft https://raw.githack.com/w3c/sdw-sosa-ssn/251-collections-documentation/ssn/index.html#Collections-extensions

Currently I say that these other collections are out-of-scope for SSN, but there are existing patterns in SSN and PROV (and Project) that might be used.
If you want to do something more concrete, then I suggest that sit in a separate SSN extension document.

[dr-shorthair]

Mind you, placed in the Collections section of the Specification chapter, this material is a bit hidden. I wonder if there is a better location within the document?

[sgrellet]

Agreed, it reminds me of a situation in OGC GroundWaterML2.0 regarding Aquifer Test.
All was actually already available from O&M, we came up with a pattern to recommand. Question was : how to put forward the existence of the pattern so that it's not hidden in the spec ?

We came up with some kind of signature class : https://docs.ogc.org/is/19-013/19-013.html#toc49 (GW_AquiferTest). To guide the reader to it and apply the pattern.

Would that help ?