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

[dr-shorthair]

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

Yes, this is the solution.
The OMS alignment clause is already normative. The sosa-oms: terms are tagged 'non-normative' because of the 'pending further implementation experience' caveat that we have for all of the new terms.

[dr-shorthair]

It would make more sense to keep only Property and drop the ObservableProperty and ActuableProperty.

These were in the 2017 edition.
So backward compatibility concerns arise.

[dr-shorthair]

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

Indeed. OWA says that nothing is 'mandated'. But there is a general relationship between procedures and systems which is captured by these terms.

[ldesousa]

It would make more sense to keep only Property and drop the ObservableProperty and ActuableProperty.

These were in the 2017 edition. So backward compatibility concerns arise.

I am also in favour of this simplification. Perhaps ObservableProperty and ActuableProperty can be "marked" as deprecated. And thus feature less proeminently in the diagrams.

[dr-shorthair]

keep only Property and drop the ObservableProperty and ActuableProperty

Please make this a separate issue.

[dr-shorthair]

Closed by #226

[alexrobin]

I probably missed a big part of this conversation but it seems that we lost ActuatingProcedure in the process of just using OMS terms for procedure specializations. This is something we were counting on in Connected Systems so I would really like to see it defined somewhere in the ontology. It would be kind of silly to have to define this in the OGC definition server while we have everything else related to Actuations here.

Furthermore, since Property specializations were removed, I believe using core SSN only there is no easy way to know that a Procedure is either an "Observing Procedure", "Actuating Procedure" or "Sampling Procedure", unless it is associated to a instance of the corresponding System subclass. IMHO we are making things more difficult that they should be.

[dr-shorthair]

We removed the procedure specialisations as part of a cull of new terms where their definitions did not seem to be very distinct. Do they have different properties to the general case? Do we have evidence of implementation?

I admit this one was closest to the edge for me.

[ldesousa]

@alexrobin When those specialisations were removed there no properties or associations telling them apart. Everything was already concentrated in the Procedure class.

In the context you put forth, I believe the alignment could be made by declaring the ActuatingProcedure class in Connected Systems as a subclass of sosa:Procedure.

[alexrobin]

@ldesousa I am aware that in the current model, the properties are identical, but from a discovery perspective, do we have a way to know that a procedure is either Observing, Sampling or Actuating?

Once all kind of procedures are registered in an ontology, it seems important to be able to distinguish these types easily, w/o having to create convoluted SPARQL queries.

In general, it also still seems odd to me that we would have separate Execution and System classes for the 3 flavors, but not for Procedures. As I said before, the fact that they have identical properties is more the result of a choice of words than anything else (if we generalize property names enough, then all Executions could end up with the same properties as well, same for Systems). Conceptually, the 3 kinds of procedures exist, just like for Executions and Systems.

In this case, I am afraid that our quest for simplification is going to make life harder in the end...

[ldesousa]

The reasoning for removal was the lack specific associations or properties to distinguish between the three sub-classes. Regarding discovery your questions are valid, however what a Procedure actually does is context dependent.

Let me offer a simple example: soil sieving. A sample of soil material is collected on the field and transported to the lab. There the sample is sieved tto separate the fine earth (particles smaller than 2 mm across) from coarse fragments. The sieving action produces a result, the fraction of fine earth in the soil material, and two new samples: one with the fine earth and another with the coarse fragments. Each of the latter are subject to further observations individually. Therefore the sieving procedure is associated to both Observation instances and Sampling instances.

A discovery mechanism based solely on SOSA/SSN would thus need to search for observations or samples in order to determine which procedure(s) are implied in each. Note also newly introduced predicates such as forProperty. Otherwise specialisation would be the way.

SELECT ?p
WHERE
{
    ?o a sosa:Observation ;
    ?o sosa:usedProcedure ?p .
}

[alexrobin]

@ldesousa Yes, that's how I understand the current model. But the consequence is that there is no way to discover specific subtypes of procedures if they are not (yet) associated to a result.

This is a pity because I can see many use cases where procedures would be registered before they are used.

[dr-shorthair]

Procedure registration (and Discovery) is a valid use case. The question is whether supporting it is in scope for SSN. We have ruled specific property- and system-models out of scope. But, as you have noted, we did go as far as distinguishing three classes of system, even though they had no distinct model or axiomatization.

@ldesousa allowing a procedure instance to be a member of more than one class is not a problem in RDF. So I'm not sure your argument holds up on ambiguity grounds. Furthermore, the specific sieve that implements the procedure would be both a sampler and sensor.

[alexrobin]

@dr-shorthair Thanks for chiming in. Yes I really believe this lack of parallelism between Procedure subtypes and System subtypes is conceptually strange. I understand the argument that we have no specific properties for the procedure subtypes at the moment but this can very well change in the future (and this way we will have the proper placeholders for them) and, in any case, I'm not sure this alone is an argument for removing a class that does exist conceptually.

@ldesousa I would really be thankful if we could reintroduce these classes because it solves a big issue for us in Connected Systems (and I suspect for others as well), and I don't think it hurts anything.

Thanks for your consideration.

[dr-shorthair]

Regarding the 'parallelism' argument, the key relationship at the generalized (abstract?) level is

• System implements Procedure https://w3c.github.io/sdw-sosa-ssn/ssn/#Systems-and-their-Deployment-overview

So here are where the three (potential) specializations would sit - replace Procedure with ActuationProcedure, ObservationProcedure and SamplingProcedure in the following:

• Actuator implements (Actuating)Procedure https://w3c.github.io/sdw-sosa-ssn/ssn/#Actuations-overview
• Sensor implements (Observing)Procedure https://w3c.github.io/sdw-sosa-ssn/ssn/#Observations-overview
• Sampler implements (Sampling)Procedure https://w3c.github.io/sdw-sosa-ssn/ssn/#Sampling-overview

