[Requests] RFC 37: CSIRO Comments on proposed O&M specification

Simon.Cox@csiro.au Simon.Cox at csiro.au
Sun Feb 25 19:29:29 EST 2007


Part A to be completed once.  Iterate Part B as needed.

 

 

PART A

 

 

1. Evaluator:

Simon Cox

CSIRO Exploration and Mining

PO Box 1130

Bentley, WA 6102, Australia

Simon.Cox at csiro.au

 

2. Submission: 

RFP #37

OGC document 05-087r4, Observations and Measurements

 

 

PART B

===========

1. Requirement: [1] 

Refactor specification, 

remove Sampling Features, SWE Common, Discrete Coverage, Geometry
Extensions into separate documents

 

2. Implementation Specification Section number: [7, Annex C, Annex D]

 

3. Criticality: [Major]

 

4. Comments/justifications for changes: [Comments]

The specification could be usefully refactored, removing some non-core
sections into separate documents. 

This would allow focus on the observation model, 

removing clauses which might draw essentially irrelevant criticism, 

and would enforce some useful discipline in clarifying the relationships
between the core model and supporting components. 

Suggest removing 

   * Sampling Features (clause 7; Annex C sub-clause 2; Annex D
sub-clause 3), 

   * SWE Common (Annex D subclause 5), 

   * Discrete Coverage (Annex D subclause 5, 

   * Geometry Extensions (Annex D sub-clause 4) 

into separate documents

 

OGC pending documents 07-002, 07-003, 06-188 and 07-001 cover the scope
proposed for the refactored material so the work for this change is
already well in hand.  

 

===========

1. Requirement: [2] 

Link Observation/Feature model with relevant "GF_" classes from ISO
19109

 

2. Implementation Specification Section number: [Clause 6, Figure 1]

 

3. Criticality: [Minor]

 

4. Comments/justifications for changes: [Comments]

The "AnyFeature" and "Phenomenon" classes are realizations of the
GF_FeatureType and GF_PropertyType meta-classes from ISO 19109. 

This should be indicated in the model. 

 

===========

. Requirement: [3] 

Change class name "Phenomenon" to "PropertyType"

 

2. Implementation Specification Section number: [Clause 6, Annex C]

 

3. Criticality: [Minor]

 

4. Comments/justifications for changes: [Comments]

As noted in comment [2], the Phenomenon class is an implementation of
the GF_PropertyType metaclass. 

The term Phenomenon was originally selected as a "neutral" term that did
not risk a clash with GML's narrow use of the term "property" for XML
patterns. 

However, the GML usage is also clearly consistent with the ISO 19101 and
ISO 19109 terminology so there is no need for coyness. 

It is most important to focus on getting the terminology correct at the
model level. 

The term "phenomenon" is not widely used for this purpose in the
relevant communities: "property" is more common. 

Furthermore, since the class is intended to support links to concepts
(definition) not data instances, the "Type" suffix is an appropriate
indication of the higher meta-level. 

 

============

1. Requirement: [4] 

Remove "Event" class; clarify "time" attributes

 

2. Implementation Specification Section number: [Clause 6.3]

 

3. Criticality: [Major]

 

4. Comments/justifications for changes: [Comments]

The Event superclass may not be a useful abstraction. 

- the notion of Event is more general and should be managed in a
separate specification. If this happens, then an amendment to O&M at
that time could be considered. 

- the notion that an Event can occur at a time more generic than a time
instant is inconsistent with the use of the word event in other ISO
19100 specifications (e.g. ISO 19109)

- the generic "time" attribute becomes ambiguous when inherited by a
more specialised class like Observation and divorced from its original
Event context

- various "time" properties are of interest in the context of
observations, and disambiguation of these is important to enable the
model to be generally comprehensible and useful

We suggest 

1. removing the Event class and the specialization relationship with
Observation, 

2. adding two attributes to the Observation class, viz. procedureTime,
samplingTime, 

3. add procedureParameter in place of eventParameter. 

These property names more explicitly convey the intended semantics. 

However, it should also be made clear in the text of the specification
that such specialized time properties may simply "copy-up" (denormalize)
values that can be found associated with the feature-of-interest or
procedure. 

 

============

1. Requirement: [5] 

Improve alignment between "Procedure" class and SensorML terminology

 

2. Implementation Specification Section number: [6.3, 6.6, Annex C 4]

 

3. Criticality: [Minor]

 

4. Comments/justifications for changes: [Comments]

The high-level model for procedure types provided in clause 6.6 and
Annex C differs in some small ways from the "process" model described in
SensorML. 

The model should be modified to provide a better match, so that the
SensorML model can be easily seen to be conformant. 

 

============

1. Requirement: [6] 

Introduce a stereotype <<observedProperty>> or <<estimatedProperty>> to
characterize those feature properties whose values are determined by
observation, in contrast to those assigned by an authority ("by
assertion").  

 

2. Implementation Specification Section number: [General, #]

 

3. Criticality: [Minor]

 

4. Comments/justifications for changes: [Comments]

The Observation model concerns the determination of property values
through some estimation procedure. 

This implies a classification of feature properties into those whose
values are amenable to an observation process and which will have some
associated error. 

This contrasts with those properties whose value is assigned by some
authority (e.g. name, owner) for which the value is exact.

Essentially this marks those feature properties against which
observations may be made. 

 

In due course this would be a potential addition to the suite of
stereotypes defined in ISO 19109. 

 

===========

1. Requirement: [7] 

Implement specialised Observation types using constraints instead of
property-type override. 

 

2. Implementation Specification Section number: [Clause 6.5; Annex D -
XML Schema implementation]

 

3. Criticality: [Major]

 

4. Comments/justifications for changes: [Comments]

The (informative) UML model and XML Schema implementation include
concrete elements for both generic (Observation) and specialized
observation types (Measurement, CategoryObservation, etc). 

In the UML this requires use of the "override" pattern, and in XML
Schema this requires insertion of an additional "abstract" layer to
avoid difficulties with derivation by restriction. 

The ISO recommendation in implementation models is to use constraints,
rather than override/type derivation. 

It is suggested that the XML Schema implementation be revised to use a
constraint language (ISO Schematron) instead of XML Schema derivation,
for specialized Observation types. 

 

 

______
Simon.Cox at csiro.au  CSIRO Exploration & Mining
26 Dick Perry Avenue, Kensington WA 6151 PO Box 1130, Bentley WA 6102
AUSTRALIA
T: +61(8) 6436 8639  F: +61(8) 6436 8555
C: +61(4) 0330 2672  http://www.csiro.au callto:dr_shorthair

ABN: 41 687 119 230 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.opengeospatial.org/mailman/private/requests/attachments/20070226/74904d24/attachment-0001.htm


More information about the Requests mailing list