Generalization vs realization

[heidivanparys]

Comment in response to https://www.ogc.org/standards/requests/246:

Figure 7, Feature GeoPackage classes:

Why are the following relations shows as realizations (I think, see also #622)?:

• FeatureStore → EntityStore
• Feature → Entity
• FeatureType → EntityType

I would think that these relations are generalizations, just as the following relations are shown as generalizations:

• GeometryAttributeType → AttributeType
• GeometryAttribute → Attribute

A realization is a kind of abstraction, used to relate elements at a different level of abstraction, that does not seem to be the case here.

[jyutzler]

This gets into murky theory. A GeoPackage must store both entities and the meta-model for those entities. It is a challenge to model. In my opinion, UML isn't perfect for this purpose but I am not aware of a better alternative. I used "realization" because features/tiles are different implementations of entity stores. Calling them generalizations is really missing the point.

I suggest a WONTFIX to this ticket but perhaps if I come up with some verbs as requested in #623, we will have something that will satisfy you.

[heidivanparys]

So the realizations are on purpose. So then my question would be, then why are the following relations modelled as generalizations:

• GeometryAttributeType → AttributeType
• GeometryAttribute → Attribute

It's ok for me don'tnot to change anything in the specification, I was really just wondering why things are modelled the way they are.

[jyutzler]

Again, this is all murky and not well-defined by UML. The generalizations do have inherited properties. The realizations do not. Take, for example, the FeatureStore as a realization of an EntityStore. An EntityStore is a completely abstract concept. It has no common properties and this is demonstrated by the lack of commonality between FeatureStore and TileStore. However, they do share behaviors (EntityStores support CRUD operations on their content.) I understand how a UML purist would bristle at this usage (particularly realization) but I thought that the two ideas I was trying to convey were different enough that it warranted using different nouns, even though one defied a precise noun.

Naming things is the single hardest part of these modeling exercises. It is enough to drive anyone crazy so constructive suggestions are greatly appreciated.

[jyutzler]

I'm sweeping all of the diagrams before I post to pending. I am going to ensure that realizations are used for abstract relationships (i.e., the supplier is abstract) and that generalizations are used for concrete relationships (i.e., the supplier is concrete). I am also defining these terms in section 4. I think this is the best we can do.