UGAS-2019

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

For this deliverable, the Pilot was tasked to analyze how property stereotypes can be used within an application schema to indicate that the property can be associated with a (specific type of) metadata.

As part of this analysis, the implications of using such stereotypes within an application schema – with the NSG Application Schema (NAS) being the primary use case – were to be considered. Once the concept of property stereotypes for metadata association has been established, the goal then was to extend ShapeChange and the ShapeChange XML (SCXML) format as necessary to support it.

The concept of using a property stereotype for associating metadata with property values has been developed through a series of web meetings and email conversations. A separate document captures the results of these discussions in detail. The results of this work were presented within the OGC Architecture DWG at the OGC TC meeting in Toulouse, in November 2019.

The concept is realized via the new property stereotype <>. When added to a property (an attribute or association role) within an application schema, it signifies that metadata can be associated with the values of the property. By assigning tagged value “metadataType” to the property, the exact type of that metadata can be defined by the modeling expert – per property. Doing so supports use cases in which different kinds of metadata are required for different properties, for example attributes and association roles, or properties with a simple and a complex value type.

The new property stereotype can significantly reduce the complexity of an application schema, which used the standard modeling constructs defined by ISO 19103 and ISO 19109 to model property value types with metadata. The NAS is a good example of such an application schema. Currently, the NAS uses Meta- and Reason-classes to model that a property has a set of values or a reason why no value exists, and also metadata for the property value – see Figure 1.

With the new property stereotype <> – as well as the property stereotype <>, to indicate that a property can be null, with a defined reason – the Meta- and Reason-classes are no longer needed.

The model can be revised/simplified to the one shown in Figure 2.

The resulting model design pattern is much easier to understand and then consistently implement and maintain.

The effect of employing the pair of property stereotypes also applies to implementation schemas, such as XML and JSON schemas.

These schemas become simpler to implement, easier to understand, and more readily employed in application software.

Additional benefits of replacing the Meta- and Reason-classes with property stereotypes are:

Work on D100 also included the design of an OCL language extension. The new operation call propertyMetadata() provides programmatic access to the metadata object that is associated with the value of a property with stereotype <>. That means that a modeling expert can explicitly model conditions that involve the metadata that is associated with property values. An example would be that the value of a geometric property must be associated with metadata that provides information on the positional accuracy.

Multiple encodings of stereotype <> were considered during the analysis in D100. The primary focus was on the XML encoding, for which a number of options were considered. The recommended option provides a simple and straightforward solution for encoding the relationship between a property value and a metadata object in XML. That option was implemented in D101 – see chapter Conversion of property stereotype for metadata in the ShapeChange XML Schema target – D101.

Even though not explicitly required for UGAS-2019, the analysis of encodings of stereotype <> encompassed JSON, SQL, GML Simple Features, and Linked Data encodings. The results of D100 provide suggestions on how <> can be realized in these encodings. Since implementation and testing of these suggestions were not in scope of the UGAS-2019 Pilot, such work will need to be conducted in future activities.

Summarizing the key results of D100:

Once the concept of a property stereotype for metadata had been developed in D100, suitable rule(s) were to be developed, to convert stereotype <> in the XML Schema encoding of an application schema, with the NSG Application Schema (NAS) being the primary use case. The resulting XML Schema should be equivalent, but possibly not identical, to the current NAS XML Schema encoding. The conversion process should take into account property-specific OCL constraints, as well as preceding model transformations.

ShapeChange was enhanced as follows:

These enhancements fully support the concept of stereotype <> in the XML encoding. They ensure XML data checks and expressiveness equivalent to the current NAS XML Schema.

OGC Testbed-14: Application Schema-based Ontology Development Engineering Report (OGC 18-032) documents recommendations for writing OCL constraints that are intended to be translated to OWL expressions. A major aspect of those recommendations is to significantly increase the use of quantifications (exists(..) and forAll(..)) in OCL expressions. These quantifications are readily supported by OWL, however extensive use of such quantifications can be an issue for the translation to Schematron based on XSLT1 – which is what the OCL to Schematron conversion of ShapeChange currently supports.

The reason is that Schematron with the XSLT1 query binding does not directly support quantifications. More specifically: XPath 1.0, which is used by XSLT1 and thus also used to define Schematron assertions, does not support them. The conversion by ShapeChange represents quantifications through equivalent XPath expressions. Especially the representation of forAll(..) can quickly lead to highly complex and potentially inefficient XPath expressions; a chain of forAll(..) statements would result in a deeply nested tree of count expressions. The situation could significantly improve if XSLT2 was used as Schematron query binding, since XPath 2.0 directly supports quantified expressions.

The goal of D102 therefore was to enhance the current OCL constraint to Schematron assertion conversion capability of ShapeChange to perform the conversion to Schematron based on XSLT2 instead of XSLT1.

The ShapeChange conversion of OCL constraints to Schematron has been revised. Full use of the XSLT2 query binding now not only allows a straightforward representation of quantifications, but also fully enables evaluation of property values given by reference (given that all objects are encoded within the same XML document, such as a feature collection). When evaluating such references, the Schematron code makes use of XSLT2 keys, which significantly improve the performance of such lookups. Other OCL language constructs can now be translated in a more natural and direct way, too, such as if-then-else-endif and the pattern matching function.

