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?

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.

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

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.

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).

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).

Anonymous Classes. Section 16.4.4.3 (Anonymous Class to Class) can translate blank nodes to anonymous classes in UML.

Ontology Properties. Section 16.4.3.2 (Ontology Properties to Comments) should use dependencies for some of the translations. See the profile (Chapter 14).

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

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.

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.

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).

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".

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.

Multiplicity. Section 16.3.7 (Multiplicity), the translation can also be to OWL FunctionalProperty or InverseFunctionalProperty if the multiplicity is 1.

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.

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).

Boolean combination. In Section 16.5.1 (Predicate Definition Language), third sentence, UML supports the equivalent of unionOf.

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.

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.

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.

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.

Design of RDF metamodel for rdf:Statement, triple, and graph controversial in semantic web community. In November-December 2007, there were discussions of the ODM metamodels for RDF and OWL
within the OWL working group of the W3C. It became clear from these discussions that key OWL
and RDF experts were surprised and not particularly happy with how ODM modeled the RDF data
model and reification vocabulary. These portions of the RDF specification describe the fundamental
data model for RDF assertions: Triple with subject, predicate and object properties; Graphs for
collecting triples as sets of assertions; and a reification vocabulary enabling assertions about triples
themselves. Pragmatic design decisions were made for the ODM metamodel which merged support
for triples and the reification vocabulary into a single class, Statement, and merged support for a
non-standard extension for RDF, named graphs, with graph.
Unfortunately, the reification vocabulary
for RDF has proved problematic and controversial, and because these aspects are key to the semantics
of RDF, some are very sensitive about how they are modeled.
To encourage better acceptance of ODM in the semantic web community the RDF metamodel should
be changed to correspond with expectations of SemWeb experts. Triples, Statements, Graphs and
Named Graphs should all be modeled with separate constructs with non-normative and non-standard
elements noted. The OWL Ontology model which uses these constructs should be modified to use the
fundamental rdf forms: triple and graph, and should do this in a way consistent with the RDF
specifications, e.g., RDF triples in a graph are considered unordered (a set).

Factor the Statements diagram in Figure 10.2 in RDFBase into 3 diagrams: Graph Data Model, Reification, and Graphs. This separates rdf triples from statements about them and creates a separate construct for Named Graph since it is not a part of the current rdf specification. The diagram for rdf:statements is now called Reification (rdfs calls this the reification vocabulary), the Graph Data Model diagram depicts triples, and the Graphs diagram depicts RDF graphs and named graphs. New subsections in RDFBase will be added for RDF Reification and Graphs: Reification after the Literals section and Graphs after Reification.
Places in odm metamodels which extended or otherwise referred to statements are changed to refer to triples. This includes the Documents model in the RDFWeb package and the Ontology model in OWLBase.
Changes include:
§ Changing section 10.2 from describing RDF Statements to describing Triples.
§ Revising figure 10.2 to describe triples, moving RDF Graph to 10.5, eliminating Reification kind, and introducing a supertype which is a complete and disjoint covering for URIReferenceNode, BlankNode, and RDFLiteral called Node for RDFSubject and RDFObject roles from Triple.
§ Adding a new section 10.4 called RDF Statements to describe the RDF reification vocabulary. Including a diagram describing Statements and its relationship to Triples.
§ Adding a new section 10.5 called Graphs describing rdf graphs and named triples. This includes a Graphs diagram depicting RDF Graphs and Named Graphs as separate classes and including associations on named graphs to for equivalentGraphs and subGraphs per the seminal named graphs reference.
§ Revising Documents and Namespaces in the RDFWeb package to refer to triples instead of statements and revising the Documents diagram accordingly.
§ Revising OWL Ontology section and diagram in the OWLBase package to refer to triples instead of statements and to eliminate

attribute for sets of triples.

The RDF/S and XML Schema library has some metalevel mixups I think, see
comments. Can discuss, should be easy to fix.b

Replace Annex A, in its entirety with the attached PDF revision. Revisions include:
§ Revised Table 30 to correct meta-level concerns raised in issue 11304
§ New Table 31 to provide library for RDF profile for XML Schema Datatypes
§ New Table 32 representing the missing model library for the OWL profile noted in issue 10840

