Conceptual Sampling : specialization of Procedure

[sgrellet]

The latest version of our 'Conceptual sampling schema' now has the following interfaces

• 'Procedure' then specialized into
• 'PeparingProcedure' : with Sample:preparationStep pointing at
• 'SamplingProcedure' : with Sampling:samplingProcedure and Sampler:implementedProcedure both pointing at it

It's not doing any harm (at least more consistent with previous version of that model) but aren't we overspecifying this ?
We could have those 3 associations just pointing to Procedure.

There are communities doing semantic models for Process/Methods we may not impose too much semantics. At least in this version of the standard.

[ilkkarinne]

If we have just one Procedure interface (and AbstractProcedure in the Core and Procedure classes in the Basic packages), the model is a bit simpler. The Procedure does not have any attributes, and only one association (relatedObservation), so its semantics could mostly be captured by the association role names pointing towards it (change procedure into observingProcedure and samplingProcedure etc.)

However, the backlink associations become issues: It makes no sense to have a relatedObservation association for the sampling procedure or relatedSampling for the observing procedure. We could however remove the relatedObservation association from the Procedure interface in the Conceptual observation schema, and only introduce the related observations and samplings in the Observation and Sampling core packages as associations for AbstractObservingProcedure realizes Procedure and AbstractSamplingProcedure realizes Procedure.

Considering the preparationStep association of Sample I'm not sure if we need the AbstractPreparingProcedure and concrete PreparingProcedure feature types, but if we do, than those would also realize the same Procedure interface and have the relatedSample association.

[ilkkarinne]

It was decided in the SWG meeting today that the Procedure backlinks towards Observation and Observer in the Conceptual observation schema are too important to lose due to the reuse of the Procedure in the Sample packages. Thus it was decided to introduce an ObservingProcedure interface generalizing Procedure in the Conceptual observation schema, and restore the bi-directional associations by associating the Observation and Observer with the ObservingProcedure rather than the generic Procedure.

To align the Procedure usage in the Sample packages I have also added a SamplingProcedure interface to the Conceptual sample schema package, and made the Sampling and Sampler associations bi-directional and pointing to the SamplingProcedure instead of the generic Procedure. The Sample preparationStep association still points to the generic Procedure (and thus has no backlink).

[sgrellet]

Now PreparationStep is a Class on its own (no association Class anymore)
It's definition states "A PreparationStep is an individual step pertaining to a PreparationProcedure."
However its 'processingDetails' association to PreparationProcedure is 0..*

The min card is surprizing as the PreparationStep by essence pertains to PreparationProcedure. I would expect min card to be 1