I can see the merits of having those relationships relate to the specialized forms of Procedure.

If we were to (re-)introduce these, then we need to consider the axiomatization and backward-compatibility.
I think it would go like this.

In the SOSA modules:

in sosa-actuation.ttl

sosa:ActuatingProcedure 
  rdfs:isDefinedBy sosa-act: .

sosa:implements 
  schema:domainIncludes sosa:Actuator ;
  schema:rangeIncludes sosa:ActuatingProcedure ;
  rdfs:isDefinedBy sosa-common: .

in sosa-observation.ttl

sosa:ObservingProcedure 
  rdfs:isDefinedBy sosa-obs: .

sosa:implements 
  schema:domainIncludes sosa:Sensor;
  schema:rangeIncludes sosa:ObservingProcedure ;
  rdfs:isDefinedBy sosa-common: .

in sosa-sampling.ttl

sosa:SamplingProcedure 
  rdfs:isDefinedBy sosa-sam: .

sosa:implements 
  schema:domainIncludes sosa:Sampler;
  schema:rangeIncludes sosa:SamplingProcedure ;
  rdfs:isDefinedBy sosa-common: .

We have three new classes for Procedures (alongside the three old classes for Systems) which are not axiomatically related to the superclass at the SOSA level. So we add them into the rangeIncludes (and domainIncludes) for sosa:implements.
But remember: in the SOSA modules, the domain and range indications are merely hints and have no formal implications.
So overall I'm not sure if there would be any backward compatibility issues arising from updating the SOSA modules like this. @kjano ??

Then in the SSN modules:

in ssn-actuation.ttl

sosa:ActuatingProcedure rdfs:subClassOf sosa:Procedure ;
  rdfs:isDefinedBy sosa-act: .

sosa:Actuator 
  rdfs:subClassOf sosa:System ;
  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:implements ; owl:allValuesFrom sosa:ActuatingProcedure ] ;
  [...]
  rdfs:isDefinedBy sosa-act: .

in ssn-observation.ttl

sosa:ObservingProcedure rdfs:subClassOf sosa:Procedure ;
  rdfs:isDefinedBy sosa-obs: .

sosa:Sensor
  rdfs:subClassOf sosa:System ;
  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:implements ; owl:allValuesFrom sosa:ObservingProcedure ] ;
  [...]
  rdfs:isDefinedBy sosa-obs: .

in ssn-sampling.ttl

sosa:SamplingProcedure rdfs:subClassOf sosa:Procedure ;
  rdfs:isDefinedBy sosa-sam: .

sosa:Sampler
  rdfs:subClassOf sosa:System ;
  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:implements ; owl:allValuesFrom sosa:SamplingProcedure ] ;
  [...]
  rdfs:isDefinedBy sosa-sam: .

The guarded restrictions relating to sosa:implements added into the SSN modules here introduce new entailments on any existing data. But in the RDFS/OWL level I don't see that breaking anything, because it would merely say that the individual procedure implemented by a specific sensor is a sosa:ObservingProcedure which is a sub-class of the sosa:Procedure which is the type that would have been asserted in data previously been, etc.

[alexrobin]

@dr-shorthair Thanks for this proposal. I agree that specializing the implements relationship also makes sense. I like the way you did it to avoid breaking any formal reasoning at the SOSA level.

[dr-shorthair]

Discussed at length in 2025-01-15 telecon.

The symmetry argument is acknowledged. Particularly since ObservingProcedure and SamplingProcedure (and PreparationProcedure) are normative in the OMS Extension.

Pruning proposed new terms was partly motivated by the need for 'evidence of implementation'.
@alexrobin @maximelefrancois86 will you be able to provide links to implementation of ActuatingProcedure?

The OMS team can provide evidence for ObservingProcedure and SamplingProcedure (and PreparationProcedure).

Some discomfort about the lack of specific content models for ActuatingProcedure, ObservingProcedure and SamplingProcedure.
Note, however, that the specializations of System (i.e. Actuator Sensor Sampler do not have content models specified in SSN/SOSA.

[oldskeptic]

What I'd like to see is a case where the contents of ObservingProcedure, SamplingProcedure or PreparationProcedure have a different structure or content that demonstrates their specialization beyond a different narrative.

What makes a ObservingProcedure andSamplingProcedure structurally different besides linking back to different class instances?

[dr-shorthair]

Note that in the RDF proposed above, the focus is on modifying the range of sosa:implements in different contexts:

• in the SOSA modules by adding the matching procedure type using schema:rangeIncludes in the specific module (e.g. sosa-actuation)
• in the SSN modules by adding the matching procedure type as a guarded constraint (owl:Restriction) on sosa:implements in the context of the system specialization (e.g. sosa:Actuator)

[alexrobin]

@dr-shorthair Yes, I confirm that the Connected Systems group will be able to provide proof of implementation for ActuatingProcedure (as well as ObservingProcedure and SamplingProcedure).

@oldskeptic I don't think the choice of classes should be driven by their contents. The reason why the content model is what it is today is because we haven't really dug into the details of how a procedure should be described and left that up to implementations. But since the specializations exist conceptually, I think it is important to define the corresponding classes for implementations to plug into and provide appropriate details. Depending on how it's used, the contents of the different specializations might be similar (for example if the content is just a list of steps), but it could also differ greatly. In any case, by providing separate classes, whatever the contents provided by an implementation, there will be a common way of distinguishing the specialized procedures. This means that one doesn't need to look at the details of the procedure description to figure out if it can be applied to an observation, a sampling or an actuation. Otherwise, I bet everybody will come up with implementation specific properties to achieve the same (and that would be a pity...)