UML Thing 1. In 16.2.2 (Class and Property - Basics), second paragraph, starting at "The main difference" overstates the difference. The ODM defines a UML model library that includes Thing, which is not "unusual" or "problematic" in any way. The most that can be fairly said is that UML does not currently standardize its own model library.

Remove the text about this being problematic in UML.

Concretely represented. In Section 16.2.2 (Class and Property - Basics), second paragraph under Figure 16.5, says OWL instances are "concretely represented". What does this mean?

Change the text to use less ambiguous wording.

M0 implementation of a class. In Section 16.2.1 (Class and Property - Basics), paragraph underneath Table 16.5, the first sentence refers to M0 as an implementation, but in these examples, they are only models of instances, not implementations on a particular platform.

Replace the word implementation with representation.

Page 188 formatting. In 16.2.2 (Class and Property - Basics), the last few paragraphs on page 188 should be one paragraph.

Change the formatting of the text near the bottom of page 188 which begins "The translation from UML to OWL is straightforward" to the end of the page to make this clearly all one paragraph.

Table 16.6. In 16.2.2 (Class and Property - Basics), Table 16.6 (Simple Model Classes Translated to OWL), since the OWL column does not include properties, the owned attribute column can be removed. Or an OWL properties column can be added. It's confusing to have one and not the other.

Remove column with heading "Owned attributes" from Table 16.6 since the OWL analog to these attributes were not shown in this table. Note that the UML Owned attributes to owl:Property mapping for these classes is shown in table 16.7 on the next page of the document.

Modeled instances. In Section 16.2.2 (Class and Property - Basics), second paragraph, parentheical remark, insert "not" before "equivalent". because multiple M0 instances can conform to a single M1 instance specification. It would be good to expand this to say that for the purposes of discussion, instance specification used to explain M0 instances, for example, using the term "slot".

Fix the text to correct the statement about instances in a model library.

Extents. In Section 16.2.2 (Class and Property - Basics), second paragraph, first sentence, the extent is not an M0 object. I think this is trying to say the extent consists of M0 objects.

Fix the text to say that the extent consists of M0 objects.

Class = set of instances. In Section 16.2.2 (Class and Property - Basics), first paragraph, second sentence, an OWL class can exist without insances, so it is not equivalent to a set of instances.

The statement was meant to include the empty set. The sentence was slightly revised to make this clearer.

Table 16.5. Table 16.5 (Example Course Instance) has a column "title", which I assume should be "description" to be consistent with the example in the previous section.

Fix the table to match the model specified in the earlier section.

Chapter 16 purpose. In Chapter 16 (Mapping UML to OWL), first sentence, starting with "in part" says the chapter is trying to justify using ODM rather than UML. This of course is not the point of a comparison, which is to be informative and let readers make their own choices, including the option to use both with mappings.

Replace the entire first sentence of 16.1 Introduction as described below.

Section 8.2 wording. In Section 8.2 (Why Not Simply Use or Extend the UML 2.0 Metamodel?), next to last paragraph, first sentence, remove "Additionally". The paragraph is about a similarity between UML and OWL, rather than a difference as the earlier paragraphs were.

Replace text as indicated.

RestrictionClass constraint [1]. In 14.2.5.3 RestrictionClass, Constraints. [1], the last word should be "restriction" rather than "constraint".

Replace text as indicated.

Annex A missing model library. Appendix A is missing the UML Profile for OWL that the first paragraph of Appendix A sayss it contains. Last sentence refers to "Table xx+1"

Replace Annex A, in its entirety with the attached PDF revision. Revisions include:
§ Revised Table 30 to correct meta-level concerns raised in issue 11304
§ New Table 31 to provide library for RDF profile for XML Schema Datatypes
§ New Table 32 representing the missing model library for the OWL profile noted in issue 10840

Classes and properties wording. In Section 16.2.1 (UML Kernel), Under Figure 16.1, sixth bullet, the sentence combines optional and mandatory multiplcity (may or may not, one or more). Properties may be optionally owned by a single class, elements cannot be owned by more than one other element

