4.1.  Classification of models

There are essentially three levels or types of models that can be employed, as follows.

• Conceptual — a 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 (OGC 19-014r3, after CEN ENV 1613:1995).

• Logical — an abstract representation of an interface or data model that can be executed to produce physical artifacts. Another oft-cited aspect of this is that logical models be machine readable, although this is not considered mandatory in this paper. Logical models, although abstracted from physical models, usually have some overarching approach, for example, relational databases.

• Physical — the implementable artifacts, these may be produced from the logical model or produced independently.

The OGC utilizes all three models in the general sense, however, only the physical model is mandated and is usually expressed in the form of an XML schema, a JSON schema, or an interface definition. In the majority of cases, the physical models are generated at the physical level, either manually or by crafting the definition using an editor to do so. There are methodologies (discussed later) that allow automatic movement from the logical to the physical level of modeling provided the artifacts are crafted according to a set of rules that fit the transformation process. Conceptual models are slightly different in this hierarchy, as there isn’t a defined transformation process.

The OGC has upon occasion conflated or interchanged the terms conceptual and logical to describe many of the models. It should be recognized that these are different levels of modeling for different purposes. Confusingly, an alternative model ordering that simplifies the definition of model types is defined in Model Driven Architecture (MDA) , these are:

• Platform Independent Model (PIM); and

• Platform Specific Model (PSM).

The two models are utilized in MDA to describe an independent model to create multiple specific models, that is, the relationship between PIM and PSM should be one to many. Whether the definition of a PIM requires it to be transformed into a PSM is a matter for discussion. An additional consideration is what a PIM and PSM looks like in terms of technology. PIMs by definition need to abstract from any particular technology in order to generate specific representations ready for implementation. In many cases, the PIM is represented as a Unified Modeling Language (UML) class diagram (but not always). PSMs maybe a specialized version of the PIM in UML, but they are more often representations in a target technology (for example, an XML schema).

PIMs in practice are not necessarily completely independent of a target technology and maybe abstracted to a technology approach. An example of this is relational databases modeled using UML class diagrams. The concepts within relational databases are well accepted — 1st, 2nd, and 3rd normal form, the use of primary and foreign keys, code lists, and enumerations are all well accepted within the relational database modeling community, which in turn allows for technology specific artifacts (Postgres DDL, Oracle, SQL Server, etc.) to be derived from the same PIM. At this point, it is a case of ordering the model detail into the correct representation for the target technology. However, generating database artifacts (PSM) with a different approach such as NoSQL or an Elastic instance is likely to be more challenging.

4.2.  OGC discussions on conceptual modeling

This section contains a summary of recent previous discussions within the OGC regarding conceptual modeling and its applicability to the OGC as a whole. The Boulder 2015 TC meeting captured the following benefits regarding conceptual modeling:

• Promotes consensus on the concepts, independent of implementation-specific standards;

• Communicates the concepts and their intended meanings – easier than reading an encoding; and

• Helps ensure compatibility between multiple implementations.

The last point in that list is key to the push for conceptual modeling and an associated group to understand and govern the creation of the models. OWS Common, and more recently, OGC API — Common are essentially specifications that all of the other standards in each suite utilize. Compatibility between implementations of individual standards should be granted by underlying concepts such as Common and having a set of tools and agreed upon modeling language to help that cause is key to success. Additionally, implementation compatibility can be facilitated if processes (such as MDA) can be employed appropriately.

A presentation at the aforementioned Boulder meeting proposed that all OGC Standards shall have a conceptual model and cites similar benefits with the addition of conceptual models being a precursor to the semantic web that has an explicit goal to make data on the web machine readable. In order to make that happen, there has to be agreement on the meaning of terms and abstracted concepts. Tools like conceptual modeling can help with this as standards can inherit concepts already defined. A typical example is the concept of a feature; a feature has certain properties including a geometry, which is also a recognized concept and every standard that utilizes a feature has the same concept, but not necessarily the same encoding (GML Vs GeoJSON, for example).

