Metadata profiles OWS-8 CCI Schema Automation Engineering Report

6 Copyright © 2011 Open Geospatial Consortium Treat code lists as subtypes of CharacterString that limit the valid string values; i.e. explicitly allow constraints like attribute value and attribute.oclIsTypeOfMyCodeList Since code list values are more like enumerants than free strings, it was decided to follow the first of the two approaches in these encoding rule extensions. The intended comparison operation attributeCodeList::value is a particularly problematic case, because equality operators such as “” and “=” in OCL are permitted between any objects of any type. The data types of the two comparands being complete unrelated CharacterString vs. MyCodeList the semantics of OCL would imply that the compared objects are different and the inequality operation “” of above expression would result in the constant true. Not surprisingly, implementing a far-reaching exception to the rules in the ShapeChange OCL system turned out to be difficult and dissatisfying. When the code generator translates a token such as the “attribute” operand, is usually does not know about the requirement that this in this special case is meant to be translated as if it were a code list of type CodeList. In order to avoid deterioration of comprehensibility and clarity of the ShapeChange code is was decided to confine the rule conflict to the OCL type detection and type casting operations by requesting that in such comparisons as above an explicit type cast “oclAsTypeCodeList” has to be applied to the CharacterString operand. The comparison operation must therefore be written as follows: attribute.oclAsTypeCodeListCodeList::value Note that this solution is still invalid according to the strict rules of UMLOCL. The type cast operation above is supposed to deliver a result value of “null”, because the types are unrelated. The same is, of course, true for constructs employing “oclIsTypeOf...”. XML encoding considerations: In “pure restriction” case the subtype is just a container for the constraints and in general it is not intended to create a new object element for the subtype in the XML representation. I.e, the representation in Figure 1 of the blue MD_Class in XML Schema is strictly not necessary as the Schematron rules encoding the restriction can capture all aspects of the classifier. However, in some cases it may be desirable to represent classes that do not add new properties in the XML Schema, too. An example might be that a community wants to express explicitly through the namespace of the metadata element that this is according to the profile associated with the namespace. I.e., we need a mechanism to control the behavior of the conversion. Following the guidance Copyright © 2011 Open Geospatial Consortium 7 for encoding rule extensions planned for inclusion into GML 3.3, a tagged value is used for this: A tagged value suppress with a value of true attached to such pure restriction subtypes indicates that in the XML Schema no element, type and property type is to be created for this classifier. Note that the use of this tagged value is only valid, if the classifier has a direct or indirect, non-abstract supertype without this tagged value set to true, and no subtype without this tagged value set to true. The meaning is that such a classifier does not appear in the XML Schema output suppress and that any constraints defined for that classifier are being attached to the supertype. Concerning the translation of OCL constraints to Schematron, the constraints found in a suppressed class are translated and then attached to its direct or indirect supertype, which is not suppressed. In this way you can import constraints into parts of the schema, which you otherwise cannot alter such as ISO 19115 objects encoded by means of ISOTS 19139. There are two subtly different ways of thinking how the intended transfer of restrictions contained in a suppressed class to its superclass is supposed to work. 1. In a strict UML sense, the restricting constraints dwell in the suppressed class and only apply to instances of this class. In the mapping to XML schema the suppressed class is mapped to its superclass, which means that the XML instances of the superclass and only these are subject to the defined restrictions. 2. Another way of thinking is that the suppressed class is just a trick, a Trojan vehicle, to inject constraints into a class, which is otherwise unavailable to such an operation. In this case the constraints would be treated as if they were in reality specified in the superclass, which, of course, means that the “injected” constraints also apply to derivations of that superclass. Since no decision about the intended behavior had been reached in the project both ways were implemented and made controllable via a ShapeChange configuration option. See section 6.4.1 for this. Note that there are still some more unsettled questions beyond the strict-UML vs. Trojan interpretation concerning “suppress”. What is the intended behavior, when the name of the suppressed class is used in OCL expressions? This can happen anywhere in the model, for example in a type constant used in oclIsTypeOf… or oclIsKindOf… or ….allInstances. Is this being treated as if it were the superclass? Or should the strict UML rules apply? Lacking answers to these questions, the current implementation just rejects class constants of suppressed classes in OCL expressions and emits appropriate error messages. 8 Copyright © 2011 Open Geospatial Consortium Pure extensions In this case the subtype which again may have the same local name as the supertype, but in the package of the profile schema represents an intent to revise the behavior of the supertype purely by additional properties. New attributes, roles, and classifiers representing domains of new properties are added. Inherited properties are used “as is” without any constraints on them. Figure 2 - Pure extension case Combinations of restrictions and extensions This case represents a combination of the previous two cases. Additional properties are added to the subtype in the profile as well as constraints. Figure 3 – Combined case To enable a consistent encoding in XML, the encoding rule of the subtype and its sub- elements as specified in the tagged value xsdEncodingRule shall be the same as in the supertype. This applies to all types in an application schema. MD_Class from Metadata – Identification Information DQ_Class from Metadata – Data Quality 0.. quality All attributes All attributes AnotherClass 0.. friendly Attributes MD_Class New attributes friender 1. MD_Class from Metadata – Identification Information OCL: •  restricting multiplicities •  restricting domains DQ_Class from Metadata – Data Quality 0.. quality All attributes All attributes AnotherClass 0.. friendly Attributes MD_Class New attributes friender 1. codeList MyCodeList Attributes Copyright © 2011 Open Geospatial Consortium 9

6.2 UML profile extensions for code lists and units of measurements

In order to enable constraints on code list values and units of measurements that cannot be properly encoded using OCL, additional tagged values are specified for these cases. The tagged values are specified in the following tables. Table 1 – Tagged values for code list value constraints Stereotype Model element Tagged Value Description codeList classifier codeList Base URI of the code list codeListValuePattern Value access pattern for the code list, containing the substitution points {codeList} and {value}, where {codeList} is the base URI of the code list replaced by the tagged value codeList and {value} the local identifier of the code list value. Default: {codeList}{value} codeListRepresentation MIME type indicating the code list representation Valid values are: applicationgml+xml;version=3.2 for a GML dictionary as currently used in the MDR applicationrdf+xml for a SKOS concept scheme as created as part of the LTDS RDF representation Default: applicationgml+xml;version=3.2 10 Copyright © 2011 Open Geospatial Consortium Table 2 – Tagged values for unit of measure value constraints Stereotype Model element Tagged Value Description schema or application Schema Package uomResourceURI Base URI of the units dictionary Example: http:metadata.ces.milmdrnsGSIPuom uomResourceValuePattern Access pattern for the unit, containing the following substitution points: {resource}: The base URI of the units dictionary, to be replaced by the tagged value uomResourceURI from the schema. {quantity}: The quantity type of the unit, to be replaced with the value of the tagged value physicalQuantity or the value ‘noncomparable’ from the property. {uom}: The local identifier of the unit in the units dictionary, to be replaced with the value of the tagged value recommendedMeasure or noncomparableMeasure from the property, or a valid value from the resource that represents the physicalQuantity. Default: {resource}{quantity}{uom}. uomResourceRepresentation MIME type indicating the units dictionary representation Currently, only one value is specified: applicationgml+xml;version=3.2 for a GML dictionary as currently used in the MDR Default: applicationgml+xml;version=3.2 - attribute physicalQuantity Physical quantity of the referenced unit Example: length recommendedMeasure Unit recommended for use with this property. The unit must be consistent with the physicalQuantity value. Example: metre noncomparableMeasure Valid non-comparable unit. Example: flightLevel