Input, Output, Result, Condition, are roles, and shouldn't be named classes

[maximelefrancois86]

Anything can be an input, an output, a result, or a condition. It's just a role that something has in some description.

The relevant information are the binary relations ssn:hasInput, ssn:hasOutput, sosa:hasResult, ssn:inCondition.

Proposal: deprecate or delete the classes ssn:Input, ssn:Output, sosa:Result, ssn:Condition

[dr-shorthair]

I'm inclined to agree. However, is there a backward-compatibility issue? Do any of the known implementations use these classes?

The same argument could apply to FeatureOfInterest - see #114. When this was brought up in 2016 (?) I think @kjano argued that there was some utility in being able to classify something as 'being of interest in the context of an Observation or Actuation or Sampling'.

[maximelefrancois86]

I have very little record of usage for these classes. From https://w3c.github.io/sdw/ssn-usage/

ssn:Input is used in 1 dataset ssn:Output is used in 1 dataset sosa:Result is used in 1 dataset ssn:Condition (non-normative) is used in 1 dataset

The situation is a bit different for sosa:FeatureOfInterest, I admit, as it is reported to be used in all 16 dataset in https://w3c.github.io/sdw/ssn-usage/

If we're aiming for a backward-compatible version (I think it's important), then probably we should just:

• deprecate the classes in the ontology,
• do not mention them in the documentation and diagrams

[dr-shorthair]

OMS uses the Ur-class Any in these situations.

[dr-shorthair]

I'd be OK deprecating these - I don't think they add anything except to help drawing diagrams.

@kjano do you have a view here?

[maximelefrancois86]

I agree with the proposal

[sgrellet]

I agree as well.

[hylkevds]

There is also the distinction between what is attached to the Procedure and what is attached to the ProcedureExecution.

• The Procedure describes the process in abstract terms, so the inputs and outputs should also be described in abstract terms. In this usage the classes make sense, since one can't point to any specific instance.
• The ProcedureExecution is the actual execution instance of the Process. Here the inputs and outputs should point to actual values.

Even in the second case, an intermediary class may be required, since the inputs and outputs need to be linked to their abstract descriptions of the Procedure. If my Procedure has two input temperatures, my ProcedureExecution will have two values for those temperatures, and it's important to know which value belongs to which input. For example, an oven that can first heat for a minutes at temperature b, then for c minutes at temperature d.

We don't need four Classes for this. Something like a class ParameterDescription and ParameterValue would be better, but I can imagine those already exist elsewhere.

[dr-shorthair]

In #105 I suggested that hadInput would be the property of a ProcedureExecution (was Observation), which distinguishes it from hasInput which applies to Procedure.

However, @maximelefrancois86 noted the potential confusion from just a single letter difference.