CollectionTypeByMemberCharacteristicsSemantics values

[KathiSchleidt]

OGC PART B 27/35

1. Requirement: ● homogenousObservationCollection, ● summarizingObservationCollection
2. Implementation Specification Section number: 10.12.1 CollectionTypeByMemberCharacteristicsSemantics
3. Criticality: Minor
4. Comments for changes: ● homogenous, ● summarizing
5. Justifications for changes: conciseness.

KS: Makes sense to me! Maybe even reduce the name of the codelist?

[KathiSchleidt]

The following entries SHALL be provided: ● homogenous: all observations contained are of a similar nature ● summarizing: a wider grab-bag type of collection

Agreed :)

[ilkkarinne]

Note that a draft for the vocabulary for this codelist and its two entries (as a SKOS collection and two member concepts) is now provided at https://github.com/opengeospatial/om-swg/blob/master/oms-abstract-spec/codelists/collectionTypeByMemberCharacteristicsSemantics.json

Since we did not have a formal definition of the Summarizing or Homogenous Observation collection in the spec, I used the following in the SKOS concepts:

• "In a homogenous Observation collection the properties provided though the memberCharacteristics are identical to the corresponding Observation properties of each collection member."
• "In a summarizing Observation collection, the properties provided though the memberCharacteristics provide the full range of the values of the corresponding Observation properties present in any of the collection members."

[ilkkarinne]

Sorry, the def. for the homogenous one was initially obviously wrong, now fixed in SKOS and in the comment above

[ilkkarinne]

Regarding the requirements /req/obs-basic/ObservationCollection/collectionType-homogenous-con and /req/obs-basic/ObservationCollection/collectionType-summarizing-con, I think we need to find out where to put them in the UML. We do not have classifiers for the codelist entries in model, but we do have the codelist class there. Would the CollectionTypeByMemberCharacteristicsSemantics be a suitable place for including these constraints?

The current constraints are probably too lengthy to copy-paste in full under the class constraints, and they also include conditions. Can we refer only provide references to the corresponding requirements by using they URIs in the constraints section of the class?

{see /req/obs-basic/ObservationCollection/collectionType-homogenous-con} {see /req/obs-basic/ObservationCollection/collectionType-summarizing-con}

In case you don't have the doc readily available, I'll paste the requirements below in full.

/req/obs-basic/ObservationCollection/collectionType-homogenous-con:

If collectionType is specified as homogenousObservationCollection from the CollectionTypeByMemberCharacteristicsSemantics Codelist, the following constraints apply to the associated ObservationCharacteristics and all Observation instances referenced via the member association.

If a property value is provided within the ObservationCharacteristics, this value applies to all contained observations (note: the observations need not contain this attribute as supplied via the ObservationCharacteristics):

• property not provided - values may be provided by the observations but is not provided at this level
• property provided but with no content - no observation within the collection provides this property
• property = value - this value applies to all observations within the collection
• property = value set/range - this value set/range applies to all observations within the collection

/req/obs-basic/ObservationCollection/collectionType-summarizing-con:

If collectionType is specified as summarizingObservationCollection from the CollectionTypeByMemberCharacteristicsSemantics Codelist, the following constraints apply to the associated ObservationCharacteristics and all Observation instances referenced via the member association.

If multiple values for a property are available in the contained observations, ALL values for this attribute (or the range of values contained in all Observations) are provided in the ObservationCharacteristics. A property may also be empty in the ObservationCharacteristics - in this case any value can be provided for this attribute within the contained Observations:

• property not provided - values may be provided by the observations but a summary is not provided at this level
• property provided but with no content - no observation within the collection provides this property
• property = value - this value applies to all observations within the collection
• property = value set/range - all observations provide a value within this set/range

[jetgeo]

There is probably no “correct” way of defining these requirements, but I have some suggestions for how it can be done in a structured and understandable way.