Conceptual modeling has been discussed in the OGC Architecture Board (OAB) several times and has shown that it has been considered by several different groups. For example, issue 1438 suggests that the CityGML SWG has sought to create a conceptual model for the CityGML 3.0 standard that can be used as a template for all other standards within the OGC. Whether this ambition comes to fruition is currently unknown. The group has created and refined a complex and sophisticated set of conceptual models. However, whether they can be considered conceptual or logical is debatable, as they utilize many ISO 19000 standards, which are inherently XML based.

A known issue with conceptual models is their accessibility within the standards in which they do appear. Another OAB issue highlighted the lack of accessibility of conceptual models when they are developed. An example given is again CityGML 3.0, where although the UML is present in the documentation, however, accessibility of the model is limited to the generated images. A solution to this is to make the full model available either in its raw form (an Enterprise Architect -EA file or an XML Metadata Interchange — XMI file), or via a generated set of HTML pages available in EA to enable implementers to explore the model attributes. At the time of publication of this Discussion Paper, the CityGML 3.0 UML source is planned to be hosted by the OGC in a public repository.

Another noted issue is that some standards that contain UML models are incorrect with many errors. An additional consideration is how much UML models should be harmonized across the OGC and with models that are relied upon in ISO TC211, which many of the older standards relied upon.

Observations from this section are as follows.

• There is a recognized need for conceptual modeling within the OGC, although the scope and requirement is unclear.

• The use of the terms conceptual and logical to describe models are often conflated or used interchangeably.

• Some standards do have normative UML models, notably CityGML 3.0

• The models that are available are not necessarily accessible, and therefore not as useful as what they otherwise might be.

• Worryingly, some of the UML models that are available are incorrect in terms of their construction and do not necessarily harmonize with each other or supporting models from ISO TC211.

• The value added by conceptual modeling differs between efforts.

4.3.  OGC conceptual modeling initiatives

There have been several formal attempts to utilize conceptual modeling within the OGC. Two recent documents include the following:

• UML-to-GML Application Schema Pilot (UGAS-2020) Engineering Report [[OGC20_012]]

• OGC Testbed-16: OpenAPI Engineering Report [[OGC20_033]]

The UGAS Pilot (2020) had many objectives, the following are relevant to this discussion:

• Refine UML to JSON rules for the UML schema of the US National System for Geospatial Intelligence (NSG); amd

• A preliminary investigation into MDA for OpenAPI interfaces (work eventually completed in Testbed-16).

The UML to JSON schema aspect took a direct approach when converting from UML to JSON, that is, they did not enforce a metamodel/model pattern and the approach in the same manner as Testbed-16, where the model classes are essentially specializations of the metamodel. The UGAS Pilot, as suggested by the acronym, utilizes the Application Schema model from ISO 19109 and depends on the requirements of the ISO 19103 Conceptual Schema Language. Although there is no direct JSON alternative to Application Schema, the approach taken in the Pilot seeks to fulfill the requirements of Applications Schema using a ‘first principles’ approach to derive translations based upon common JSON patterns of use, GeoJSON design and other pragmatic considerations.

The Testbed-16 OpenAPI thread enabled the creation of an MDA pipeline for OpenAPI interfaces with an initial demonstration using OGC API — Features Part — 1:Core as well as some other simplistic, non-OGC conformant OpenAPI interfaces. The work involved creating a metamodel for the OpenAPI specification that could be specialized into implementations that were then run through the ShapeChange transformation software. A plugin for ShapeChange was created to do the transformation from UML to JSON, this was made simple by using the metamodel construct to apply rules at the abstract level. The exercise resulted in a compliant OGC API — Features — Part 1: Core output, however the test case demonstrated was simplistic and relied on references to defined components, schemas and parameters.

Although the OpenAPI tests completed in Testbed-16 were a success, there were several recommendations that were made regarding the MDA process, the salient ones are thus:

• Complex modeling process should be simplified through packaging;

• The process of creating an interface should be reversible; and

• The relationship between a standard and encoding should be recognized.

