Modelling of monitoring campaign / activity / ?project?

sgrellet commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

Maybe an extension module?

sgrellet commented 1 month ago

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

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

sgrellet commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

Here's a minimal extension:

Activities (2)

What are the essential properties of an Activity?

sgrellet commented 1 month ago

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 commented 1 month ago

Maybe also

how: prov:used prov:Plan

dr-shorthair commented 1 month ago

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 commented 1 month ago

Looking back at the INSPIRE EF model, in addition to the when, where, whoand whylisted 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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

dr-shorthair commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

Which one?

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

ldesousa commented 1 month ago

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 commented 1 week ago

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.

w3c / sdw-sosa-ssn

Modelling of monitoring campaign / activity / ?project? #224