Issues for Mailing list of the Ontology Definition Metamodel (ODM) 1.1 Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 13074: Section: 10.2.2
Issue 13075: Section: 10.9.3
Issue 13937: Section: Appendix A, Section A.3
Issue 13938: NamespaceDefinition is defined as a metaclass, without a stereotype
Issue 13940: Section: 14.2.8.1
Issue 13977: rdfsDomain/Range should be based on dependency.
Issue 13978: Section: UML Profile for OWL and RDF
Issue 13979: Figure 14.10 missing property subsetting
Issue 13980: owlValue and allValuesFrom
Issue 13981: Figure 14.19 is property subsetting
Issue 13982: owlValue and allValuesFrom 2
Issue 13983: RDFGlobalProperty shouldn't apply to classes
Issue 13984: rdfsDomain/Range should be based on dependency 2
Issue 13985: rdfsDomain/Range should be based on dependency 3
Issue 13986: RDFProperty, RDFObjectProperty, and RDFDatatypeProperty shouldn't apply to classes
Issue 14425: rdfs:Literal
Issue 16030: The PrimitiveTypes in the metamodel XMI file are instances of Class not PrimitiveType
Issue 16031: In the OWL metamodel the Restriction Cardinality elements should own their TypedLiteral
Issue 16032: multiple inheritance for MOF shown in Figure F.4
Issue 16033: It would be preferable for isDeprecated to be non-optional with a default value of false.
Issue 16034: OWLClass::isClassKind:OCLClassKind breaks convention that ‘is’ at the start of properties is used to indicate Booleans
Issue 16035: In Annex F the use of OWLClass::/isClassKind: and OWLClass::/hasRestrictionKind is not sufficient
Issue 16036: In the CL metamodel the associations Conjunction and Disjunction clash with class names.
Issue 16037: I propose that the following properties are owned by the Association
Issue 16038: derived Association OWLBase::/TripleForGraph
Issue 16039: There is a general lack of composition relationships for model management – in both the RDF and OWL metamodels
Issue 16040: Spec is sorely in need of examples showing how to represent common RDF/OWL constructs as instances of metamodel
Issue 16256: Users creating domain ontologies want their models to be user friendly
Issue 16495: ODM does not support internationalized URIs
Issue 16496: ODM should support recent W3C definitions for plain literals
Issue 16497: Stereotypes should be shown on diagrams in the RDF and OWL profiles
Issue 16498: ODM does not support XML Schema Datatype facets, which were added in OWL 2
Issue 16499: Label and URI properties are duplicated on many elements in the RDF and OWL profiles
Issue 16500: Datatype definitions should be mapped to UML primitives
Issue 16501: Typed literal definitions should be mapped to their defining datatypes
Issue 16502: Need a stereotype to visually link individuals to their classifiers
Issue 16503: Need a stereotype to link local extended defs to the definitions they reference in imported vocabularies
Issue 16504: Need to augment stereotyped literal strings with InstanceSpecification metaclass
Issue 17338: ODM Metamodel takes a different approach to OWL restrictions from the Profile (and indeed from OWL):
Issue 17424: Provide support for distinguishing asserted vs. inferred axioms
Issue 18833: Move Chapter 16 to an Informative Annex
Issue 18834: Annex F has been superceded by SMOF
Issue 18835: Revise the ODM to support UML/MOF 2.4.1
Issue 18836: Annex D has a number of issues and should be removed

Issue 13074: Section: 10.2.2 (odm-rtf)

In the fifth line of the OCL expression the specification says: ...self.oclIsTypeOf(RDFSLiteral)... I think it should be: self.oclIsKindOf(RDFSLiteral), otherwise there will be constraint errors if you for example create an instance of PlainLiteral. In the seventh line of the very same OCL expression the specification says: ...self.isTypeOf(RDFSLiteral)... I think it should be: self.oclIsTypeOf(RDFSLiteral) In the second and third line calls to the notEmpty method are made. However, "()" is missing. The same applies to OCL expressions on page 41 and 49!

In section 10.9.3 the specification uses the association name NamespaceForNamespaceDefinition. However, Figure 10.9 uses the name NamespaceDefinitionForNamespace. In addition I noticed that not all figures are vector images (some are). With respect to copying and pasting it would be nice if all images were vector images (example: Figure 10.2 in contrast to Figure 10.3)

The set of XML Schema Datatypes defined for use with the UML profiles for RDF and OWL currently have a base class and stereotype of UML::LiteralString, <<typedLiteral>>. These elements actually represent classes of datatypes, and for use with the profile should be classified by UML::DataType, with a stereotype of <<rdfsDatatype>>.