The final point provides the strongest argument for conceptual modeling as an end rather than just a means (such as in MDA). Domain knowledge changes infrequently while technology changes frequently. Therefore, many version changes in standards simply reflect the old domain knowledge in a new encoding, potentially with refinements and extensions. Conceptual modeling allows the domain knowledge to be held in a single place that can be extended and amended at the most abstract level. If conceptual modeling is extended to be used in MDA, then any changes reflected in the domain knowledge can be automatically added to abstract standards and interface implementations.

These projects and subsequent discussions have resulted in the same question being asked time and time again, to paraphrase; what is the purpose/place/utility of conceptual modeling and transformation technologies and how should they be used within OGC if at all?

5.1.  Model abstraction

How far to abstract a model from an implementation to its core concepts is a balancing act between maintaining usability to complete independence from any particular implementation. From an OGC perspective, conceptual models are utilized in many of the standards both established and emerging but not all. The Sensor Observation Service (SOS) used full conceptual, logical and physical modeling to produce the standard. SOS is XML based, therefore many of the reported benefits of this approach such as producing multiple targets from one set of models are likely to be lost. Some standards have had success with full transformation into multiple target technologies; OWS Context has a model that can be transformed directly into XML or JSON, likewise, O&M and CDB also have similar approaches.

An open question within the OGC is to understand whether a conceptual model should be mandatory for a standard and if it is, what form should it take? The lowest level of burden required in a model at all would be to produce a purely conceptual model that reflects the organization of the domain with little regard to any target implementation. Indeed, these models have been specified in a number of standards, however, the utility of producing one for anything more than documentation purposes is questionable.

An alternative approach to the conceptual, logical, physical differentiation is to simplify and use the terms platform independent model (PIM) and platform specific model (PSM). This sidesteps the conflation of logical and conceptual modeling to just two sets of models:

1. abstract representations; and

2. implementable schemas.

Testbed-16 and the in-progress Testbed-17 (at the time of publication of this document) seek to utilize models for directly generating API definitions. By the nature of the requirement, the models were created at the logical level with enough information to perform a transformation to a physical model. If conceptual models are to be recommended or required for OGC Standards in the normative sense, then their utility will also have to be defined, i.e., can they be normative and are they suitable for MDA?

5.1.1.  Diagramming convention

The OMG Standard Semantics of Business Vocabulary and Business Rules (SBVR) is a method of relating models types and levels to each other via the use of UML and semantic relationships. The diagram below describes what looks like a hybrid between the concept model (note that this is different from the conceptual model and described in a later section) and the data format (sometimes called encoding in this paper) through the PIM and the PSM. In essence, it is a way of getting to the data format from the concept model through some intermediate steps. The semantic descriptions of the relationships differ from standard UML in that they are providing information that is not easily described using standard UML. This type of model structure may eventually provide the OGC with a method of separating high level concepts and encodings or data formats in a structured manner.

Figure 1 — Semantics of Business Vocabulary and Business Rules model relationships

5.2.  UML

Unified Modeling Language (UML) is often used as the standardized notation for modeling computational artifacts. It is not the only language used for this purpose, ArchiMate is quickly becoming the notation for architectures and Business Process Modeling Notation (BPMN) is used for modeling business processes.

UML class diagrams are often the notation of choice for describing objects and their relationships. Originally, class diagrams were designed for describing programs in object oriented (OO) languages. It was envisaged that variables and method stubs could be generated from class diagrams automatically. The obvious flaw with this approach is that not all languages are OO, and the transformation to each language requires a new development delta.

A similar issue occurs today when UML Class Diagrams are used to describe data structures and interfaces as these are also assumed to be OO. A salient example of this is with OpenAPI, which has a specification aimed at JSON and YAML targets, which are not inherently OO, therefore compromises have to be made in the modeling to ensure readability, usability and conformity with the specification and UML.

