Remove Procedure specializations from SOSA

[dr-shorthair]

Following on from the discussion in #225

We added ObservingProcedure, SamplingProcedure to SOSA as part of the OMS alignment, and then ActuatingProcedure for consistency.

However, it is not clear that they have much utility or significance in the context of SSN.

1. they are not compatible with 2017 SOSA. Since SOSA does not include sub-class relationships, changing the range of an observation's sosa:usedProcedure from sosa:Procedure to sosa:ObservingProcedure might break backward compatibility.
2. they are unnecessary. Procedures used for Actuations will be Actuating-Procedures anyway, those used for Observations will be Observing-Procedures, those used for Samplings will be Sampling-Procedures, etc.

We were perhaps a bit too quick in adding these specializations.
My work looking at the consistency of the predicates has exposed this.
(They could be moved back to the sosa-oms: namespace alongside sosa-oms:PreparationProcedure.)

[dr-shorthair]

@hylkevds commented

The only use that I can think of is that it is easier to ask "Give me all instances of ObservingProcedure" than the alternative if they are all just instances of "Procedure" and require looking at the relations to figure out what a given Procedure is.

[sgrellet]

I guess one extra question is : to what extend would we model those 3 subtypes of procedures with element(s) that are specific to each of those (ex : do we want to add extra properties to SamplingProcedure that are raally really specific to it).

If none (for now), there is no need to separate each of them individually here apart from the OMS alignment.

[rob-metalinkage]

I would say that an Observable Properties model, and an Observing Procedure model, would be the basis of asking questions about these, and SOSA doesnt need to have anything other than a common predicate to link,

[alexrobin]

I see SOSA as a registry of concepts too and from that standpoint it's useful to have them separated, even though at the moment they have the same properties. I think if you generalize too much, the concepts are not so useful and even confusing.

Also if you keep generalizing property names then you'll end up in the same situation with Sensor/Actuator (they will have the same properties, e.g. observes could be renamed forProperty, etc..) and you could keep only the System class.

To me this is going in the wrong direction. It's useful to have generalized super classes and property names but you also need to keep the concrete ones to make the ontology useful and understandable.

[oldskeptic]

@alexrobin I understand why you want to use the SOSA ontology as a flat "registry of concepts", but it doesn't strike me as a good design guideline.

You argument goes the other way too. Right now, the only thing that differentiates an ObservingProcedure from a SamplingProcedure is the label and the class it links to. Unless there is a materialized / structural explanation for what makes them different, what is the point of specializing a Procedure?

[rob-metalinkage]

Agreed 17 July 2024 to move these to the sosa-oms namespace

[dr-shorthair]

ObservingProcedure and SamplingProcedure moved to sosa-oms: namespace and removed from diagrams

See preview https://raw.githack.com/w3c/sdw-sosa-ssn/225-madebysystem/ssn/index.html#OMS-Alignment-New-Terms

[alexrobin]

I don't get it.
Can somebody explain why these why specializations were considered useful in OMS but not in SOSA?

[oldskeptic]

From OMS : "The conceptual schema specified in this document is in accordance with the Unified Modelling Language.." while SOSA/SSN is an ontology.
Unless we differentiate Observing-Procedures from Sampling-Procedures what is the point to having them?

[alexrobin]

@oldskeptic The main reason why we revived the SOSA-SSN group was to merge the work from OMS back into SOSA. If we keep everything new introduced by OMS outside of SOSA, we're not really achieving this goal.

Besides, the only reason why the procedure specializations are identical is because we chose them to be. We could very well have chosen to create more specific properties just like we did for System specializations.

I would be ok if the sosa-oms ontology also becomes normative, but will this be the case?

[alexrobin]

@rob-metalinkage The only reason why you can figure out a procedure is of a given subtype (i.e. observing, actuating or sampling) if it's not yet implemented by any System is by looking at the associated property. (and BTW I don't think the Procedure->System association should be mandated as it is not scalable so we should not rely on it).

However I don't see how you can differentiate ObservingProcedure from SamplingProcedure as they would both be associated to ObservableProperties. I also suspect at least some SamplingProcedure would not be associated to any property at all.

Also, I think we have it backward. It would make more sense to keep only Property and drop the ObservableProperty and ActuableProperty. A property is just a property. The same property can be both observed or acted upon and that can be inferred from the context. If we keep them separate then we make it hard to understand that it is the same property that is both measured by a sensor and controlled by an actuator (e.g. the temperature of a room is both measured by a sensor and controlled by the heating system).

Procedures and Systems, however, are intended to do only one of those things: observe, actuate or sample. And this is known at the time you create the instance or subclass, so it makes sense to have specializations.

[KathiSchleidt]

+1 on making sosa-oms normative. This had been my assumption to date. Then all you'd need to define is actuatingProcedure.

I'm actually wondering if this should be in the Alignments section as in contrast to the other alignments, the OMS Alignment Module has New Terms.

On Procedure being for a Property, not sure if all SamplingProcedure sample by a property, same goes for preparationProcedure.

I hadn't caught the specialized Property types, not sure we need them, agree with @alexrobin above that a Property is a Property, same in both Sensing and Actuation. Think this differentiation is even less important that the Procedure subtypes!

I don't think the Procedure->System association should be mandated

As with all OWL Object Properties, sosa:implementedBy is not mandated, just a possibility, just like the inverse sosa:implements