NamespaceDefinition is defined as a metaclass, without a stereotype, in the UML profile for RDF, which is not allowed in UML 2. The definition requires revision to include a stereotype.

Currently, the specification of owl:DataRange uses a UML::Enumeration, which requires all of the data values that make up the enumeration to be enumeration literals. In all other places in the profile, literal strings are used to represent literals, yet one cannot use literal strings to build up data ranges given the current definition (i.e. something that is a literal string cannot also be an enumeration literal). 

rdfsDomain/Range should be based on dependency. These figures use associations as if they were links: Figure 14.6: Property hasColor Without Specified Domain, Class Notation Figure 14.8: Property hasColor With Specified Domain and Range, Class Notation Figure 14.12: Property Subsetting - Class Notation Figure 14.14: rdfsRange Stereotype Notation - Class Notation for RDF Property Figure 14.23: owl:Cardinality - Restricted Multiplicity in Subtype Figure 14.13 «rdfsDomain» Stereotype Notation - Class Notation for RDF Property Figure 14.27: Property Redefinition for owl:allValuesFrom Using Classes Figure 14.28: Property Redefinition for owl:hasValue Using Classes Maybe others (any showing rdfsDomain/Range are probably incorrect) These should be changed to dependencies, per the discussion in Santa Clara, and the definition of RDFSDomain and RDFSRange stereotypes changed accordingly. 

owlValue stereotype missing UML compartment notation. The draft going into FTF ptc/06-10-11) showed the UML notation for owlValue using an attribute compartment on a class, but the current draft doesn't. It only refers to the allValuesFrom notation, which also doesn't show the compartment notation. The text and figure for owlValue in ptc/06-10-11 should be included again. 

Figure 14.10 missing property subsetting. Figure 14.10 (Property Subsetting, Unidirectional Association) should have {subsets follows} under the chases end label.

owlValue and allValuesFrom. The stereotype owlValue has property allValuesFrom, but the rest of the section, including the title, only describes someValuesFrom and owl:hasValue. Why is the allValuesFrom property needed on owlValue? 

Figure 14.19 is property subsetting. Figure 14.19 (Figure 14.19 - Property Redefinition For owl:allValuesFrom With Association Classes) is property subsetting rather than redefinition. The lower association should be hasBrightColor, rather than has hasColor, with {subsets Hascolor}. It should be moved to the section on rdfsSubpropertyOf, it's not an example of allValuesFrom. 

owlValue and allValuesFrom 2. The paragraph under Figure 14.19 (Figure 14.19 - Property Redefinition For owl:allValuesFrom With Association Classes) says the owlValue stereotype may be applied to an association, but the base class of owlValue is Property. It also says the multiplicity of the allValueFrom property can be set by the modeler, but it can't, the multiplicity is defined in the standard. 

RDFGlobalProperty shouldn't apply to classes. RDFGlobalProperty has Class has a base type, but classes aren't properties. This is inconsistent with the rest of the description of RDFGlobalProperty. 

rdfsDomain/Range should be based on dependency 2. When rdfsDomain/Range are changed to be based on dependencies, see previous issue, Figure 14.23 (owl:Cardinality - Restricted Multiplicity in Subtype) will no longer work. Dependencies cannot have multiplicities or be redefined. This figure should be removed

rdfsDomain/Range should be based on dependency 3. The comment in the previous issue also applies to Figure 14.27 (Property Redefinition for owl:allValuesFrom Using Classes), and the sentence under Figure 14.6 (Property hasColor Without Specified Domain, Class Notation).

RDFProperty, RDFObjectProperty, and RDFDatatypeProperty shouldn't apply to classes. RDFProperty has Class has a base type, but classes aren't properties. This affects Figure 14.2 (Property hasColor - Class Notation Without Specified Domain or Range) where a class (that is not an association) is used as a property, and the sentence above Figure 14.8 (Property (hasColor With Specified Domain and Range, Class Notation). 

Need capability to say that the type of a property, when specified without an explicit domain or range, an alternative to an anonymous class might be rdfs:Literal
The statement is made that the profile uses an anonymous class, analagous to owl:Thing ..., which is only appropriate if the user intends the property to be an object property in OWL.  For completeness, include rdfs:Literal to support datatype properties as well.

The PrimitiveTypes in the metamodel XMI file are instances of Class not PrimitiveType

In the OWL metamodel the Restriction Cardinality elements should own their TypedLiteral (i.e. the associations Cardinality, MaxCardinality, MinCardinality should be composite)

The multiple inheritance for MOF shown in Figure F.4 results in PropertyOWLClass and IndividualPropertyOWLClass having 2 distinct properties called isDeprecated inherited from OWLClass and OWLProperty – which is an error in MOF (and UML). Either they should be redefined in the subclasses or one of the original properties renamed – depending on whether the same element can be separately deprecated as a property and as a Class).