From a modeling perspective, UML class diagrams are usually used to create logical models, as they can contain all of the information to generate an interface. However, this begs the question as to what should be used for a conceptual model. If conceptual modeling is done using a UML Class diagram and logical modeling is done using the same notation, then is a conceptual model a logical model that omits detail? Is a conceptual model organized differently to a logical model? The example SOS model does not differentiate between a conceptual and a logical model, likely because the only encoding it supported was XML, therefore the conceptual model in this case is a blend of the concepts and the logical to create the standard. A defining decision will be whether a model is organized according to the domain it is modeling or according to the encoding or output format it is trying to represent.

5.3.  OGC Abstract Specification

The OGC Abstract Specification aims to create and document a conceptual model with sufficient detail to to aid the creation of implementation standards. The OGC Abstract Specification is comprised of a number of Topic volumes. Up until this point, this Discussion Paper has looked at conceptual modeling within the OGC in terms of the membership comments and recent initiatives. However, it should be recognized that OGC has already considered the topic of conceptual modeling formally as part of the OGC Abstract Specification. This set of documentation is lengthy, but obviously provides some insight into the vision of conceptual modeling within the OGC by providing an overview of OGC implementation standards in the form of a conceptual model.

The concept of conceptual modeling for standards is noted within the Abstract specification and makes the following points:

• Conceptual modeling addresses aspects of the standards definition, notably these include:

  • Identification of the concepts of interest;

  • Identification of the relationships between concepts;

  • The significance of a concept, its properties, and attributes; and

  • Identification of concepts from outside the standard scope.

The section also espouses the benefits of doing conceptual modeling within the OGC, however, it crucially mentions that the inclusion of a conceptual model within a standard is up to the submission team or SWG, and it is therefore not mandated. UML is also mentioned as a language that, has been used successfully by many standards developers for conceptual modeling although again, it is not mandated.

5.3.1.  Use of modeling within the OGC Abstract Specifications

The Abstract Specification makes use of UML as a modeling language within it to describe objects and relationships within class diagrams. It should be noted that the Abstract Specification contains its own diagrams, but much of the information on the Abstract Specification is held in other documents, notably from ISO / TC 211 and other OGC documents and groups such as Simple Features SWG. An example of a model within the Abstract Specification is shown below.

Figure 2 — A Taxonomy-based Instantiation in Classical Object Oriented Programming Languages

As an example, the diagram uses UML to provide the structure and other relational aspects such as qualifiers to provide context between objects.

The document Core Tiling Conceptual model contains a discussion on conceptual modeling and logical modeling that is relevant to this discussion. The paper makes the case for characteristics of conceptual models and logical models; it describes the purpose of a conceptual model to support the expression of natural language statements and therefore concept centric, however, a logical model is thing-entity-or-class-centric. This description is in contrast to the Concept Model, which is described in a future section, which is unlikely to use UML to create a suitable model, as UML does not have the semantic capability to describe the relationships between concepts.

Overall, this aspect of the Abstract model is in contrast to some of the other thinking around the OGC. In some circles, conceptual models are seen as the top level of a conceptual, logical, physical hierarchy where each level abstracts away from implementation. The PIM and PSM hierarchy doesn’t consider the conceptual aspects at all and is more concerned with implementation than describing concepts. There is also a concept model that seems to perform the same function as the conceptual model within the OGC Abstract Specification.

5.4.  CityGML 3.0 & other standards with conceptual models

This section is not intended to be an exhaustive list of standards with conceptual models, instead it is intended to present examples of OGC using conceptual models. A recent example is CityGML 3.0, which is an example of a mature practice of the OGC using conceptual models to define, express, or generate standards. The CityGML 3.0 approach to modeling is used to enable the translation of the CityGML conceptual model into multiple encodings. A key aspect of the standard is that the model is in fact, normative — where there is a conflict between the documentation and the model, the model takes precedence.

Figure 3 — CityGML 3.0 Core conceptual model