Author agreed with the issue. A replacement sentence was drafted leading to the fix below.

UML References. The UML 2 reference on page 4 can be replaced with version 2.1.1, formal/07-02-05, http://doc.omg.org/formal/07-02-05 The UML Infra reference can be replaced with version 2.1.1, formal/07-03-06, http://doc.omg.org/formal/07-02-06

Replace references as indicated.

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).

Close no change. It was previously resolved in FTF2 in response to issue 10869

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.

Replace text as described below

In Annex A, RDFSContainer-MembershipProperty should be moved to the UML Profile chapter as a stereotype based on UML:Property.

In Annex A, Section A.3, UML Profile for RDF Library Elements, in Table A.4 - Foundation Library (M1) for Use with the RDF Profile, remove the row (entire row in the table) describing RDFSContainerMembershipProperty.
In Chapter 14, Section 14.1.8 Containers and Collections, insert a new section defining a stereotype for rdfs:ContainerMembershipProperty, as given below

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.

Close, no change. The issue / section in question is in reference to the RDF profile, not the OWL profile, but Thing is only defined for use in OWL. There is no equivalent “class of everything” in the RDF language – rdfs:Resource is the closest, but its semantics are closer to those of an individual than a class.

Revised Text:
None
Disposition: Closed, no change

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".

Replace text as described below.

Universal Superclass. Section 16.4.5.2 (Universal Superclass) should also refer to Annex A.

Replace text as described below

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.

Replace text as described below

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.

Delete section 16.6.4 and Replace text in section 16.6.5 as described below.

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.

Delete section 16.6.4 and Replace text in section 16.6.5 as described below

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

Replace text as described below

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?

Replace text as described below.

Disjoint. In 16.2.3 (More Advanced Concepts), sixth paragraph, parenthetical remark should note that with UML Thing the same is true in UML).

Replace text as described below. (Note: this issue actually refers to the seventh paragraph)

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.

Replace text as described below. (Note: this issue actually refers to the sixth paragraph)

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).

Remove last row of table 16.11
Replace the second to last line in table 16.12 with the following:
Classes as instances (in OWL Full)

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.

Delete paragraph in section 16.2.3 after the XML starting with the words “UML allows a property”. It misrepresents the kinds of things that can be done in OWL and what can be done with a UML composition.

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

Add text as described below

Other OWL. In Section 16.5.3 (Other OWL Developments), should refer to OWL 1.1.

Delete text as described below

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.

Replace text as described below

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).

Close no change.

Names, UML namespaces. In Section 16.5.2 (Names), next to last paragraph, namespaces are supported at all metalevels in UML/MOF.

Delete text as described below

Table 16.12, disjoint. In 16.2.3 (More Advanced Concepts), Table 16.12, last row. UML supports declaring disjoint classes.

Replace text as described below.

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

Close no change

Herbrand semantics. In 16.2.3 (More Advanced Concepts), under the XML example, the paragraph starting "In UML, there is a strict separation" is incorrect. The M0 level of UML can be real world individuals, not just software implementations (this is called an "analysis" application). Even when they are software implementations, they do not need to be specific ones, such as an SQL database manager. The last sentence is fine because of the qualification. The previous ones makes it seem like the qualification is always the case. The entrie next paragraph seems to also to mit the qualification, and I think can be dropped, since the presence of particular kinds of nulls in databases not relate to UML as generally applied. The last sentence of that paragraph can be used as a summary of the discussion.

Replace text as described below.

Constants. In 16.2.3 (More Advanced Concepts), under the XML example, paragraph starting "It is not required", the same is true in UML.

Replace and append text as described below.

Symmetric. Section 16.3.5 (Binary Association To Object Property), second paragraph says that binary associations with the same type on both ends translate to symmetric properties in OWL. This isn't correct. For example, an association that has Animal on both ends, with ends named "chases" and "chased by", doesn't mean that if animal A chases animal B, that animal B chases animal A. It means that animal B is chased by animal A

Replace text as described below.