It would be preferable for isDeprecated to be non-optional with a default value of false. Likewise the Booleans added in Annex F such as isSymmetric

The property OWLClass::isClassKind:OCLClassKind (introduced in Annex F) breaks the convention that ‘is’ at the start of properties is used to indicate Booleans. The name ‘classKind’ or ‘hasClassKind’ (for consistency with ‘hasRestrictionKind’ would be more appropriate

 In Annex F the use of  OWLClass::/isClassKind: and OWLClass::/hasRestrictionKind is not sufficient to avoid the need for large numbers of multiply-inherited classes e.g. IndividualOWLIntersectionClass since isClassKind does not capture the specific properties of the subclass e.g. OWLintersectionOf. Furthermore isClassKind should not be derived (in the same way isSymmetric should not be derived). To avoid the large number of multiple-inherited class a generic association OWLClass::relatedClass[0..*] would need to be added – which would stand in for OWLintersectionOf, OWLunionOf, OWLcomplementOf depending on the value of isClassKind. And another association to Individual for OWLoneOf. And it gets still messier to try to capture all the relationships of OWLRestriction. However the larger question is whether all this multiple inheritance is needed : since, as I understand it, all these subclasses of OWLClass will only be instantiated by anonymous classes, and it does not make sense that anonymous classes could also be reified as Individuals/Properties.

 In the CL metamodel the associations Conjunction and Disjunction clash with class names. This is not strictly speaking an error at MOF 2 but can cause difficulty for some implementations. And these do not make good associations names. I propose: ConjoinedSentence and DisjoinedSentence (which will make them consistent with NegatedSentence).

There is a mutual dependency between RDFWeb and RDFBase since, for example, RDFBase::URIReference owns a Property owningNamespace typed by RDFWeb::Namespace. I propose that the following properties are owned by the Association:

-          URIReference ::namespace

-          URIReference ::fragmentIdentifier

-          Triple::document

-          Triple::ontology

 It’s unclear how derived Association OWLBase::/TripleForGraph is supposed to interact/be merged with underived RDFBase::TripleForGraph. There seems no need for a derived OWLGraph::/triple when OWLGraph inherits triple from RDFGraph. Or is it the intent that OWLGraph::triple {redefines RDFGraph::triple} – in which case that should be stated along with how it would be derived: via OWLGraph::ontology and Ontology::triple? And is it the intent that Triple has both a derived /owlGraph and a (non-derived) graph property? In which case the former should {subset} the latter and the derivation should be expressed.

There is a general lack of composition relationships for model management – in both the RDF and OWL metamodels

 The specification is sorely in need of examples showing how to represent common RDF/OWL constructs as instances of the metamodel. That’s especially the case for use of URIs and IDs; and also for anonymous classes as used in Restrictions and Intersections

.

Users creating domain ontologies want their models to be user friendly and this requires phrases with spaces and other special characters.  The use of “camel case” and other I.T. conventions are not friendly, however OWL has restrictions on the characters that may be used.  

 

Potential resolution: ODM should specify the algorithm for mapping a user friendly names in the UML profile to an OWL legal name where required.  The user friendly name can and should be used in the OWL label and does not require such mapping.  The choice of algorithm can be to eliminate the space and enforce camel case or to substitute underscores for all illegal characters.  My preference would be to introduce underscores as these are then easier to reverse map from OWL to UML and are visually similar to spaces.

Revise the RDF metamodel and profile to reflect modifications to the W3C standards to use internationalized URIs (IRIs).

Formalize the definition of RDF plain literals in the RDF metamodel and profile to reflect recent W3C specification revisions.

Stereotypes should be shown on diagrams in an abstract syntax section under each profile, not only in text under each stereotype.

Include definitions for xsd facets on datatypes for datatype restriction and user-defined datatype development in the XML Schema Datatype library, for OWL metamodel and profile.

Need better integration of the notions of labeled and named resources in the RDF profile: RDF resources may have multiple "PlainLiteral" labels in their RDFSlabel property, and multiple "PlainLiteral" comments in their RDFScomment property (where a plain literal includes a value string and language definition encoding).  The same issue is prevalent in the OWL profile.  These label and URI elements should reuse the same UML properties rather than proliferate duplicates.

Need to be able to map xsd datatypes to UML primitive types in the RDF profile to facilitate tool support for value specification.

Need to link typed literals to their defining datatypes in the RDF profile and library, not just to the URI for the external xsd definition.

Need an additional stereotype in the RDF profile to link individuals to their classifiers (<<rdfType>>) to aid in diagramatic / visual explanation of individual definitions in cases where they have numerous classifiers.

Need an additional stereotype in the RDF profile to link local augmentations to vocabulary definitions to the definitions that are specified in imported or referenced vocabularies, (<<rdfAbout>> - e.g., in cases where properties are added to imported classes, which would entail modification of the imported model in a UML project, which is typically prohibited).

Literal Strings are not well defined in UML, and tools do not support them well.  In order to be able to use stereotyped literal strings for elements such as URIs, labels, comments, and so forth, the stereotype definitions must include InstanceSpecification as a metaclass in addition to LiteralString in order to get expected behavior from mainstream UML tools.

The ODM Metamodel takes a different approach to OWL restrictions from the Profile (and indeed from OWL): the Profile has a single stereotype Restriction whereas the Metamodel has 6 different subclasses depending on the type of restriction: HasValueRestriction, AllValuesFromRestriction, CardinalityRestriction etc. It would be more consistent if the metamodel had only a single class, though this would necessitate constraints on the properties.

Currently, the ODM 1.0 specification defines several stereotypes for representing an OWL ontology in UML using the ODM stereotypes for RDF and OWL.


The ODM spec is understandably updated to support OWL2, the current recommendation from the W3C.
It is not entirely clear which OWL2 constructs are supported in the ODM profile — a cross-reference table linking the entries of the quick ref. guide would be particularly helpful: http://www.w3.org/TR/owl2-quick-reference/


Also, in practice, it would be useful to have the flexibility of showing come axioms but not others.
For example, if we have (in functional syntax):


Declaration( Class( A ))
Declaration( Class( B ))
Declaration( Class( C )) 
SubCassOf( A B )
SubCassOf( B C ) 


Then, an OWL2 reasoner will infer the following axiom:


SubCassOf( A C )


Using the ODM profile, it should be possible to show selected subsets of an ontology.
For example:


view1:


Declaration( Class( A ))
Declaration( Class( B ))
Declaration( Class( C )) 
SubCassOf( A B )
SubCassOf( B C )


view2:


Declaration( Class( A ))
Declaration( Class( B ))
Declaration( Class( C )) 
SubCassOf( A B )
SubCassOf( B C )
SubCassOf( A C )


view3:


Declaration( Class( A ))
Declaration( Class( C )) 
SubCassOf( A C )


This brings up the question of adding support in the ODM profile to distinguish asserted vs. inferred axioms.
Perhaps there could be a flag — e.g., 


isAsserted : Boolean = true // set it to false for an inferred axiom — or-- 
isInferred : Boolean = false // set it to true for an inferred axiom


Finally, additional markup may be useful — e.g., showing whether an ontology is consistent or not.

Chapter 16, which has always been an informative section of the ODM specification, describes differences between UML and OWL 1.0, and provides some guidance on strategies for mapping one to the other, including a partial mapping in QVT.  There are a number of issues with the text, including the fact that it is outdated, but many people find it useful from an educational perspective.


The RDF has determined that deleting the chapter altogether is not a good strategy due to the fact that so many educators have been using it as a teaching tool.  However, because of the reasons listed above, the RTF would like it to have a less prominent role in the overall specification.  Please move this chapter to an informative Annex in the document.

Annex F, entitled "RDF and OWL Workarounds for MOF Multiple Classification Issue" is an informative annex in the specification, provided to address issues that are no longer valid. The SMOF specification was designed specifically to address the issues identified in the annex, in fact.  The annex should be removed, as it is no longer needed.

The ODM metamodels and profiles were developed using UML 2.1.2, OCL 2.0, MOF 2.0, and MOF XMI 2.1.1, and should be revised to support the latest versions of these specifications.  The references in the normative references section of the document and any other text referring to these versions should be revised accordingly as well.

Annex D, "Extending the ODM", describes methods for extending the metamodels defined in the specification.  The metamodels themselves represent the abstract syntax of the languages they support, and rather than extending them, specification users tend to develop ontologies that use them.  


The RTF cannot identify a single user for this informative annex, which we believe is no longer relevant.  We have no evidence that anyone has ever used this section of the specification over the last 6 years, and believe that we should not be advocating its approach.  The annex should be removed from the specification.