21-049 - Public Comments - Carl Reed

[geofizzydrink]

Issue to track communications and comments related to 21-049 as it passes through the OGC publication cycle. This part of the cycle is relevant OAB review and Public Comment.

[cmheazel]

February 26, 2024 e-mail from Chuck Heazel to Carl Reed

Thanks Carl,

Some responses to your comments --

#1: The POI data dictionary and diagrams are machine generated from the ISO TC211 Harmonized UML model. We used the same tools and practices used for the CityGML 3.0 Conceptual Model. We had to use ISO Standards because there is no harmonized UML model for OGC. We expect that this standard will be used by developers of Implementation Specifications. They will most likely use ShapeChange to generate the GML and JSON schema. These folks are comfortable using the ISO Standards (or to be more precise, the Harmonized UML model).
#2: According to the ModSpec there is a one-to-one correspondence between Requirements Classes and Conformance Classes. That would mean that each UML class in POI is a separate Conformance Class. Not very manageable. A Requirements Module would make more sense. Or, the OAB could find that defining a requirement for each attribute of a UML class is excessive. That would eliminate most of the problem requirements.
#3: Agreed
#4: Until the doc type registry is fixed "Implementation Specification" is our only "valid" option.
#5: Nope. Haven't looked at Location Services in years. Probably overlooking a lot of good work.
#6: Actually it's a Platform Independent Model. I'm open to synonyms.

Thanks for the red-lines. I should be able to incorporate most of them. I'll include an explanation for the rest.

Chuck

On 2/26/2024 3:26 PM, Carl Reed wrote:

All -

Please find attached a Word copy of the draft PoI "Conceptual" Model Standard. Looks very complete! Some of the UML diagrams are hard to read - but this is most likely a publication issue. (Scott, see item 3 below).

A few considerations (both as a reviewer and as an OAB Member):

1. I worry about the "heavy" focus on ISO Standards. First, there is the cost if the reader/developer has not already paid for copies of all of the ISO Standards that are normatively referenced in the PoI document. I also worry about the time necessary to read all of those documents (and understand them)! For CDB 2.0 we referenced ISO Standards - but usually not in requirements or requirements classes. For example, ISO 19107 is mentioned but the requirements classes for Geometry and Topology reference OGC Standards such as Simple Features. For CRS, CDB 2.0 references the OGC Abstract Specification and not the ISO document.
2. What appears to me to be a requirements class is titled "Requirement", such as "Requirement 3: Requirement — Abstract Feature". As such for this class, "A" would be a dependency and B through E would be a list of the requirements for that class.
3. Maybe this is just me, but a sentence or two to introduce each requirement would really help provide context. For example, "Encodings of the description attribute SHALL be a valid implementation of the CharacterString class from ISO 19103" means nothing to me other than I need to have a copy of 19103 - which I have not read. So some additional content - at least for readers such as me - would be helpful.
4. Implementation Standard viz Implementation Specification. Over 10 years ago, the OGC Membership agreed to calling approved OGC Standards "Implementation Standards" and not "Implementation Specifications". Documents external to the OGC, such as STAC, can be referred to as specifications. I checked the TC PnP and the Policy Directives - Standards. I checked the doc type registry and Rainbow (http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/doc-type/) Oh-oh. Got a problem there. The list does not include a type "Implementation Standard". Not sure why. Also shows a type "Ballot Document" - which the OGC no longer has. Anyway, I noted the use of "Implementation Specification" in the PoI document. I am not sure whether they need to be changed to "Implementation Standard" or not. Something to discuss.
5. Did you look at the OGC Location Services Standard? That OGC Standard defines a PoI Abstract Data Type. Not a biggie - more informative.
6. Finally, "Conceptual Model" :-) I really do not like the ISO 19101 definition. I much prefer the CEN definition which captures the context way better WRT what we do in the OGC
   conceptual model

description of common concepts and their relationships, particularly in order to facilitate exchange of information between parties within a specific domain. A conceptual model is explicitly chosen to be independent of design or implementation concerns.

(SOURCE: CEN ENV 1613:1995)

FYI, I spent considerable time a few years ago researching Conceptual, Logical, and Physical models. This was part of my work on the Tiling Abstract Specification. I ended up writing two clauses for that document that clearly define the terms Concpetual and Logical in the context of that Abstract specification.

Sorry for the longish email - and item 4 above is probably an OGC website/registry issue. Of course, many longtime OGC Members still say "specification" when they should be saying "Standard" :-) A hard one to stamp out!

If you have any questions, please let me know.

Regards

Carl

[cmheazel]

Adjudication of comments provided as tracked changes in the Word document:

1. Implementation Standard - this change can be made once "Implementation Standard" is a valid OGC document type.
2. Table 4 - class name - a class name should not include an abbreviation.
3. Table 4 - definition - this is the definition provided by the SSN/SOSA ontology and should not be changed.
4. Table 9 - definition - change has also been made to the UML model.
5. Table B.2 - definition - this was generated from the TC211 Harmonized UML model. Corrected in the text, but change may be lost if this data dictionary is regenerated.
6. Table B.6 - definition - this was generated from the TC211 Harmonized UML model. Corrected in the text, but change may be lost if this data dictionary is regenerated.
7. Table B.12 - reference attribute - this was generated from the TC211 Harmonized UML model. Corrected in the text, but change may be lost if this data dictionary is regenerated.
8. Table B.16 - ontology attribute - this was generated from the TC211 Harmonized UML model. Corrected in the text, but change may be lost if this data dictionary is regenerated.
9. Table B.17 - keyword attribute - this was generated from the TC211 Harmonized UML model. Since this is correct European spelling and valid under ISO conventions, no changes were made.

All other recommended changes were applied.