Restriction. In 16.2.3 (More Advanced Concepts), eigth paragraph, first sentence should clarify that the restriction is recorded in the domain in the XML format, but is a restriction on the range. In particular, "relation" should be expanded to clarify that the resriction applies to each domain individual, not the relation as a whole (ie, not all tuples).

Edit the text in the ninth paragraph of section 16.2.3 as described below.

N-aries. In 16.2.2 (Class and Property - Basics), second paragraph under Figure 16.3, association classes are not the same as naries. The translation given to N-ary associations is incomplete, because n-ary associations have multiplicities. These will not translate to cardinalities of binaries, at least not without a constraint to ensure there is only one instances of the association class in OWL for each link in UML.

Replace text as described below.

Behavioral Features. In Secton 16.6.1 (Behavioral Features), first paragraph is about a number of things other than behavioral features, and much of it is incorrect or uses incorrect terminology. Behavioral features only declare capabilities or services, not resources. They aren't the "program" that implements the service (called Behavior in UML). Behavioral features can be used in OCL that defines a derivation of a property, but the behavioral feature isn't directly related to the derived property. Operations include the parameters (including return value). A "method" in UML is the behavior that implements the operation on a particular class. Responsibility in UML is only a standard stereotype of a usage dependency. It isn't a well-developed part of UML class modeling. Qualified associations are more accurately described as a special kind of ternary relation. An abstract can have operations and methods like any other class. Abstract classes cannot have direct instances. Interfaces specify features of classes, including operation features. They aren't interfaces of operations themselves.

Replace text as described below

All/SomeValuesFrom. In 16.2.3 (More Advanced Concepts), under the XML example, the paragraph starting "An OWL property can have", the translation to UML for allValuesFrom restrictions is property subsetting. There is no translation for someValuesFrom unless using the UML Profile for OWL.

Replace text as described below

Transitive closure. In 16.2.3 (More Advanced Concepts), under the XML example, the paragraph starting "Note that a consequence of", seems to have lost its context. It doesn't appear related to the paragraphs around it. If it is, this should be clarified.

Replace and append text as described below.

Name as instance. In Section 16.2.2 (Class and Property - Basics), paragraph underneath Table 16.5, the second sentence says a name can be an instance, but a name is usually a property or a string, not an instance. The third sentence says if name is the identifer, then "the remainder of the slots could be filled dynamically from other properties of the class". What does dynamically mean? It appears this is going into relational modeling, like the previous section does.

Delete paragraph underneath table 16.5.

Classes and properties. In Section 16.2.1 (UML Kernel), Under Figure 16.1, fifth bullet, properties do not implement classes (the "implementation" usually refers to how the model is translated to a platform). UML properties have the same semantics as OWL properties. Classes do not necessarily have properties. See multiplicity from Class to Property in the UML spec.

Replace text as described below

Metalevels. In Chapter 16 (Mapping UML to OWL), third paragraph, first sentence, before the bullets, should refer to "models", rather than UML models. It can also refer the reader to more examples and explanation in Sections 7.9 through 7.12 of [UML Infrastructure, http://doc.omg.org/formal/07-02-06

Replace text as described below

Annex D.2, OWL Full. In Annex D.2, under Figure D1, the second sentence says that OWL Full must be used to subclass OWL class. Why can't OWL class be subclasses in OWL Lite or DL? All instances of subclasses of OWL:Class are also OWL classes, and presumably wouldn't violate the constraints of OWL Lite or DL just because of the subclassing.

No Data Available

Annex D.4 typo. Annex D.4, second sentence, "OntoClear" should be "OntoClean".

Replace text as requested.

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.

Replace text as described below

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.

Issue actually references the second paragraph after table 16.7. Replace text as described below.

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.

Closed to the resolution of issue 18836, delete Annex D, "Extending the ODM" from the specification.

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")

Replace text as described below.

Formal structure. Under Figure 16.1, the first sentence refers to "formal structure". Should explain what this is. Is it the metamodel?

Replace text as described below.

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

Closed to the resolution of issue 18836, delete Annex D, "Extending the ODM" from the specification

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.

Delete last sentence of the fifth paragraph. (Note: this issue actually refers to fifth paragraph)

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.

Replace text as described below. (Note: This issue actually refers to the forth paragraph.)