In addition to the conceptual model being the normative part of the standard, a transformation process is in place to generate the standard artifacts such as the application schemas directly from the model with no manual intervention ideally required. This is an example of producing automatically generated artifacts from a conceptual model because, as mentioned, the model can be used to create other encodings beyond XML (from the GML). This calls back to the initial discussion earlier in the document regarding PIMs and PSMs, in MDA a PIM is not necessarily independent of all standards and encodings, it has to be based upon some rules (the example given was relational databases).

Figure 4 — OWS Context Core Model

Figure 5 — Symbology Core conceptual model

6.1.  Appropriate use of MDA

There are two places in the standards definition process that MDA may be utilized.

1. Standards definition — using existing models to create a new standard with extensions made according to the requirements of the domain.

2. Implementation generation — using an existing metamodel of a standard to produce an implementation by specializing the abstract model or specification.

Creating a standard using the MDA process maybe a good use of conceptual models, but it is reliant on the conceptual modeling artifacts having already been defined. However, it would encourage an built-in governance process by requiring the use of already ratified concepts. Contrarily, MDA may not necessarily have a significant role in the standards definition process as the overhead and prior work requirement maybe deemed too high, a jump directly to implementation may suit the SWGs.

MDA should really be utilized for creation of implementations of the standard to fulfill a particular use case. In the Testbed-16 OpenAPI thread, the OGC API — Features Part 1 : Core metamodel was specialized to generate the interface definition in JSON, another transformation algorithm could be easily constructed to produce the same representation in YAML, alternatively, there is no reason why an XML representation of the interface implementation could not be constructed using the same process. This is the tried and tested method of using MDA as it has been proven recently in Testbed-16 and UGAS(2020) Pilot as well as being investigated in many prior Testbeds. At least if a PIM was defined for each standard, it would provide implementers the option of using MDA, even if it is not a requirement.

6.2.  MDA criticism

As MDA has been around for decades as a concept, a criticism of the approach is that is has not been widely adopted in that time. This is for a variety of reasons.

• Expertise in modeling is required as well as developers representing an overhead for business and a direct cost for governmental organizations.

• Models cannot be truly independent, they are based on a formalized language, usually UML (this does not imply that they are not useful). Additionally, logical models still have to have rules enforced.

• Models do not guarantee that all information required is captured formalized way due to the constraints of the modeling language and the trade-off between abstraction and pragmatism for MDA.

• The process can be more complex than simply creating an artifact from direct implementation.

Although this criticism is valid, MDA could potentially be employed in OGC in specific ways with a standardized set of tools. This approach does not require MDA to work in all cases for all models into all encodings, just the subset of each required by the OGC. The criticism leveled at MDA is valid, especially if an idealistic approach is adopted where models created are done so with the explicit function of being used in the MDA process. This is unlikely to be a requirement for a conceptual model, however, standards groups should be aware of the process and ascertain its utility. As mentioned in the previous section, providing a normative conceptual model along with the standard would at least provide implementers the option of MDA.

6.3.  Management of concepts