• Add the URI of the codelist you refer to in the requirements text. That would make the requirements more specific on which code list and value you actually refer to.
• Add the constraints to the ObservationCollection class, as that’s where the code values are applied.
• Use the requirement URIs as identifier (name) of the constraint.
• Add the requirement texts to the notes filed for the constraint.

The constraint will of course not be machine-processable, that would require a description in OCL.

[ilkkarinne]

Thanks for the suggestions @jetgeo. The 1st, 3rd and 4th bullet are clear and seem OK by me.

Regarding the place to add the constraints to: I agree that it would make sense to add the constraints to the class they affect. However, in our case these would have to be conditional as they would only be applicable in the case the particular instance of ObservationCollection would happen to have a particular instance (homogenous or summarizing) of the CollectionTypeByMemberCharacteristicsSemantics code list item as the value of its collectionType attribute. The constraints would not be applicable to any other instances of ObservationCollection.

The issue I see with including then in the ObservationCollection class is that the this class as likely to be implemented / reused in contexts where the homogenous/summarizing classification scheme is not relevant, and the collections are classified using other schemes, also possibly having similar constraints applicable to the collection and its members. We do not want to force them to specialize ObservationCollection for this, but rather extend the AbstractObservationCollectionTypeCodeListValue as seen fit.

[jetgeo]

I understand your concerns, but the requirements as described are already conditional. I don't see any need for subclassing to avoid them. They come into play only if the values in question are used. However, you may very well put the constraints on the empty codelist, if you prefer so. They will probably be only for human "processing", so it doesn't really matter that much :).

[KathiSchleidt]

Proposal: Shift constraints down to codelist itself (including all examples) add a constraint and req on collection indicating that if you use the codelist, the constraints on the codelist must be respected. Also add a note pointing to the codelist Same applies to Observation-by-Result-Type and Sample-by-Geometry_Type types/codelists

[ilkkarinne]

I have now edited the UML model based no the above resolution as follows:

• Two additional constraints for the Basic Observations: ObservationCollection:
  • "property values of the Observation instances associated by the member role shall comply with the constraints defined in the class of the collectionType attribute value" and
  • "property values of the ObservationCharacteristics instance associated by the memberCharacteristics role shall comply with the constraints defined in the class of the collectionType attribute value"
• Two additional constraints for the CollectionTypeByMemberCharacteristicsSemantics" with notes field values below:
  • "/req/obs-basic/CollectionTypeByMemberCharacteristicsSemantics/homogenous-con" and "/req/obs-basic/CollectionTypeByMemberCharacteristicsSemantics/homogenous-con" (note that these assume that the constraint IDs will be changed when moving from ObservationCollection to CollectionTypeByMemberCharacteristicsSemantics in the spec).

The notes field contents for the last two constraints are currently as follows in the UML:

/req/obs-basic/CollectionTypeByMemberCharacteristicsSemantics/homogenous-con:

If the value "homogenous" is used, the following constraints apply to the ObservationCharacteristics instance and all Observation instances associated with the ObservationCollection with roles memberCharacterics and member:

For each property of the associated ObservationCharacteristics, the following constraints apply to the corresponding property of each Observation member:

• Property not provided: varying values may be provided for the corresponding property by the member Observations.
• Property provided but with no content: none of the Observation members shall contain a value for the corresponding property.
• Property has other value: the same value applies to the corresponding property of all Observation members even if no value is provided in the particular member.

NOTE: The mechanism for providing a property with no content is implementation specific. Examples include providing a special "null" or "nil" value.

/req/obs-basic/CollectionTypeByMemberCharacteristicsSemantics/summarizing-con:

If the value "summarizing" is used, the following constraints apply to the ObservationCharacteristics instance and all Observation instances associated with the ObservationCollection with roles memberCharacterics and member:

For each property of the associated ObservationCharacteristics instance, the following constraints apply to the corresponding property of each Observation member:

• Property not provided: varying values may be provided for the corresponding property by the Observation members and no summary is provided at the collection level.
• Property provided but with no content: none of the Observation members shall contain a value for the corresponding property.
• Property contains a single, non-range value: the same value applies to the corresponding property of all Observation members even if no value is provided in the particular member.
• Property contains a value set or range value: all Observation members shall contain a value for the corresponding property that is within the provided value set or range.

NOTE: The mechanism for providing a property with no content is implementation specific. Examples include providing a special "null" or "nil" value.

If the above textual revision of current spec constraints for the homogenous and summarizing collection is ok by you I can copy the same texts as the values of the corresponding constraints in the specification.

[KathiSchleidt]

@ilkkarinne A general question to constraints in the UML - in some cases you provide the req identifier, details in the notes (e.g. /req/obs-basic/CollectionTypeByMemberCharacteristicsSemantics/summarizing-con, makes sense as too looooong for the UML), in others you have it descriptively inline (e.g. the two additional constraints for the Basic Observations: ObservationCollection. Difference to above is that in the UML the 2 constraints are merged, to my view more difficult to read, would prefer to keep split)

If we can decide, I'd be all for the first option, if we can get away with it!!!

General (but probably too late): I do find the name CollectionTypeByMemberCharacteristicsSemantics a mouthful! Interesting is that despite the lengthy name, it doesn't even mention that it deals with Observations. I'm tempted to propose ObservationCollectionTypeByMemberCharacteristicsSemanticsDefinedByTheOMSSWGInAFitOfMadness ;)

[KathiSchleidt]

@ilkkarinne another question - is there a reason why you rephrased all the constraints for homogeneous and summarizing? To my memory, a lot of work went into the definitions we have, all been updated after the review. In your version all rephrased freestyle - I admit I prefer the ones we defined and have in the doc

[KathiSchleidt]

I have some issues with the proposed two additional constraints for the Basic Observations: ObservationCollection:

• "property values of the Observation instances associated by the member role shall comply with the constraints defined in the class of the collectionType attribute value" and
• "property values of the ObservationCharacteristics instance associated by the memberCharacteristics role shall comply with the constraints defined in the class of the collectionType attribute value"

collectionType is optional, thus you cannot require the instances to comply. Also - seems strange to refer to codelist entries as classes

How about:

If the collectionType is provided, property values of the associated Observation and ObservationCharacteristics instances SHALL comply with the constraints defined for this collectionType value

[KathiSchleidt]

@ilkkarinne a heads-up that the codelists will also need to be adjusted, e.g. https://github.com/opengeospatial/om-swg/blob/master/oms-abstract-spec/codelists/collectionTypeByMemberCharacteristicsSemantics.json

[KathiSchleidt]

Also - do we foresee use of other codelists for collection type?

I just noticed that in the original constraint to /req/obs-basic/ObservationCollection/collectionType-sem, we state that "If information on the collection type is provided, the attribute collectionType:AbstractObservationCollectionTypeCodeListValue shall be used."

Issues:

• AbstractObservationCollectionTypeCodeListValue should just be AbstractObservationCollectionType
• This codelist is abstract, so cannot be used.

How about:

• "If information on the collection type is provided, values from a codelist derived from AbstractObservationCollectionType shall be used."

[KathiSchleidt]

Name goes down to ObservationCollectionType

[KathiSchleidt]

Constraint on Collection:

If the collectionType is provided, property values of the associated Observation and ObservationCharacteristics instances SHALL comply with the constraints defined for this collectionType value.

[KathiSchleidt]

First §: If collectionType in the ObservationCollection is specified as homogenous from this Codelist, the following constraints apply to the associated ObservationCharacteristics and all Observation instances referenced via the member association.

[KathiSchleidt]

Second §: If a property value is provided within the ObservationCharacteristics, this value applies to all Observations contained in the ObservationCollection:

Add after req: NOTE: the observations need not contain attributes or associations supplied via the ObservationCharacteristics when collectionType is set to homogeneous.