Add association between ObservingProcedure and ObservableProperty

alexrobin commented 1 year ago

This allows linking the observing procedure directly to an observable property without requiring that an implementation of the procedure (i.e. Sensor or Observer) exists.

This is missing in OMS but several early adopters have requested it, so we could add it to SOSA.

dr-shorthair commented 1 year ago

Yes, this is needed for most catalogues of procedures.

sgrellet commented 1 year ago

indeed. then we'll need to be careful on the semantics we'll define for that association (see : https://github.com/w3c/sdw-sosa-ssn/issues/42).

KathiSchleidt commented 1 year ago

related to w3c/sdw-sosa-ssn#44

dr-shorthair commented 1 year ago

Is this the same as #42 ?

dr-shorthair commented 7 months ago

@KathiSchleidt @sgrellet @alexrobin is there a concrete proposal here? See diagrams here for context - https://w3c.github.io/sdw-sosa-ssn/ssn/#Procedures https://w3c.github.io/sdw-sosa-ssn/ssn/#Actuations-overview https://w3c.github.io/sdw-sosa-ssn/ssn/#Observations-overview

hylkevds commented 7 months ago

The association is also part of the STA version 2 data model proposal: https://raw.githubusercontent.com/opengeospatial/sensorthings/23-019_DataModel/figures/Datamodel-SensorThingsApi-V2-proposal-1-OM.drawio.png

dr-shorthair commented 7 months ago

OK - I will make this addition

sgrellet commented 7 months ago

The association is also part of the STA version 2 data model proposal

-> yes but I'm not sure this semantically cover what is in #42

How could we handle both the UseCase below ? not sure only one association suffice

that observingProcedure is used to observe that observableProperty
VS that observingProcedure can be used/is allowed to be used to observe that observableProperty (in some domains you have long list of ISO/CEN validated Procedure)

hylkevds commented 7 months ago

How could we handle both the UseCase below ? not sure only one association suffice

* that observingProcedure is used to observe that observableProperty
* VS that observingProcedure can be used/is allowed to be used to observe that observableProperty (in some domains you have long list of ISO/CEN validated Procedure)

Yes, those are different associations. That's why the proposed STA v2 model has three relations for the observingProcedure:

To Sensor, to indicate the Sensor implements the Procedure
To Datastream, to indicate the Observations in the Datastream [were|will be] made using the Procedure
To ObservedProperty, to indicate the Property can be determined using the Procedure

sgrellet commented 7 months ago

Thanks @hylkevds for confirming my guts feeling. That was my point with 'semantically cover' above

=> We just need to be extra-careful in those properties definitions to enable the reader/implementer understand that

1°/ ObservingProcedure that can be used/are allowed for a given ObservedProperty are handled in the yellow association below
2°/ The specific ObservingProcedure that isused in the context of a given ObservationCollection/Observation is in the red circled one

For 1°/, for now we have almost the same property names; with only the plural making the difference (at least in the STA 2.0 draft schema above). If they carry different semantics shouldn't we differentiate them in a bit more obvious way ?

ex: ObservingProcedures <--> ObservedProperties could be renamed into a/ potentialObservingProcedures <--> ObservableProperties b/ allowedObservingProcedures <--> ObservableProperties

hylkevds commented 7 months ago

At some point the relation names become prose. And they will probably still not perfectly reflect all intended use cases. One important detail is if distinct relations with the same name can have different semantics. In OData this is possible, and thus I personally prefer the shorter name. If this is not allowed or goes against best practice in the semantic world we may need a longer name here.

alexrobin commented 7 months ago

@hylkevds In the SOSA/SSN ontology, I think it's definitely cleaner if these two associations have different names since properties in RDF are just "global" objects defined independently from their parent class, and in this case they share the same namespace.

In STA 2.0, I agree with Hylke that it may be fine to have the same name because the two associations are used in the context of different classes, so with good documentation, I think things can be kept pretty clear.

dr-shorthair commented 7 months ago

We can just use sosa:forProperty and add guarded constraints on sosa:ActuatingProcedure and sosa:ObservingProcedure so that they must point to an individual from the correct subclass.

dr-shorthair commented 7 months ago

See https://raw.githack.com/w3c/sdw-sosa-ssn/47-add-association-between-observingprocedure-and-observableproperty/ssn/index.html#SOSAforProperty https://raw.githack.com/w3c/sdw-sosa-ssn/47-add-association-between-observingprocedure-and-observableproperty/ssn/index.html#SOSAActuatingProcedure https://raw.githack.com/w3c/sdw-sosa-ssn/47-add-association-between-observingprocedure-and-observableproperty/ssn/index.html#SOSAObservingProcedure

dr-shorthair commented 6 months ago

Changed my mind and added new role hasProcedure a852de4 - see preview and key figures Observation Actuation

Observation Actuation

ldesousa commented 6 months ago

Apologies for being late into this, only now I lent some time to this issue. In my perspective a direct association between Property and Procedure is redundant with Observation (actually a many-to-many relation). Often (or almost always) it is necessary to restrict one or more procedures to a property and vice-versa. However, achieving that in an ontological sound way would instead call for a specialisation of the Observation class, not a new association. This has been the approach in ontologies like GloSIS, AIM, OIM, etc. I implemented this approach successfully in a few data models, as in the ISO-28258 database.

This new association between Property and Procedure opens the door to inconsistencies, with forPorperty indicating one property and the Observation class (or instance) indicating another. But let me know if I am wrong.

dr-shorthair commented 6 months ago

@ldesousa Yes, it is redundant when describing an Observation instance (or Actuation instance).

But it is useful when compiling a register of Observation Procedures and Observable Properties (or Actuation Procedures and Actuatable Properties). These properties support recording which property(s) can be observed with which procedure(s), etc.

And yes, there are risks of inconsistencies, but the other way of looking at that is that it provides additional consistency checking.

ldesousa commented 6 months ago

Following the discussion in the last meeting, here is a concrete example. It starts with the basic definition of three soil properties:

soil:sand a sosa:ObservableProperty ;
    rdfs:label "Sand fraction"@en ;
    rdfs:comment "Soil particles in the size range between 0.05 and 2.0 mm."@en .

soil:silt a sosa:ObservableProperty ;
    rdfs:label "Silt fraction"@en ;
    rdfs:comment "Soil particles in the size range between 0.002 and 0.05 mm."@en .

soil:soc a sosa:ObservableProperty ;
    rdfs:label "Soil organic carbon"@en ;
    rdfs:comment "Microbial, plant and animal detritus at various stages of decomposition, from humus to charcoal."@en .

And two laboratory procedures:

soil:drc a sosa:ObservationProcedure ;
    rdfs:label "Dry combustion"@en ;
    rdfs:comment "Complete flash combustion of a soil sample in the presence of oxide catalysts."@en .

soil:pip a sosa:ObservationProcedure ;
    rdfs:label "Pipette"@en ;
    rdfs:comment "Pipetting a known fraction of suspension to an evaporating dish and boiling off the water."@en .

Dry combustion is applied to measure the content of carbon and nitrogen, not texture. A specialisation of Observation can express that distinction/restriction:

soil:SOCObservation a owl:Class ;
    rdfs:label "Soil organic carbon observation" ;
    rdfs:subClassOf sosa:Observation ;
    rdfs:subClassOf [ a owl:Restriction ; owl:onProperty
        sosa:observedProperty ; owl:hasValue soil:soc ] ;
    rdfs:subClassOf [ a owl:Restriction ; owl:onProperty
        sosa:usedProcedure ; owl:hasValue soil:drc ] .

The pipette method applies to the two soil texture properties. In that case the predicates owl:allValuesFrom or owl:someValuesFrom can be applied instead. However, they require a further specialisation of ObservableProperty:

soil:Texture a owl:Class ;
    rdfs:label "Soil texture fraction"@eng ;
    rdfs:subClassOf sosa:ObservableProperty .

soil:sand a soil:Texture ;
    rdfs:label "Sand fraction"@en ;
    rdfs:comment "Soil particles in the size range between 0.05 and 2.0 mm."@en .

soil:silt a soil:Texture ;
    rdfs:label "Silt fraction"@en ;
    rdfs:comment "Soil particles in the size range between 0.002 and 0.05 mm."@en .

soil:TextureObservation a owl:Class ;
    rdfs:label "Soil texture observation" ;
    rdfs:subClassOf sosa:Observation ;
    rdfs:subClassOf [ a owl:Restriction ; owl:onProperty
        sosa:observedProperty ; owl:allValuesFrom soil:Texture ] ;
    rdfs:subClassOf [ a owl:Restriction ; owl:onProperty
        sosa:usedProcedure ; owl:hasValue soil:pip ] .

The complete graph is available from this gist.

Some pros and cons of this approach:

For

Sticks to the same philosophy of SOSA v1.0;
Keeps the ontology lean;
Avoids redundancy (i.e. more than one "path" from Observation to Procedure);
Better aligned with STA (nuanced).

Against

Laborious identification of related Properties/Procedures (relevant when their instances are published in automated registries, e.g. are SKOS concepts).

Adding direct relations between Properties and Procedures implies a relevant change of philosophy when re-using SOSA. Whichever the decision, this aspect begs for some sort of re-use guidelines document.

sgrellet commented 6 months ago

@ldesousa : I'm away these weeks but Simon in his comment (https://github.com/w3c/sdw-sosa-ssn/issues/47#issuecomment-2100292825) already summarised most of the reasons.

In many information system we work in, we know in advance the authorised ObservationProcedure for a given ~ObservationProcedure~ ObservableProperty. So feeding can also come prior to receiving/exposing actual observations.

Thus this would also allow for consistency checks as mentioned by Simon

dr-shorthair commented 5 months ago

And here is the alternative, using the proposed properties to link properties to procedures.

It starts with the same basic definition of three soil properties:

soil:sand a sosa:ObservableProperty ;
    skos:preflabel "Sand fraction"@en ;
    skos:note "Soil particles in the size range between 0.05 and 2.0 mm."@en .

soil:silt a sosa:ObservableProperty ;
    skos:preflabel "Silt fraction"@en ;
    skos:note "Soil particles in the size range between 0.002 and 0.05 mm."@en .

soil:soc a sosa:ObservableProperty ;
    skos:preflabel "Soil organic carbon"@en ;
    skos:note "Microbial, plant and animal detritus at various stages of decomposition, from humus to charcoal."@en .

And two laboratory procedures:

soil:drc a sosa:ObservationProcedure ;
    skos:preflabel "Dry combustion"@en ;
    skos:note "Complete flash combustion of a soil sample in the presence of oxide catalysts."@en .

soil:pip a sosa:ObservationProcedure ;
    skos:preflabel "Pipette"@en ;
    skos:note "Pipetting a known fraction of suspension to an evaporating dish and boiling off the water."@en .

Dry combustion is applied to measure the content of carbon and nitrogen, not texture. We express that directly in the ObservableProperty catalogue by decorating the property definition as follows

soil:soc a sosa:ObservableProperty ;
    skos:preflabel "Soil organic carbon"@en ;
    sosa:hasProcedure soil:drc ;
    skos:note "Microbial, plant and animal detritus at various stages of decomposition, from humus to charcoal."@en .

The pipette method applies to the two soil texture properties. We express that directly in the ObservableProperty catalogue by decorating the property definitions as follows

soil:sand a sosa:ObservableProperty ;
    skos:preflabel "Sand fraction"@en ;
    sosa:hasProcedure soil:pip ;
    skos:note "Soil particles in the size range between 0.05 and 2.0 mm."@en .

soil:silt a sosa:ObservableProperty ;
    skos:preflabel "Silt fraction"@en ;
    sosa:hasProcedure soil:pip ;
    skos:note "Soil particles in the size range between 0.002 and 0.05 mm."@en .

The ObservationProcedure catalogue might contain the inverse properties as follows

soil:drc a sosa:ObservationProcedure ;
    skos:preflabel "Dry combustion"@en ;
    sosa:forProperty soil:soc ;
    skos:note "Complete flash combustion of a soil sample in the presence of oxide catalysts."@en .

soil:pip a sosa:ObservationProcedure ;
    skos:preflabel "Pipette"@en ;
    sosa:forProperty soil:sand , soil:silt ;
    skos:note "Pipetting a known fraction of suspension to an evaporating dish and boiling off the water."@en .

The choice of which catalogue hosts the links depends on the business rules of the organization managing the soil observation definitions. Both might be recorded, in which case they provide a consistency check on each other.

Some pros and cons of this approach:

For

direct identification of related Properties/Procedures. (Both sosa:ObservableProperty and sosa:ObservationProcedure might be cast as sub-classes of skos:Concept so that these definitions could be hosted in a 'vocab service')
keeps the a-box 'data' in individuals, without using OWL restrictions and RDFS subclasses

Against

two additional properties in SOSA;
potential redundancy (i.e. more than one path from Observation to Procedure) (though this could provide a consistency/integrity check);

KathiSchleidt commented 5 months ago

If the link from ObsProc to ObsProp is too much, same could be said of the links from Sensor to ObsProp and ObsProc

ldesousa commented 5 months ago

Hi all, I yield. I had a nice discussion with @rapw3k on this, he wisely points out that the most important is for these changes to not break the current re-use philosophy. That clearly isn't the case here. The only remark of note is the similarity of some of these predicates, e.g. usedProcedure vs hasProcedure, thorough semantic descriptions are necessary.

One conclusion I take from this discussion is the need to consider two different ways SOSA is approached by users: 1) used directly to create instances in knowledge graphs; 2) re-used in ontologies specialising SOSA to a particular domain (e.g. GloSIS, AIM, etc).

KathiSchleidt commented 5 months ago

Sounds like there are no more arguments against adding this association :)

rob-metalinkage commented 5 months ago

@ldesousa I fully agree the specialisation Use Case should be explicit and tested for every specification. It's been the biggest barrier to standards adoption and interoperability IMHO.

dr-shorthair commented 5 months ago

Need one more positive review on #213 to merge.

dr-shorthair commented 5 months ago

Sounds like there are no more arguments against adding this association :)

@KathiSchleidt can you approve #213 then please?

w3c / sdw-sosa-ssn

Add association between ObservingProcedure and ObservableProperty #47

For

Against

For

Against