An aspect that is missing from UML modeling, MDA and tooling in general seems to be an overall agreement on concepts. The current UML models are missing peripheral materials that are probably best held in a different format, for example, a data dictionary or business glossary for terms building on the existing OGC Glossary of Terms (http://www.opengis.net/def/glossary). If such a repository existed, it would assist in the semantic harmonization of concepts across the OGC — it would be like an OWS/OGC API Common but for terms that are agreed upon. This type of model would provide UML models with semantic meaning, rather than just describing the relationships in terms of its multiplicity, for example.

A comparison of concept models and conceptual models is presented in a paper by Ross [Bibliography]. The paper highlights some of the confusion regarding semantic descriptions of concepts and the way that the term conceptual model is used. Concept models are concerned with semantics and capture of meaning, whereas conceptual models are concerned with engineering and relationships. A table summarizing the comparison is presented below. The original table can be found here.

Table 1

Although concept modeling is outside of the scope of this paper, which is focused on data and interface modeling, it is an important topic that should be explored further as part of the Architecture DWG or other relevant group. Perhaps this type of concept modeling could be used as a companion to the conceptual model, or in some cases, it may be sensible to replace the conceptual model with a concept model depending on the value added.

8.1.  The terms conceptual model and logical model should be well-defined and used in an appropriate way

OGC has previously conflated the terms logical and conceptual when describing models. If these terms are disentangled and well-defined then the appropriate model type can be used in the standards definition process. This will in turn help users to decide whether the modeling process would add value to the resultant standard. Coupled with this distinction, Platform Independent Models (PIMs) and Platform Specific Models (PSMs) should be used specifically in reference to the MDA process. Although PIM loosely translates to logical model and PSM loosely translates to physical model, the terms should not be used interchangeably.

8.2.  Conceptual models should be recommended standards where they add value

Recommending the creation of conceptual models for new standards going forward would start to enable the harmonization of models and standards across the OGC. Conceptual models should not be mandatory as OGC standards contain rules for implementation, and a model is not required for this to be a success. Models, however, do add value in certain circumstances. For example, if the model is entwined with the MDA process then it can be specialized to create implementations or used as a baseline to extend specifications for different domain requirements.

8.3.  Conceptual models should be UML class diagrams when describing objects, relationships and structure

Although an older standard, UML is still the baseline for data models, it is also coupled tightly with the MDA process which should at least be an aspiration for standards developers in OGC. Although UML is OO, it has been shown through Testbed initiatives that UML can be used to represent models that are not OO provided all of the information for a standard or implementation can be captured. In addition to providing modeling artifacts that are machine readable, UML also provides a standardized graphical interface that is well understood.

Concepts are difficult for UML models to describe as they lack the semantic depth of some other modeling languages. The OGC Abstract Specification (specifically OGC Core Tiling Concept) describes the Conceptual Model (opposed to a logical or physical model) as being the place where concepts and semantics are captured before being specialized into logical models for transformation into physical model (automated or manually). In contrast to this the use of concept model as being the place where concepts including their semantics are captured. This will need to be resolved, possibly by introducing another modeling paradigm to manage concepts and semantics.

8.4.  MDA should be used where appropriate, or at least be an option for implementers

MDA is useful, especially when a base model can be used to derive many encodings. It also allows standards to broaden their encoding base through implementation of new transformations. A harmonized, model-driven approach should remove some of the complexity from the process that was discussed in the criticisms of the process. Even if MDA is not recommended by the OGC in the formal sense, having a set of standardized, domain led conceptual models provides standards implementers with MDA as an option.

8.5.  MDA is useful for new standards as well as new implementations

Taking a model driven approach to creating new standards may be helped with the use of modeling OGC API — Common components, if suitable. This enables designers and implementers to achieve conformance with the common requirements easily as they could exist as predefined artifacts. It is recognized, however, that new artifacts would have to be modeled to create new standards.

Perhaps the real power of MDA is best exploited when creating new implementations of standards to fit a particular domain. The modeling artifacts for a standard should already exist as part of the standards definition process (although perhaps in the abstract), therefore, these artifacts could be specialized to generate the model for an implementation of the standard to fit a particular domain.

8.6.  A new Conceptual modeling group should be setup to support the Standard and Domain Working Groups

Conceptual modeling with or without the use of MDA is a value adding exercise to any standards definition process and should be encouraged throughout the OGC in groups with existing standards and those yet to be ratified. It may also be advantageous to utilize MDA to produce implementations and even new standards, this, however requires work on OGC API — Common and agreement on a methodology to enable this. Although the modeling is a useful exercise, it requires people with expertise in UML modeling and potentially MDA. These experts likely already exist within the OGC, however they currently operate primarily within the existing working groups. A new working group should be setup to house these experts and provide support to the other DWGs and SWGs. This group would also have a bird’s-eye view of all of the modeling work across the OGC and could help rationalize and standardize relevant concepts, models, and processes.

The OGC Abstract Specification should be the first point of call for developing new standards, however, it currently says very little about the use of conceptual modeling, and how this differs from concept modeling for example. The OGC Abstract Specification should be updated to provide more comprehensive guidance on the use of conceptual modeling within the standards definition and implementation processes.