Content model for Execution (was ProcedureExecution)

[dr-shorthair]

Closes #164

[dr-shorthair]

Should hasInputValue be added - see #105 ?

[ldesousa]

After the explanation during today's conference call the role of this class became clear. However, I am concerned the name may generate some confusion. It is not as concise as the other main concepts and contains the name of an existing class (Procedure). Names like Action (OMD software) or Activity (from Prov ontology) to my mind would be more effective.

[sgrellet]

agreed.

during Jan 18th webconf the issue of name conflict between ProcedureExecutionand sosa:Procedure was raised.

Not the interest of this new class (which makes a lot of sense as it gives reality to an implictly common super class), just its naming. To avoid misunderstanding by users.

A suggestion was to name it Activity. And it would actually be interesting to consider link with prov:Activity (subtyping?)

[dr-shorthair]

@maximelefrancois86 it seems that the name ProcedureExecution is causing some confusion. Would renaming to sosa:Activity (parallel to prov:Activity) cause any problems?

[maximelefrancois86]

I'd be ok with a simpler name, but note many properties that would be attached to that class would be weird if attached to Activity:

• madeBy
• hasFeatureOfInterest
• hasUltimateFeatureOfInterest
• hasResultTime

Users may wonder why such a general concept like Activity needs to be made by a sensor/actuator, be about a feature of interest, and have exactly one result...

I thought the name ProcedureExecution would help to make clear the distinction with Procedure.

DUL and PROV-O alignments are both important and structuring.

PROV-O offers Activity as you pointed out

DUL offers:

Event: Any physical, social, or mental process, event, or state. Action -> An Event with at least one Agent that isParticipantIn it, and that executes a Task that typically isDefinedIn a Plan, Workflow, Project, etc. ------> this perfectly aligns to our idea of what a procedure execution is Process -> This is a placeholder for events that are considered in their evolution, or anyway not strictly dependent on agents, tasks, and plans.

[hylkevds]

One advantage of the name ProcedureExecution is that it is quite clearly the Execution of a Procedure, and not some other, non-Procedure-related Activity. How about just Execution? Since that name implies that there is something else that is being executed (a program or procedure).

[maximelefrancois86]

I'd be happy with Execution

[dr-shorthair]

I just added hasInputValue and hasOutputValue for use on Executions. But I have a feeling more documentation and justification or patterns is required. Can @hylkevds or @alexrobin or @maximelefrancois86 or @sgrellet step in here please?

FWIW I'm somewhat uncertain of the hasOutputValue semantics and how it relates to hasResult.

[dr-shorthair]

As usual, the browser view for this branch can be seen at https://raw.githack.com/w3c/sdw-sosa-ssn/ProcedureExecution-spec/ssn/index.html

[hylkevds]

hasInputValue and hasOutputValue will need two properties:

• One that points to what the hasInput / hasOutput of the Procedure points to. How about forInput / forOputput?
• One that points to the actual value. hasValue?

The text is a bit confused at the moment. How about: has Input Value - Assigns a value (hasValue) to an input (forInput) defined by the Procedure that is implemented by an Execution (Actuation, Observation, Sampling).

[dr-shorthair]

Thank you for the suggested improvement to the wording.

I'm reluctant to propose a detailed content model for the object of hasInputValue and hasOutputValue without implementation experience. These terms will probably need to be tagged non-normative anyway. If you do want to push this further, then can you do it in concrete form through a PR?

[dr-shorthair]

closes #105

[dr-shorthair]

@hylkevds to push this further can you make a PR?

[dr-shorthair]

This PR must be merged prior to the major modularization work suggested in https://github.com/w3c/sdw-sosa-ssn/issues/183#issuecomment-1913860023

We can revisit the hasInputValue issue later if required. (@hylkevds you can create a new issue for that)

[alexrobin]

I personally liked the name ProcedureExecution better. I find the Execution term too vague given that we are talking about a very specific type of execution. I don't think having a longer name really matters since this class is not meant to be used directly.

I agree with @dr-shorthair that we should revisit the definition of input/output at a later stage (separate PR) since I feel it can get complicated...

[maximelefrancois86]

hasInputValue and hasOutputValue will need two properties:

• One that points to what the hasInput / hasOutput of the Procedure points to. How about forInput / forOputput?
• One that points to the actual value. hasValue?

The text is a bit confused at the moment. How about: has Input Value - Assigns a value (hasValue) to an input (forInput) defined by the Procedure that is implemented by an Execution (Actuation, Observation, Sampling).

We would solve this problem differently in SAREF (ETSI TS 103264 V3.2.1): applications would define different sub-properties of hasInput to distinguish the different inputs, and these sub-properties would apply to commands and to executions of that command. In the case of controlling an oven, inputs could be: ex:hasPhase1TemperatureIncreaseRate, ex:hasPhase1Duration, ex:hasPhase2ConstantTemperature, ex:hasPhase2Duration ...