Issue 10844: Figure D.3 notation Jira Issue ODM11-84
Issue 10846: Annex D.4 sets Jira Issue ODM11-85
Issue 10849: Figure 16.1 incomplete Jira Issue ODM11-1
Issue 10850: Formal structure Jira Issue ODM11-86
Issue 10853: Associations Jira Issue ODM11-2
Issue 10863: Distinct associations, ownedAttribute associations Jira Issue ODM11-3
Issue 10864: Distinct associations, restrictions Jira Issue ODM11-4
Issue 10865: Identifiers Jira Issue ODM11-87
Issue 10866: Associations Jira Issue ODM11-5
Issue 10867: Subproperites and redefintion Jira Issue ODM11-88
Issue 10871: Association member ends Jira Issue ODM11-89
Issue 10872: Table 16.9 and Naries Jira Issue ODM11-6
Issue 10873: Translation of binary associations. Jira Issue ODM11-90
Issue 10874: UML Thing 2 Jira Issue ODM11-91
Issue 10875: Individuals Jira Issue ODM11-92
Issue 10876: Disjoint. Jira Issue ODM11-93
Issue 10877: Classes of classes Jira Issue ODM11-7
Issue 10879: Mandatory properties Jira Issue ODM11-94
Issue 10884: Derivation. Jira Issue ODM11-95
Issue 10885: Table 16.10 Jira Issue ODM11-8
Issue 10886: Table 16.11 Jira Issue ODM11-96
Issue 10887: Table 16.12, Thing Jira Issue ODM11-97
Issue 10888: Table 16.12, AllValuesFrom Jira Issue ODM11-98
Issue 10889: Table 16.12, classes as instances Jira Issue ODM11-9
Issue 10890: Table 16.12, disjoint Jira Issue ODM11-99
Issue 10891: Inferring subsumption Jira Issue ODM11-10
Issue 10892: Boolean combination Jira Issue ODM11-11
Issue 10893: Names, unique names. Jira Issue ODM11-12
Issue 10894: Names, UML namespaces Jira Issue ODM11-100
Issue 10895: Other OWL Jira Issue ODM11-101
Issue 10897: Complex Objects Jira Issue ODM11-102
Issue 10898: Keywords Jira Issue ODM11-103
Issue 10899: Profiles Jira Issue ODM11-104
Issue 10900: UML to OWL, OWL-DL Jira Issue ODM11-105
Issue 10901: UML to OWL, Table 16.10 Jira Issue ODM11-106
Issue 10902: Object identification in UML Jira Issue ODM11-107
Issue 10904: N-aries. Section 16.3.6 Jira Issue ODM11-108
Issue 10905: Multiplicity. Jira Issue ODM11-13
Issue 10906: navigableOwnedEnd Jira Issue ODM11-14
Issue 10907: Enumeration literals Jira Issue ODM11-109
Issue 10908: Individuals, mapping Jira Issue ODM11-15
Issue 10909: complementOf and disjointWith Jira Issue ODM11-16
Issue 10910: Multiple Domains or Ranges for Properties. Jira Issue ODM11-17
Issue 10911: Ontology Properties Jira Issue ODM11-18
Issue 10912: Anonymous Classes Jira Issue ODM11-19
Issue 10913: Universal Superclass Jira Issue ODM11-110
Issue 10914: Constructed Classes Jira Issue ODM11-20
Issue 10915: Range Restriction Restriction Classes Jira Issue ODM11-111
Issue 10916: Range Restriction Restriction Classes Jira Issue ODM11-21
Issue 10917: Properties in OWL Jira Issue ODM11-22
Issue 11099: Constraints in the RDF Metamodel Chapter (10) should be specified in OCL Jira Issue ODM11-23
Issue 11100: Constraints in the OWL Metamodel Chapter (10) should be specified in OCL Jira Issue ODM11-24
Issue 11102: Mapping from Common Logic to OWL should be revised Jira Issue ODM11-25
Issue 11320: Thing in the Profile Jira Issue ODM11-112
Issue 11321: RDFSContainer-MembershipProperty Jira Issue ODM11-113
Issue 12390: Specification: RDFSComment optional representation as plain literal Jira Issue ODM11-114
Issue 12394: OWL Model Library elements are missing owl:versionInfo attributes Jira Issue ODM11-115
Issue 12399: Text describing owl:someValuesFrom and owl:hasValue limits implementations Jira Issue ODM11-116
Issue 12400: Examples provided for owl:inverseOf are misleading Jira Issue ODM11-26
Issue 12563: UML Profile for RDF and OWL, Section 14.2.5 Jira Issue ODM11-117
Issue 13074: Section: 10.2.2 Jira Issue ODM11-118
Issue 13075: Section: 10.9.3 Jira Issue ODM11-119
Issue 13937: Section: Appendix A, Section A.3 Jira Issue ODM11-120
Issue 13938: NamespaceDefinition is defined as a metaclass, without a stereotype Jira Issue ODM11-121
Issue 13940: Section: 14.2.8.1 Jira Issue ODM11-122
Issue 13941: Section: 14.1.3.5 Jira Issue ODM11-123
Issue 13977: rdfsDomain/Range should be based on dependency. Jira Issue ODM11-124
Issue 13978: Section: UML Profile for OWL and RDF Jira Issue ODM11-125
Issue 13979: Figure 14.10 missing property subsetting Jira Issue ODM11-126
Issue 13980: owlValue and allValuesFrom Jira Issue ODM11-127
Issue 13981: Figure 14.19 is property subsetting Jira Issue ODM11-128
Issue 13982: owlValue and allValuesFrom 2 Jira Issue ODM11-129
Issue 13983: RDFGlobalProperty shouldn't apply to classes Jira Issue ODM11-130
Issue 13984: rdfsDomain/Range should be based on dependency 2 Jira Issue ODM11-131
Issue 13985: rdfsDomain/Range should be based on dependency 3 Jira Issue ODM11-132
Issue 13986: RDFProperty, RDFObjectProperty, and RDFDatatypeProperty shouldn't apply to classes Jira Issue ODM11-133
Issue 14425: rdfs:Literal Jira Issue ODM11-134
Issue 16030: The PrimitiveTypes in the metamodel XMI file are instances of Class not PrimitiveType Jira Issue ODM11-135
Issue 16031: In the OWL metamodel the Restriction Cardinality elements should own their TypedLiteral Jira Issue ODM11-136
Issue 16032: multiple inheritance for MOF shown in Figure F.4 Jira Issue ODM11-137
Issue 16033: It would be preferable for isDeprecated to be non-optional with a default value of false. Jira Issue ODM11-138
Issue 16034: OWLClass::isClassKind:OCLClassKind breaks convention that �is� at the start of properties is used to indicate Booleans Jira Issue ODM11-139
Issue 16035: In Annex F the use of OWLClass::/isClassKind: and OWLClass::/hasRestrictionKind is not sufficient Jira Issue ODM11-140
Issue 16036: In the CL metamodel the associations Conjunction and Disjunction clash with class names. Jira Issue ODM11-27
Issue 16037: I propose that the following properties are owned by the Association Jira Issue ODM11-141
Issue 16038: derived Association OWLBase::/TripleForGraph Jira Issue ODM11-142
Issue 16039: There is a general lack of composition relationships for model management � in both the RDF and OWL metamodels Jira Issue ODM11-28
Issue 16040: Spec is sorely in need of examples showing how to represent common RDF/OWL constructs as instances of metamodel Jira Issue ODM11-29
Issue 16256: Users creating domain ontologies want their models to be user friendly Jira Issue ODM11-30
Issue 16495: ODM does not support internationalized URIs Jira Issue ODM11-143
Issue 16496: ODM should support recent W3C definitions for plain literals Jira Issue ODM11-144
Issue 16497: Stereotypes should be shown on diagrams in the RDF and OWL profiles Jira Issue ODM11-31
Issue 16498: ODM does not support XML Schema Datatype facets, which were added in OWL 2 Jira Issue ODM11-145
Issue 16499: Label and URI properties are duplicated on many elements in the RDF and OWL profiles Jira Issue ODM11-146
Issue 16500: Datatype definitions should be mapped to UML primitives Jira Issue ODM11-147
Issue 16501: Typed literal definitions should be mapped to their defining datatypes Jira Issue ODM11-148
Issue 16502: Need a stereotype to visually link individuals to their classifiers Jira Issue ODM11-149
Issue 16503: Need a stereotype to link local extended defs to the definitions they reference in imported vocabularies Jira Issue ODM11-150
Issue 16504: Need to augment stereotyped literal strings with InstanceSpecification metaclass Jira Issue ODM11-151
Issue 17338: ODM Metamodel takes a different approach to OWL restrictions from the Profile (and indeed from OWL): Jira Issue ODM11-32
Issue 17424: Provide support for distinguishing asserted vs. inferred axioms Jira Issue ODM11-33
Issue 18833: Move Chapter 16 to an Informative Annex Jira Issue ODM11-152
Issue 18834: Annex F has been superceded by SMOF Jira Issue ODM11-153
Issue 18835: Revise the ODM to support UML/MOF 2.4.1 Jira Issue ODM11-154
Issue 18836: Annex D has a number of issues and should be removed Jira Issue ODM11-155
Issue 18861: RDFWeb serves no purpose Jira Issue ODM11-170
Issue 18862: Revise the RDF Metamodel and Profile to support RDF source and dataset Jira Issue ODM11-156
Issue 18863: Stereotypes for RDF Containers and Collections Jira Issue ODM11-34
Issue 19025: ODM does not support internationalized URIs (Chapter 17) Jira Issue ODM11-35
Issue 19026: ODM does not support internationalized URIs (Chapter 16) Jira Issue ODM11-36
Issue 19071: Qualified Restrictions In Metamodel Jira Issue ODM11-171
Issue 19072: Further characteristics of Properties Jira Issue ODM11-172
Issue 19073: How to relate RDF Classes to an OWL Ontology in ODM metamodel Jira Issue ODM11-173
Issue 19079: Remove sub-packages of OWL metamodel Jira Issue ODM11-37
Issue 19080: profiles submitted with the RTF report include stereotype definitions that are not in the submitted RTF report itself Jira Issue ODM11-38
Issue 19093: The UML Profile for RDF and OWL still refers to the UML Superstructure Specification Jira Issue ODM11-39
Issue 19099: The section numbers refer to the 1.1 convenience document Jira Issue ODM11-40
Issue 19100: On RDFSResource, groupingNamespace, RDFSLabel, RDFSComment, are not documented Jira Issue ODM11-41
Issue 19101: On Triple (mis-named RDF Triple in the spec), statement, document are not documented Jira Issue ODM11-42
Issue 19102: In 10.6.2 the property �resource� does not seem right Jira Issue ODM11-43
Issue 19103: In 10.6.3, RDFSisDefinedBy should be a subproperty of seeAlso Jira Issue ODM11-44
Issue 19104: In 10.6.3 the constraints should not refer to IRIs but linked objects Jira Issue ODM11-45
Issue 19105: In 10.9.1, Document::xmlBase should be deleted (it�s on Source now) Jira Issue ODM11-46
Issue 19106: In 10.9.4 the attribute namespacePrefix should be just prefix Jira Issue ODM11-47
Issue 19107: In 10.9.7, graphForNG should be just graph Jira Issue ODM11-48
Issue 19108: 10.9.8 does not document bNode Jira Issue ODM11-49
Issue 19109: OWLOntology::owlUniverse is not documented � in fact it�s in 11.7.2 which should be moved Jira Issue ODM11-50
Issue 19110: Question section 11.2.3 RDFSLiteral (Augmented) Jira Issue ODM11-51
Issue 19111: There are still mentions of OWL Full and OWL DL Jira Issue ODM11-52
Issue 19112: Constraint [1] of AnnotationProperty still has URIReference and RDFLLiteral Jira Issue ODM11-53
Issue 19113: OWLOntologyProperty is obsolete Jira Issue ODM11-54
Issue 19114: OWLAllDifferent should specialize ClassExpression not OWLClass Jira Issue ODM11-55
Issue 19115: The subclass stereotype in the RDF profile section needs to be simplified to match the normative xmi model Jira Issue ODM11-56
Issue 19117: The section on changes required to other OMG specs has been made moot by SMOF Jira Issue ODM11-57
Issue 19118: The conformance section of the document needs to be revised to support the new metamodel structure Jira Issue ODM11-58
Issue 19119: The proof of concept section should be revised to discuss support by Thematix/No Magic and Sparx Jira Issue ODM11-59
Issue 19120: Revise the overview section to support the latest changes in the metamodel structure Jira Issue ODM11-60
Issue 19125: Some values of the rdf:esource attribute are incorrect Jira Issue ODM11-61
Issue 19126: Annex mixes UML and OWL terminology Jira Issue ODM11-62
Issue 19135: ODM 1.1 Report contains editing bugs Jira Issue ODM11-157
Issue 19136: ODM 1.1 Editorial Changes Jira Issue ODM11-158
Issue 19138: Annex uses old stereotype name Jira Issue ODM11-63
Issue 19139: Update annotation stereotype in OWL profile Jira Issue ODM11-64
Issue 19140: Conflicting property names for stereotype "statement" Jira Issue ODM11-65
Issue 19168: Class Node should be abstract Jira Issue ODM11-66
Issue 19170: Multiplicity Conflict Jira Issue ODM11-67
Issue 19181: UML class name typo Jira Issue ODM11-68
Issue 19182: Graphical representation of �equivalentClass� conflicts with text Jira Issue ODM11-69
Issue 19183: Incorrect relationship between OWL and RDF packages? Jira Issue ODM11-70
Issue 19279: Typos, grammatical errors, and style issues Jira Issue ODM11-71
Issue 19310: Self Object Property Restrictions are only partially supported in the ODM 1.1 Specification Jira Issue ODM11-72
Issue 19311: Stereotypes associated with Restrictions in the OWL Profile are incompletely defined Jira Issue ODM11-73
Issue 19312: WL2 n-ary datatype hook and universal and existential restriction on n-ary data ranges Jira Issue ODM11-74
Issue 19313: The ODM Metamodel and Profile should support OWL2 pairwise disjoint and disjoint union classes Jira Issue ODM11-75
Issue 19314: The ODM Metamodel and Profile model libraries should support OWL2 universal and empty object and data properties Jira Issue ODM11-76
Issue 19315: The ODM Metamodel and Profile model libraries should support OWL2 extra built-in datatypes (rational, real) Jira Issue ODM11-77
Issue 19316: The ODM Metamodel and Profile should support OWL2 inverse object property expressions Jira Issue ODM11-78
Issue 19317: The ODM Metamodel and Profile should support OWL2 property chains Jira Issue ODM11-79
Issue 19416: Representation of Axioms Jira Issue ODM11-80
Issue 19421: Representation of Axioms Jira Issue ODM11-81
Issue 19630: ODM metamodel needs a Package concept for managing a structure for ontologies Jira Issue ODM11-82
Issue 19656: Issues on ODM 1.1 UML XMI file for RDFLibrary Jira Issue ODM11-83
Issue 10844: Figure D.3 notation (odm-rtf)
Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:
Figure D.3 notation. In Annex D, in Figure D.2, the instance names should be underlined. Some of the association end names are so far from the ends of the lines that it's hard to tell which they are referring to.
The RTF agrees with the issue raised against this figure. We advocate methods such as OntoClean, described in this annex for ontology evaluation, but suggest that a better approach would be to develop ontology libraries and additional profiles, together with custom applications, to achieve evaluation goals using the ODM. Using the methods described in the annex for extending the ODM is not recommended. Our recommendation after reviewing this issue and issue 10846 is to remove Annex D altogether
Annex D.4 sets. Annex D.4, under Figure D.4 should have another constraint that prevents two instances of NAryProperty from having the same values for the properties of the Nary. Otherwise, it could represent a bag of property values, which OWL properties cannot
The RTF agrees with the issue raised against the recommended representation of n-ary relations. There are a number of ways of modeling n-ary relations in OWL, including reification of the relationships as classes, as described in http://www.w3.org/TR/swbp-n-aryRelations/ and as partially described in the Annex. These have a corresponding patterns in ontologies represented using the ODM metamodels, but would not require an extension to the metamodel itself, necessarily. The representation described in Annex D would indeed require an additional constraint if implemented, but using the methods described for extending the ODM is not recommended. Our recommendation after reviewing this issue and issue 10846 is to remove Annex D altogether
Figure 16.1 incomplete. Figure 16.1 (Key Aspects of UML Class Diagram) is missing the multiplicities on general/specific, and the subsetting between ownedEnd and memberEnd.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Formal structure. Under Figure 16.1, the first sentence refers to "formal structure". Should explain what this is. Is it the metamodel?
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Associations. In Section 16.2.1 (UML Kernel), the discussion around Tables 16.2 through 16.4 seems to be about relational implementations, rather than UML modeling in the sense that is important to OWL. My suggestion is to replace Tables 16.3 and 16.4 with the tabular forms of the metamodel, as in 16.2. The paragraph above Table 16.3, first sentence, modeling associations does not depend on the implementation of classes (the "implementation" usually refers to how the model is translated to a platform). Same comment on the second sentence, which says Table 16.2 is an implementation, when it is only a tabular form of the metamodel. The second sentence refers to the disjoint union of attributes, but there's nothing like this in UML.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Distinct associations, ownedAttribute associations. In 16.2.2 (Class and Property - Basics), in the paragraph below Table 16.6, there is the sentence " Note that UML ownedAttribute M2 associations are distinct, even if ownedAttributes have the same name associated with different classes." What are "M2 owned attribute associations"? In the case of M1 properties, properties with the same name may be on different classes, but if they inherit from the same base class where a property of that name is introduced, then they are the same property from OWL's point of view. There is usually no no need to translate to unique OWL properties, just restrictions. See next issue.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Distinct associations, restrictions. In 16.2.2 (Class and Property - Basics), in the paragraph above Table 16.7, says the OWL properties "arising" (I assume due to translation) from a UML model are distinct, that OWL restrictions aren't in the translation. UML can redefine properties in subtypes of the classes where the property is introduced, which is equivalent to restriction. The method employed in the chapter is not adequate.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Identifiers. In 16.2.2 (Class and Property - Basics), in the paragraph below Table 16.7, the first sentence says the translation assumes that a single name dentifies each instance of the class. It isn't necessary to assume this, since UML does not assume a relational semantics. The notion of identity is primitive in UML and applies even to instances of classes that have no attributes or attribute values. The rest of the paragraph may apply to relational implementations, but is not a general solution. It also assumes that the property names of classes are always different, but distinct classes can have the same properties in UML. (BTW, fourth sentence, "values" -> "names")
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Associations. In 16.2.2 (Class and Property - Basics), in the paragraph below Table 16.7, gives the wrong translation to OWL for UML associations. UML associations have properties at end, and these are often navigable. Binary associations in UML translate to two inverse properties, using these property names, not the association name. See the UML profile for OWL for the translation options for associations, and the third paragraph in 16.2.3.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Subproperites and redefintion. In 16.2.2 (Class and Property - Basics), in the paragraph below Table 16.8, the second sentence, in parentheses, says that subproperties translate to redefinition. The translation is only to subsetting. Also the wording in parenthetical remark conflates association generalization with property subsetting. Same comment about the last sentence of this paragraph, which omits property subsetting. Same comment about the translation given in the next paragraph. UML associations, even binary ones, can have more than one property, and each property can be subsetted if the associaton as a whole is specialized, but they don't all need to be.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Association member ends. In 16.2.2 (Class and Property - Basics), third paragraph under Figure 16.3 describes UML member ends incorrectly. The second sentence says that the classes Staff and Enrolled are member ends, but member ends are classes, not properties.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Table 16.9 and Naries. In 16.2.2 (Class and Property - Basics), Table 16.9 replace the "Parts" header with "Properties". The Reification property isn't necessary, because AssociationClass is both a class and association, there is no separate reification of the association (this is necessary in OWL DL, however, and even in OWL Full, some extension is needed for a subclass of Property and Class to correspond to a UML Association Class). The text below the table uses the term "implements" which doesn't apply (these are platform-dependent models), and introduces the reified association, which doesn't exist in UML.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Translation of binary associations. In 16.2.3 (More Advanced Concepts), third paragraph, next to last sentence, the domain of the OWL property is the class at the non-navigable end. This is because the ends of associations in UML are placed opposite the class they navigate from.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
UML Thing 2. In 16.2.3 (More Advanced Concepts), fourth paragraph, last sentence, it's clear what the tool sets would do with it: provide Thing for modelers to explicitly assign as the end of a class, and use it as the default end class when none is given.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Individuals. In 16.2.3 (More Advanced Concepts), fifth paragraph, the first sentence draws a conclucions ("therefore") without any justification. Individuals in OWL are all classified by Thing, whether or not this is explicityly recorded. It's just syntactic sugar to omit it. In UML, instance specifications can be classified by Thing in the model library and have the same semantics as OWL individual.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Disjoint. In 16.2.3 (More Advanced Concepts), sixth paragraph, parenthetical remark should note that with UML Thing the same is true in UML).
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Classes of classes. In 16.2.3 (More Advanced Concepts), seventh paragraph, the second sentence implies classes are not instances in OWL DL, but even in DL, OWL Class is a class of classes, by definition. For example, an ontology of animals might have the class Dog, which is an instance (of OWL Class) and a class (of Fido, Rover, and other individual dogs). Ther third sentence should be moved to be the second, and start with "however"|, because it is an exception to the first sentence. After "declaration" should be replaced wtih "a common superclass".
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Mandatory properties. In 16.2.3 (More Advanced Concepts), under the XML example, third paragraph, I assume "may not" should be "must". The property must have values for every individual
Derivation. In 16.2.3 (More Advanced Concepts), under the XML example, the paragraph starting "UML allows a property", UML derivation means derivation from values of properties, not from generalizations of the classes that are the domain of those properties.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Table 16.10. In 16.2.3 (More Advanced Concepts), Table 16.10, the names of classes are capitalized in UML. The UML element corresponding to OWL subproperty is property subsetting. N-aries and association classes are not well-supported in OWL, so don't belong in a table of common features (see other issues on n-aries and association classes).
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Table 16.11. In 16.2.3 (More Advanced Concepts), Table 16.11, the last row (classes as instances), is supported in OWL Full, and even in DL (OWL Class is a class of classes, by definition). For example, an ontology of animals might have the class Dog, which is an instance (of OWL Class) and a class (of Fido, Rover, and other individual dogs). This table should be in Section 16.6 (In UML but not OWL).
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Table 16.12, Thing. In 16.2.3 (More Advanced Concepts), Table 16.12, the frst row (Thing) should be qualified by the fact that OWL is using syntactic sugar for global properties and autonomous individuals, and that the standazrd UML model library given in ODM enables UML to support these features. This table should be in Section 16.5 (OWL but not UML).
Table 16.12, AllValuesFrom. In 16.2.3 (More Advanced Concepts), Table 16.12, the second row (AllValuesFrom), AllValuesFrom is directly supported in UML as property subsetting.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Table 16.12, classes as instances. In 16.2.3 (More Advanced Concepts), Table 16.12, class as instances appears in both this table and Table 16.11.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Table 16.12, disjoint. In 16.2.3 (More Advanced Concepts), Table 16.12, last row. UML supports declaring disjoint classes.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Inferring subsumption. In Section 16.5.1 (Predicate Definition Language), first sentence, UML can support subsumption reasoning also, see http://www.inf.unibz.it/~calvanese/papers-html/AIJ-2005.html
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Boolean combination. In Section 16.5.1 (Predicate Definition Language), third sentence, UML supports the equivalent of unionOf.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Names, unique names. In Section 16.5.2 (Names), the first two paragraph implies UML assumes unqiue names. M1 instance specifications in UML can have different names, but refer to the same M0 individual. They can also have the same name and refer to different M0 individuals. The third paragraph implies UML does not have name management (given the title of Section 16.5), which of course it does in namespaces.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Names, UML namespaces. In Section 16.5.2 (Names), next to last paragraph, namespaces are supported at all metalevels in UML/MOF.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Other OWL. In Section 16.5.3 (Other OWL Developments), should refer to OWL 1.1.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Complex Objects. In Section 16.6.2 (Complex Objects), the first two paragraph and the last omit the critical aspect of connectors, that they provide a model of the interconnections of objects that are all related to the same other obejct. For example, the engine in a car powers the wheels and is controlled by the driver. See http://www.jot.fm/issues/issue_2004_11/column5
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Keywords. In Section 16.6.4 (Keywords) keywords are confused with stereotypes. Keywords don't extend, stereotypes do. Keywords are just an element of notation.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Profiles. In Section 16.6.5 (Profiles), third paragraph says that profiles not necessary because of metalevel separation. They are used as an alternative way to extend M2 classes with subclasses, in particular, where the subclases are defined at M1, even though they have the effect of being at M2.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
UML to OWL, OWL-DL. Section 16.3 (UML to OWL), third sentence, says the mapping is only to OWL-DL. Why not OWL Full?
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
UML to OWL, Table 16.10. Section 16.3 (UML to OWL), third paragraph, first sentence, says the mapping is based on Table 16.10. The section containing that table has alot of errors about UML. It would be better to base the mapping on the profile (Chapter 14), which has had muct more review from the UML perspective
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Object identification in UML. Section 16.3.1 (Naming Issues), second paragraph says UML (packageable) elements are identified by name. UML packageable elements can be anonymous, and they still have identity. The notion of identity is primitive in UML and applies even when no names are used.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
N-aries. Section 16.3.6 (Association Classes and N-ary Associations), second paragraph, says the translation treats association classes and naries the same way. Association classes are not the same as n-aries, see issues filed on n-ries in 16.2.2 (Class and Property - Basics).
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Multiplicity. Section 16.3.7 (Multiplicity), the translation can also be to OWL FunctionalProperty or InverseFunctionalProperty if the multiplicity is 1.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
navigableOwnedEnd. The introduction to Section 16.3.5 (Binary Association To Object Property) accounts for navigableOwnedEnd, but the introduction to Section 16.3.8 () Association Generalization) does not.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Enumeration literals. The introduction to Section 16.3.4 (Attribute to Property) accounts for enumeration literals that are instances of classifiers, but the introduction to Section 16.3.9 (Enumeration) does not.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Individuals, mapping. Section 16.4.1.1 (Mapping for Individuals), first sentence says the profile (Chapter 14) represents individuals as a singleton class. This is incorrect. The profile models individuals as instance specifications. To give property values to the individual, the profile uses a singleton class. Section 16.4.1.1 incorrectly concludes that individuals should not be mapped, which affects 16.4.1.2 (Mapping for Enumerated Classes) and Section 16.4.13 (Annotation Properties to Comments).
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
complementOf and disjointWith. Section 16.4.1.3 (Mapping for complementOf and disjointWith) says UML has constructions for complementOf and disjointWith in the PowerTypes pacakge. It actually has constructs for unionOf and disjointWith. Section 16.4.1.3 says no mapping is given because the OWL constructs are pairwise, but OWL unionOf and disjointWith are not pairwise, they can apply to any number of classes.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Multiple Domains or Ranges for Properties. Section 16.4.1.4 (Multiple Domains or Ranges for Properties) says that multiple domains or ranges for properties is equivalent to the intersection of the domains and ranges. UML properties have at most one type, and intersection can't be represented in UML without the profile (Chapter 14). How is this translated?
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Ontology Properties. Section 16.4.3.2 (Ontology Properties to Comments) should use dependencies for some of the translations. See the profile (Chapter 14).
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Anonymous Classes. Section 16.4.4.3 (Anonymous Class to Class) can translate blank nodes to anonymous classes in UML.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Universal Superclass. Section 16.4.5.2 (Universal Superclass) should also refer to Annex A.
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Constructed Classes. The introduction to Section 16.4.6 (Constructed Classes) refers to OWL "difference". I assume this is supposed to be complementOf. The introduction to the section says intersection can be mapped to subclass relationships, but this isn't true, at least not without the profile, see intersection in Chapter 14. It also says union can be translated to subclass relationships, but doesn't mention UML generalization sets and isCovering, see Section 16.3.10 (Powertypes).
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Range Restriction Restriction Classes. The introduction to Section 16.4.8 (Range Restriction Restriction Classes) refers to properties "behaving". Properties are static, they don't "behave".
FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved. Disposition: Deferred to RTF
Range Restriction Restriction Classes. The introduction to Section 16.4.8 (Range Restriction Restriction Classes) says the translation is to a comments. But AllValuesFrom translates directly to redefinition of property types, see the profile (Chapter 14).
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Properties in OWL. The end of Section 16.4.9 (Properties in OWL) refers to multiple domains be ing equivalent to the domain being an intersection. This does not translate to UML, see issue on Constructed Classes
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
Summary: Constraints in the RDF Metamodel Chapter (10) should be specified in OCL. Description: Text based descriptions of constraints provided in chapter 10 with the RDF metamodel should be specified in OCL.
The RTF is in the process of revising the metamodels to support RDF 1.1 and OWL 2, and has deferred work on OCL revisions in particular until metamodel revision is complete. Disposition: Deferred
Summary: Constraints in the OWL Metamodel Chapter (10) should be specified in OCL. Description: Text based descriptions of constraints provided in chapter 11 with the OWL metamodel should be specified in OCL.
The RTF is in the process of revising the metamodels to support RDF 1.1 and OWL 2, and has deferred work on OCL revisions in particular until metamodel revision is complete. Disposition: Deferred
Specification: Ontology Definition Metamodel FormalNumber: ptc/06-10-11 Section: 18 Summary: The mapping from RDFS and OWL to CL should be revised to reflect metamodel changes in CL due to finalization of ISO 24707. Description: Minor changes were made to the CL language as it was finalized through the ISO process, which are not reflected in the ODM specification. These changes also need to be reflected in the mapping (embedding) description contained in chapter 18.
The RTF has elected to defer until the changes to CL specification have been completed by ISO. Disposition: Deferred
Thing in the Profile. The UML Profile (Chapter 16) should use Annex A Thing instead of an anonymous class to model owl:Thing. Search on "Thing" (case sensitive) in the profile.
We addressed the most urgent profile issues. We would expect this to be among those addressed first in RTF. Disposition: Deferred to RTF
In Annex A, RDFSContainer-MembershipProperty should be moved to the UML Profile chapter as a stereotype based on UML:Property.
We addressed the most urgent profile issues. We would expect this to be among those addressed first in RTF. Disposition: Deferred to RTF
RDFSComment - (from ODM FTF2 meeting minutes of February 6, 2008), vendors need the ability to include language tags for comments and thus optionally, would like to represent this as an RDF plain literal, rather than UML comment (or potentially an UML opaque expression, which does permit a language tag)
This issue has been resolved in the resolution for issue 16496, which does allow language tags to be used on comments as well as with custom annotations.
From minutes of the ODM FTF 2 telecon held February 20, 2008: owl:versionInfo -- currently in the profile there is no stereotype for this. In attempting to implement this, we can add versionInfo to stereotypes, but not to elements in the model library for which there are no stereotypes. So -- what is the mechanism for adding versionInfo to elements in the model library? Decision is to make versionInfo an attribute on model library elements.
From email dated 3/12/2008 from SRI, and as discussed (and documented in the minutes from the ODM FTF2 F2F DC meeting: Section 14.2.5.6 The second paragraph appears to imply OWL DL. In OWL full, a class can be a value. This is an oversight: the description needs to be revised to include class in the case of OWL Full.
From email dated 3/12/2008 from SRI, and as discussed (and documented in the minutes from the ODM FTF2 F2F DC meeting: Section 14.2.6.5 - Simple association with properties at the end is a nice readable notation. However, the "brotherOf" property between the two classes in Figure 14.28 could be duplicated on an association between two other classes on the same diagram, but the would be unrelated in the UML model, whereas in OWL they would be a single property with multiple domains and ranges. (This comment applies also to similar graphical representation shown in other sections). So -- this is true. It is managed in UML via the namespace of the relation, which may assume that you're not trying to determine all possible values with each property. The example is not a good one and could lead to inconsistent interpretation. We should get a better example. Also, we need to decide what the interpretation of the role name is, when you have mutiples (when you assume that it is or is not in the same namespace).
The current method for specifying OWL restrictions (e.g., owl:allValuesFrom, owl:someValuesFrom, owl:hasValue) in the profile does not provide a means to differentiate, on a diagram, between the restriction types. Further, it does not create the proper "necessary and sufficient" or "necessary" relationships between the class to which the restriction applies and the anonymous class specified by the restriction.
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!
Agreed. The OCL was already updated by the resolution to 16495 which replaced URIReferenceNode. Also RDFSLiteral was renamed to Literal. Actually the first part of the constraint is redundant since the resource property is only defined on ReferenceNode. With respect to the other 2 constraints mentioned in the issue, 16495 deleted the constraint in section 10.2.9 (page 41) and added the () to isEmpty for the constraint on 10.6 2 (p49) � so no further change is needed .
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).
This issue is related to issue 16498, which addresses the need for better support for data types, restrictions, data ranges, and datatype facets in general, and the resolution for it is addressed in the resolution of that issue.
RDFStatement 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.
This issue is related to issue 16495, which addresses the need for better support for internationalized URIs (IRIs) and reworks the RDF profile with respect to how graphs, statements, and URIs/IRIs should be represented. The resolution for 13941 is addressed in the resolution of that issue (namely 16495).
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.
While direct representation of RDF properties as classes may not have provided �proper� notation from a UML perspective, neither would representation of RDF properties without some capacity to represent property hierarchies without unnecessary detail, (as one of many examples), be acceptable to vocabulary and ontology developers. In fact, for representation of properties in OWL, a �standalone� notation for complex properties and restrictions that does not require the modeller to drag property endpoints around on diagrams is essential. This resolution is intended to (1) eliminate the concerns with respect to basic property notation for RDF and OWL and (2) address the modelling requirements for properties in RDF and OWL that motivated the use of UML::Class as a base for properties in the first place, through introduction of the surrogate.
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.
This issue and a number of others related to representation of restrictions in OWL have been addressed via extensive changes in the resolution to issue 12563. As a part of that resolution, the �owlValue� stereotype was eliminated altogether, making this issue moot.
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.
In keeping with the resolution to issues 13977, and 13984-6, eliminate the class notation for 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.
This issue can be resolved by correcting the text at the start of section 14.1.7.1 in the description of RDFProperty
The PrimitiveTypes in the metamodel XMI file are instances of Class not PrimitiveType
This is addressed by using UML 2.4.1/MOF 2.4.1 for the metamodel as a result of 18835.
In the OWL metamodel the Restriction Cardinality elements should own their TypedLiteral (i.e. the associations Cardinality, MaxCardinality, MinCardinality should be composite)
The metamodel for Restrictions has been revised and redrawn as a result of issue 19071. That addresses this issue also.
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).
The RTF has determined that due to SMOF, Annex F is no longer required and the Annex should be deleted, per the resolution to issue 18834. Thus, this issue is closed to the resolution of 18834. Disposition: Resolved
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 RTF has determined that due to SMOF, Annex F is no longer required and the Annex should be deleted, per the resolution to issue 18834. Thus, this issue is closed to the resolution of 18834. Disposition: Resolved
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
The RTF has determined that due to SMOF, Annex F is no longer required and the Annex should be deleted, per the resolution to issue 18834. Thus, this issue is closed to the resolution of 18834. Disposition: Resolved
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.
The RTF has determined that due to SMOF, Annex F is no longer required and the Annex should be deleted, per the resolution to issue 18834. Thus, this issue is closed to the resolution of 18834. Disposition: Resolved
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).
The RTF has elected to defer until the changes to CL specification have been completed by ISO. Disposition: Deferred
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
This issue is moot due to the removal of the RDFWeb package completely by issue 18861.
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.
This association is not needed; neither is OWLGraph needed as a specialization of RDFGraph
There is a general lack of composition relationships for model management � in both the RDF and OWL metamodels
Significant changes to the metamodels have occurred since version 1.0. These changes had a broader scope than composition relationships, Subsequent analysis of the metamodel is anticipated to include composition. Resolutions against specific composition relationships are deferred until RTF 1.2. Disposition: Deferred
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
The RTF recognizes the importance of providing examples. However, RTF effort for version 1.1 concentrated on revising and improving the metamodels, Given the metamodels� evolving nature during the past year, producing examples was judged risky, as an example construct might soon be out of date. Resolutions against issue 16040 are deferred until RTF 1.2. Disposition: Deferred
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.
The RTF agrees that work could be done to augment the current graphical notation in the ODM profiles with short cuts and other user-friendly diagramming options. We have determined that the best approach to addressing this issue is to defer it until revisions to support OWL 2 are complete, so that we can take a step back and provide a more thoughtful and thorough approach that takes all of the language modifications into account. Disposition: Deferred
Revise the RDF metamodel and profile to reflect modifications to the W3C standards to use internationalized URIs (IRIs).
When the ODM 1.0 specification was originally published, the W3C Recommendation for internationalized URIs (IRIs) had not yet been published. It was made available shortly after ODM publication, however, and the OWL 2 recommendation in particular relies on it heavily. The ODM metamodels and profiles for RDF and OWL should be revised accordingly. One specific change is the lack of a need to separate URIReference from UniformResourceIdentifier (which inherited from it) going forward. For most use cases of the ODM metamodels and profiles, the distinction between an IRI and a URI can be eliminated, although in practice, a URI represents a more constrained character string, i.e., additional escaped and special Unicode characters are permitted in IRIs that are not allowed in URIs. The RTF has elected to eliminate the URIReference altogether, and retain the definition of a URI as support for those applications/models that require it. Note 1: Application of this resolution anticipates that the resolution of issue 13938, which addresses the changes required to section 14.1.2.1 Namespace Definitions, will be applied first.
Formalize the definition of RDF plain literals in the RDF metamodel and profile to reflect recent W3C specification revisions.
While the ODM 1.0 specification incorporated a model for plain literals based on implicit definitions in the original RDF 1.0 specifications, an explicit definition was published at the time the OWL 2 specifications were published. In addition, recent revisions to the RDF specification, which will be released as RDF 1.1 later this year, clarify the definition of literals in RDF. The distinction between plain and typed literal has been difficult to discern since the original documents were published by the W3C. The OWL working group devised a specification for rdf:PlainLiteral that requires every literal to include a language tag, which is far from ideal. The latest approach, codified in the RDF 1.1 specification, makes much more sense from an OMG perspective, and states that any literal that is not explicitly typed is, by default, of type xsd:string. This approach clarifies and simplifies the equivalent representation in UML and MOF, and makes sense for ODM implementations. See http://www.w3.org/TR/2009/REC-rdf-plain-literal-20091027/ and http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/ for additional details. Note that this resolution assumes application of the resolution to issue 16495 first.
Stereotypes should be shown on diagrams in an abstract syntax section under each profile, not only in text under each stereotype.
Many new diagrams have been incorporated into the set of resolutions completed for the ODM 1.1 revision. However, the lion�s share of these are in the RDF Profile, with only partial coverage for OWL at this point. As a result, the RTF has determined that this issue should be deferred to the ODM 1.2 revision to complete the process of integrating diagrams that represent all of the stereotypes provided in the profiles. Disposition: Deferred
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.
Treatment of datatypes and data ranges has been vastly improved in OWL 2, and is required for development of emerging standards such as the Information Exchange Policy Vocabulary and Financial Industry Business Ontology families. The resolution, below, revises the OWL 2 metamodel and profile in support of these capabilities
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.
The current profiles for RDF and OWL provide many examples of unique properties representing the URI/IRI and/or label on stereotypes, for example, for the definition of RDFProperty as defined in 14.1.7.1, which has its own uriref property. This means that the XMI for any vocabulary or ontology developed in tools that implement the profile will necessarily include many definitions of uriref, uri, and label, each of which has a unique UUID. In order to ensure that any profile element, in either the RDF or OWL profile, that can be labeled and/or named (i.e., can have an IRI), has the same label and identifier (name/IRI) property rather than one of several, additional, abstract stereotypes that provide a single source for each of these are needed. These new stereotypes can be applied in the RDF profile and inherited by stereotypes in the OWL profile to fulfill the requirement.
Need to be able to map xsd datatypes to UML primitive types in the RDF profile to facilitate tool support for value specification.
The requirement in this case can be fulfilled by augmenting the definition of rdfs:Datatype with an optional property representing the appropriate UML primitive type. Note that resolution of this issue presumes application of the resolution to issue 16495.
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.
This issue has been resolved in the resolution for issue 16496, which does include the reference to the rdfs:Datatype, optionally, as a part of the specification for �literal�. .
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.
This resolution presupposes application of the resolution to issue 16495.
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).
This issue is related to issue 16495, and the resolution for it is addressed in the resolution of that issue.
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.
This issue has been resolved in the resolution for issue 16496, which does include UML::InstanceSpecification as a base class as a part of the specification for �literal�.
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.
Significant changes to the ODM metamodel have occurred since version 1.0. These changes had a broader scope than restrictions, Subsequent analysis of the metamodel is anticipated to include restrictions. Resolutions against issue 17338 are deferred until RTF 1.2. Disposition: Deferred
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.
A number of the features described above go well beyond what a traditional UML tool, without an integrated reasoning engine, might provide. However, the ability to consistently �mark� an ontology with additional content if such an integration were available would clearly be useful. A �quick reference� capability would also be quite helpful to ODM users. We have determined that the best approach to addressing this issue is to defer it until revisions to support OWL 2 are complete, so that we can take a step back and provide a more thoughtful and thorough approach that takes all of the language modifications into account. Disposition: Deferred
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.
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 MOF Support for Semantic Structures (SMOF) 1.0 Specification, available at https://www.omg.org/spec/SMOF/1.0/, corrects the issues that Annex F raises and provides a work-around for. While the RTF does not know the implementation status for SMOF, from a specification perspective, Annex F is obsolete, and should be removed from the specification.
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.
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.
Recent changes/clarifications in the RDF 1.1 specification reduce the need for a separate RDFWeb package. Further, there has been, and there is unlikely to be, any movement by other standards to use it to �map to similar features in a Common Logic ontology, Topic Map, UML, or ER conceptual model�. Finally, it adds confusion through the existence of duplicated class names with the RDFConcepts package. Therefore the package (section 10.9) should be removed and any metamodel elements merged into RDFConcepts. --
This is a useful clean up. While rationalizing headings, there are many mentions to �RDFBase Package� which does not exist: in general the package name actually makes the document hard to navigate so should be removed.
The RDF 1.1 Concepts and Abstract Syntax document, which has been stable for months and is now in Last Call at the W3C, has substantially redefined the notion of packaging from the perspective of an RDF vocabulary. An RDF source can include documents as well as realizations of an RDF graph in a repository, such as a triple store, which and been a gaping hole in earlier versions of the specification. These revisions are critical to proper packaging of RDF in ODM applications, and should be reflected in the metamodel and profile.
The resolution described below was developed after many months� discussion within the RTF and with external experts involved in the RDF 1.1 revision. For historical context, the RTF identified a gap in mid- to late-2011, whose issue we addressed with a stereotype and set of relationships we called a �MagicBox� (to the consternation of some RTF members and others), to fill the role of what the RDF 1.1 working group identified in parallel as an �RDF Source�. That solution has evolved over time and after significant discussion among RTF members into what is presented below. The solution for the profile has been vetted in the Visual Ontology Modeler plug-in for MagicDraw and is used for both the IEPPV and FIBO ontologies. The approach taken for the metamodel is under development by Adaptive, but has been reviewed by RDF experts and is considered an accurate representation.
The current ODM specification is lacking stereotype definitions for containers and collections. The entire section in the profile amounts to one sentence that references an annex. The section should be revised to provide stereotypes for these elements.
Via the resolution to issue 16495, the ODM metamodels and profiles for RDF and OWL were revised to support internationalized URIs (IRIs). Chapter 17, which covers the mapping from Topic Maps to OWL, has not been updated to reflect this modification however. The chapter needs to be updated to be brought in line with these changes.
Chapter 17 has always been an informative section of the ODM specification. Chapter 16, another informative section, is being moved to an informative annex (Issue 18833), with resolutions against the content of what was Chapter 16 deferred until RTF 1.2 (Issue 19026). A similar course of action will be taken for Chapter 17. Changes will deferred until RTF 1.2, at which time it will be to an informative annex, with resolutions against the content of what was Chapter 17 acted upon in that annex. Disposition: Deferred
Via the resolution to issue 16495, the ODM metamodels and profiles for RDF and OWL were revised to support internationalized URIs (IRIs). Chapter 16, which covers the mapping from UML to OWL, has not been updated to reflect this modification however. The chapter needs to be updated to be brought in line with these changes.
Chapter 16 has always been an informative section of the ODM specification. It is being moved to an informative annex (Issue 18833). Resolutions against the content of what was Chapter 16 are deferred until RTF 1.2. Disposition: Deferred
The resolution to 12563 documented how to represent qualified Restrictions as added to OWL 2, using the UML Profile: the metamodel needs to be extended to provide an equivalent level of coverage.
Representation of restrictions on properties was revised extensively for the profile via the resolution to 12563, and is required for development of emerging standards such as the Information Exchange Policy Vocabulary and Financial Industry Business Ontology families. The resolution, below, revises the OWL 2 metamodel and makes minor revisions to the profile based on usage experience in support of these capabilities. The primary aspects to be addressed in the metamodel are as follows: - Addition of hasSelf restriction at OWL2 - Use of integers rather than Literals to express cardinality of restrictions - Addition of qualified cardinality restrictions at OWL2 - Use of DataRange rather than Enumeration for Data All/SomeValuesFrom - The introduction of ClassExpression rather than Class in restrictions For organizational purposes, Restrictions are important enough to have their own subsection This resolution incorporates changes to address 16031 (ownership of Literals). A lot of this is addressed by the second bullet above, only leaving HasValueRestriction. Note that application of this resolution requires that the resolution to issue 12563 is applied first.
The ODM Metamodel and Profile should support OWL2 reflexive, irreflexive and asymmetric properties
Representation of properties was revised extensively for the profile via the resolution to 13977, 13979, and 13984 through 13986, although support for reflexive, irreflexive and asymmetric properties was not provided in that resolution. The resolution, below, revises the OWL 2 metamodel with respect to OWL object properties and makes similar revisions to the profile. Note that application of this resolution requires that the resolution to issues 13977, 13979, and 13984 through 13986 (all one resolution) is applied first. For the metamodel, rather than introducing a further subclass for each of the new characteristics, this provides an opportunity to rationalize the metamodel approach with the profile and use Booleans for each.
There are ontologies such as Dublin Core which consist of RDFS Classes, but, for various reasons, also have an OWL Ontology. Currently the ODM metamodel does not have a way to represent this association � only OWL Classes can be linked to an OWL Ontology (the ODM Profile can easily reuse the UML association between Package and PackagedElement but this usage should really be documented).
This can be addressed more generically at the RDF level.
Remove sub-packages of OWL metamodel With OWL 2 no longer making a distinction between OWL DL and OWL Full it does not make sense to have separate ODM packages for these: there should just be one OWL package/metamodel.
The profiles submitted with the RTF report include stereotype definitions that are not in the submitted RTF report itself. These represent work in progress that the RTF felt should be left in the submitted profiles but that are subject to change/reconciliation in the 1.2 RTF.
Over the last several years since the start of the RTF, significant progress has been made in correcting problems encountered via implementation experience, and through working towards full support for OWL 2. The profiles submitted with the ODM 1.1 RTF report include a combination of support for the set of resolutions adopted for the ODM 1.1 and work in progress towards an ODM 1.2 specification. The RTF team determined that it would be counterproductive to remove the work in progress, but due to the urgent need for an interim version of the specification, to defer finalization of this work to the 1.2 RTF. Disposition: Deferred
References in the profile section need to be revised to reflect UML 2.4.1 / 2.5 documents, and any new references need to be incorporated into chapters 3 and 19.
The section numbers refer to the 1.1 convenience document
On RDFSResource, groupingNamespace, RDFSLabel, RDFSComment, are not documented. Actually the latter are in 10.3.2 which should be moved
On Triple (mis-named RDF Triple in the spec), statement, document are not documented. Actually statement is in 10.4.4 which should be moved.
In 10.6.2 the property �resource� does not seem right
In 10.6.3, RDFSisDefinedBy should be a subproperty of seeAlso
In 10.6.3 the constraints should not refer to IRIs but linked objects
In 10.9.1, Document::xmlBase should be deleted (it�s on Source now)
In 10.9.4 the attribute namespacePrefix should be just prefix
In 10.9.7, graphForNG should be just graph
10.9.8 does not document bNode
OWLOntology::owlUniverse is not documented � in fact it�s in 11.7.2 which should be moved
Question section 11.2.3 RDFSLiteral (Augmented)
There are still mentions of OWL Full and OWL DL
Constraint [1] of AnnotationProperty still has URIReference and RDFLLiteral
OWLOntologyProperty is obsolete
OWLAllDifferent should specialize ClassExpression not OWLClass
The xmi for the RDF profile has been substantially simplified for ODM 1.1, but the section of the RDF profile in the document does not match the xmi. This should be corrected in the 1.2 RTF.
This section describes problems with MOF/UML due to the need to work around multiple classification issues, which was fixed by SMOF. The specification needs to be revised to (1) state that no changes are required to other OMG specs, (2) update references and add SMOF, and (3) add a discussion of the need for SMOF in the design principles section (section 7)
The current conformance section includes requirements that have been made invalid by removal of the RDFWeb package in the metamodel, among other things. The entire section needs a rewrite to reflect changes made for RTF 1.1.
The set of implementations referenced is out of date and should be revised to discuss current implementations.
The diagram (Figure 9.1) and related text is out of date given the revisions made to the ODM metamodels by the 1.1 RTF.
Annex D has several OWL examples that use the rdf:resource attribute in which the attribute's value is, I think, meant to be prefixed with a "#". For example, in Table D-7, <rdfs:domain rdf:resource="Course"/> should be: <rdfs:domain rdf:resource="#Course"/>
The second sentence of Annex D.2.2 reads as follows: A class in OWL is a set of zero or more instances. An OWL class consists of individuals, not instances. The sentence should be changed to use OWL terminology.
This issue addresses a number of editing problems uncovered in the ODM 1.1 RTF report, ptc/2013-08-01.
Many of the challenges uncovered during AB review of the submitted convenience documents (ptc/2013-08-02 and ptc/2013-08-03) and related ODM 1.1 RTF report, ptc/2013-08-01, are related to the order in which the issues must be applied, and confusion around the resulting section and figure numbers. Other minor errors in the editing instructions in the original resolutions were also uncovered. The set of issues/changes identified below corrects problems in the editing instructions and provides section and figure numbering maps to assist with ensuring that the resulting specification is as intended. Editing changes are ordered by chapter in the ODM 1.1 specification and within chapter by OMG issue number. In addition, one table detailing the section mapping for Chapter 10 and several tables detailing figure and section mapping for Chapter 14 are provided to aid in understanding and provide the definitive naming for section headings in particular.
This issue addresses a number of editorial changes made to the ODM specification by the ODM 1.1 RTF against the originally submitted convenience documents, ptc/2013-08-02 and ptc/2013-08-03.
A number of changes were made over time to the profiles for RDF and OWL in particular that were not synchronized / revised as needed with respect to some of the earlier resolutions. Some of these were caught in the process of editing the convenience document, but are not reflected in existing resolutions. This resolution provides a blanket mechanism for capturing these changes.
n table A-4, the cell in the second column of row 1 contains the stereotype �rdfsContainerMembershipProperty�. This name has been changed to �containerMembershipProperty� in version 1.1.
Line 87 of the OWL profile (https://www.omg.org/ODM/20130801/OWLProfile.xml) has an element named annotationProperty. This is the v1.0 name. In 1.1 the name is owlAnnotation (cf. Section 14.2.3.1).
Fig. 14.3 shows the first 3 properties of �statement� named RDFsubject, RDFpredicate, and RDFobject. Section 14.1.3.9 lists properties named subject, predicate, and object. The names need to be consistent.
The Description in Section 10.2.2 states that ReferenceNode, BlankNode, and Literal form a complete and disjoint covering of Node. That means Node is an abstract class. For consistency with the �node� stereotype (Section 14.1.3.5), Section 10.2.2 should describe it as such.
The association between Document and Triple in Figure 10.8 shows multiplicity 0..* for the "triple" role. In Section 10.8.1, the association's multiplicity is 1..*.
The "Stereotype and Base Class" section of 14.2.4.3 states that the base class of �owlImports� is UML::PackageImports. The class name is PackageImport (i.e., it doesn't end with "s").
In the GraphicalRepresentation section of owl:equivalentClass, the text says the representation is a dashed line, but Figure 14.41 shows a solid line.
Figure 14.19 shows an association labeled "Imports" between packages OWL and RDF. Should it be a dependency stereotyped �import�? That's what the UML specifications describe.
This is a bulk report of minor problems I've identified in the specification. The following is a CSV-format list that can be read by a spreadsheet application. Page,Location,Problem,Fix 38,"Section 10.2.6, Description, paragraph 1","""RFC3986"" should be ""RFC 3986"", consistent with ""RFC 3987"" in the same paragraph.", 38,"Section 10.2.6, Description, paragraph 2","""RFC3986"" should be ""RFC 3986"".", 38,"Section 10.2.5, Constraints, paragraph 1, sentence 2","""However, in any case"" is redundant.","Replace ""However, in any case,"" with ""However,""." 44,"Section 10.5.2, Semantics, paragraph 2",The sentence beginning on the third line is run-in and the second part is incomplete.,"Change the sentence to ""Such features may in the future be provided to support, for example, more elaborate datatype conditions.""" 50,"Section 10.8, paragraph 1",Replace hyphen with dash in line 3., 50,"Section 10.8, paragraph 1",Missing comma.,"Change ""prefixes and URIs"" to ""prefixes and IRIs,""." 51,Last paragraph,Missing period at end of sentence., 53,"Section 10.8.2, Description, paragraph 1","The article modifying ""IRI"" is incorrect.","Change ""a IRI"" to ""an IRI""." 54,"Section 10.8.2, Constraints",Remove the quotation marks around [XMLNS]., 56,"Section 10.8.8, Associations, bullet 1","Change ""NameSpace"" to ""Namespace"". Missing period at end of sentence.", 73,"Section 11.3.8.1, Description, First paragraph",Missing period at end of last sentence., 77,"Section 11.3.8.9, Constraints, paragraph 1",Missing period at end of sentence., 82,"Section 11.5, title",Replace hyphen with dash., 83,"Section 11.6, paragraph 2",The first sentence is run-in.,"Change ""data values,"" to ""data values:""." 173,"Section 14.2.5, paragraph 1","On the last line, replace ""classes,"" with ""classes"".", 174,"Section 14.2.5.1, Description, paragraph 2, sentence 1",The use of passive voice reduces specificity.,"Change owl:Class is defined as a subclass of rdfs:Class. to [OWL SS&FS] defines owl:Class as a subclass of rdfs:Class." 199,"Section 14.2.6.3, Description, paragraph 1",The first sentence is missing a comma.,"Change ""in the profile"" to ""in the profile,""." 207,"Section 14.2.7.5, Description, paragraph 1","The use of commas in the first sentence decreases readability: it's not immediately obvious how to read ""OWL properties"".","Change ""OWL properties"" to ""OWL, properties""." 207,"Section 14.2.7.5, Stereotype and Base Class, paragraph 1",The first sentence is run-in.,"Change ""No stereotype,"" to ""No stereotype;""."
In ODM 1.1, partial support for hasSelf property restrictions were added to the metamodel and profile for OWL. This support needs to be fully integrated, and at a minimum, an additional stereotype should be provided in the profile.
A number of stereotypes are given in section 14.2.5.3 for dependencies to be used with restrictions are incompletely defined in ODM 1.1.
The ODM Metamodel and Profile should support OWL2 n-ary datatype hook and universal and existential restriction on n-ary data ranges
Pairwise disjoint classes and disjoint unions are only partially supported in the ODM 1.1. Representation should be completed for both the OWL metamodel and profile.
The OWL 2 top and bottom object and data properties should be represented in the metamodel and profile (possibly as additions to the libraries in Annex A).
These datatypes were added in OWL 2, and should be supported in the metamodel, profile and related libraries.
Inverse property expressions were new in OWL 2 and support for them needs to be added to the ODM specification.
Property chains were added as a feature of OWL 2 and need to be supported in the ODM metamodel and profile.
Representation of Axioms OWL2 uses Axioms to represent several capabilities, whereas ODM has them either as binary associations or not at all. In OWL these axioms are represented as a blank node so should have a metamodel element: that is necessary to allow the statement itself to be associated with an ontology/document. ODM has OWLAllDifferent which inherits from OWLClass which does not make sense. In the metamodel there should be a top level class representing Axiom with the following subclasses: - DifferentIndividuals (replaces association DifferentIndividual and class OWLAllDifferent) - SameIndividual (replaces association SameIndividual) - EquivalentClass (replaces association EquivalentClass) - DisjointClasses (replaces association DisjointClass) - EquivalentProperty(replaces association EquivalentProperty) - DisjointProperties (new)
Representation of Axioms OWL2 uses Axioms to represent several capabilities, whereas ODM has them either as binary associations or not at all. In OWL these axioms are represented as a blank node so should have a metamodel element: that is necessary to allow the statement itself to be associated with an ontology/document. ODM has OWLAllDifferent which inherits from OWLClass which does not make sense. In the metamodel there should be a top level class representing Axiom with the following subclasses: - DifferentIndividuals (replaces association DifferentIndividual and class OWLAllDifferent) - SameIndividual (replaces association SameIndividual) - EquivalentClass (replaces association EquivalentClass) - DisjointClasses (replaces association DisjointClass) - EquivalentProperty(replaces association EquivalentProperty) - DisjointProperties (new)
ODM metamodel needs a Package concept for managing a structure for ontologies, akin to the use of UML Packages in the Profile. In fact, the use of UML Packages in ontology models is outside the documented profile. There is nothing to say, for example, that the package structure should mirror the URI structure and/or whether it matters whether they differ. Despite the fact that the RDF/OWL languages do not have Package, they do make use of folders/directories in wither filestore or on the web. And ontologies like FIBO now have metadata at the package/folder level but neither the metamodel nor the profile provide any place to hang these. Finally packages provide a much-needed scoping mechanism for applying various operations � which become increasingly impractical as the number of leaf-level ontologies has already exceeded 400 for FIBO
I was working on the FIBO UML files and came across some XMI issues with the ODM XMI[PJR] for RDFLibrary: It has an erroneous import of OWLProfile and it uses .xml instead of .xmi for the RDFProfile. Proposed resolution: The lines at 402 of RDFLibrary.xmi are currently: <uml:Package xmi:id="_16_6_1_15100de_1266442802908_497608_344" name="rdf" URI="https://www.omg.org/spec/ODM/20131101/RDFLibrary.xmi"> <profileApplication xmi:type="uml:ProfileApplication" xmlns:RDFProfile="http://www.magicdraw.com/schemas/RDFProfile.xmi" xmi:id="_RDFProfile-Application" xmlns:OWLProfile="http://www.magicdraw.com/schemas/OWLProfile.xmi"> <appliedProfile href="https://www.omg.org/spec/ODM/20131101/RDFProfile.xml#_12_5_1_137b03ac_1193948135234_354269_2454"/> And should be as follows: <uml:Package xmi:id="_16_6_1_15100de_1266442802908_497608_344" name="rdf" URI="https://www.omg.org/spec/ODM/20131101/RDFLibrary.xmi"> <profileApplication xmi:type="uml:ProfileApplication" xmi:id="_RDFProfile-Application"> <appliedProfile href="https://www.omg.org/spec/ODM/20131101/RDFProfile.xmi#_12_5_1_137b03ac_1193948135234_354269_2454"/>