NAS OCL constraints can now be revised to use quantifications, as suggested in the OGC Testbed-14 engineering report. The revised constraints will be easier to translate to OWL expressions. With the new Schematron translation process, the revised constraints can also be translated to efficient Schematron assertions, which can be used for validating NAS data encoded in XML.

Overall, the revision of the Schematron translation, making full use of the language features of the XSLT2 query binding, resulted in a significant improvement of the resulting Schematron: the Schematron assertions are easier to understand, make use of XSLT2 language features to achieve faster execution, and new capabilities (e.g., value pattern matching) useful for the NAS are supported. The implementation of expressive and efficient Schematron assertions enables broader application of data content validation mechanisms with NAS-based XML instance documents, thus resulting in higher levels of data integrity and reduced content errors.

Testbed-14 included a requirement for the pilot to “Extend ShapeChange to support transformation of NAS OCL Constraints into OWL, SHACL and/or SWRL (or other ontology rule language) encodings to be used with NEO.” The results from this effort are documented in Section 5 of the OGC Testbed-14 Application Schema-based Ontology Development Engineering Report (OGC 18-032). The pilot found that conversion of OCL to OWL is not as simple a process as had been originally anticipated. Rather, each OCL construct must be individually analyzed and the rules for its proper translation derived. OGC 18-032 describes the translation rules for twenty- one (21) OCL constructs used in the NAS. It also identifies seven (7) OCL constructs for which translation is not possible and an explanation of why. Due to the unanticipated complexity of this effort, not all fifty-four (54) OCL constructs used by the NAS could be evaluated.

The goal of D103 within the UGAS-2019 Pilot was to complete the analysis of the translation of the remaining 26 types of OCL constraint to OWL class expressions.

Translations for the remaining types of OCL constraints were developed. Annex B of the OGC Testbed-14 Application Schema-based Ontology Development Engineering Report has been revised accordingly.

Completion of this analysis enables enhancement of the NSG Enterprise Ontology (NEO) to achieve increased expressivity in knowledge representation and the ability to implement data integrity checks in a linked-data environment.

Loading content from an SCXML document into ShapeChange ignored most input configuration parameters and elements.

A task for the UGAS-2019 Pilot therefore was to enhance ShapeChange such that loading from SCXML supports the “standard” input configuration parameters and elements; for example, input parameters such as “checkingConstraints” should be honored.

The analysis conducted for D104 discovered a number of shortcomings of ShapeChange when loading a model from SCXML:

All these shortcomings have been fixed. The same model loading behavior now applies to models encoded in SCXML and in other formats, such as an Enterprise Architect repository. SCXML therefore has become a true alternative model encoding.

In addition, the following ShapeChange enhancements not explicitly required for the UGAS-2019 Pilot, but discussed within the project and deemed important and useful for the wider community, have been implemented:

SCXML serves as the representation of the NSG Application Schema (NAS) through all stages of ShapeChange-based transformation. It is essential that this representation is complete and that no information is lost during ShapeChange-based transformation. The prototypical use-case is the generation of Enterprise Architect model files based on either the full NSG Application Schema (NAS) or a subset of the NAS.

The NAS is an unusually large application schema that is designed to be technology-neutral. ShapeChange is used to prepare mission-specific subsets of the NAS as well as to transform the NAS model into related models that satisfy technology-specific requirements and constraints. Accomplishing these objectives either singularly or in combination typically requires multiple processing steps that may be separated, or check pointed, by storage of the work-in-progress model using SCXML.

The goal for D104 was to investigate the use of SCXML for the lossless representation of the NSG Application Schema (NAS) at all stages of ShapeChange-based transformation (e.g., after application of the Profiler). Where shortfalls were identified, the pilot should enhance the SCXML schema and/or SCXML-related processing.

The SCXML schema as well as ShapeChange have been revised and enhanced in a number of ways:

The revised SCXML schema supports lossless exchange of the NAS model. ShapeChange has been updated to read and write UML models from/to SCXML according to the new SCXML schema.

Another achievement of D105 is that the set of tagged values well-known to ShapeChange has been revised and the documentation on https://shapechange.net/app-schemas/uml-profile/#Tagged_Values has been brought up to date. The updated documentation will help ShapeChange users, including those employing the NAS, in better understanding and correctly applying the numerous tagged values that can be used within ShapeChange processes.

In the Profile Management Tool (PMT), if a UML association class is removed from the application schema profile, the corresponding association (and roles) should be removed as well. Similar considerations apply when adding an association class. Association class management by the PMT shall be a superset of the logical union of the capabilities for management of UML classes and UML associations.

The pilot shall enhance the PMT to address each of these concerns regarding support for association classes.

The Profile Management Tool has been updated to handle association classes as required. The PMT is now suited for defining profiles of application schemas such as the NAS that use association classes.

The Profile Management Tool (PMT) – and ShapeChange – should support additional profile parameters that were first described in the OGC Testbed-12 ShapeChange Engineering Report: isAbstract, isOrdered, and isUnique.

The PMT and ShapeChange have been enhanced to support the additional profile parameters.

In addition, the PMT has been updated to support the new SCXML schema. For example, the PMT displays ownership of association roles. Furthermore, the following enhancements not explicitly required for UGAS-2019, but discussed within the project and deemed important and useful for the wider community, have been realized:

These four enhancements improve the ability for the PMT to be used by NAS Subject Matter Experts to define NAS subsets to meet their mission-specific requirem