Issue 10839: UML References
Issue 10840: Annex A missing model library
Issue 10841: RestrictionClass constraint [1].
Issue 10842: Section 8.2 wording
Issue 10843: Annex D.2, OWL Full
Issue 10844: Figure D.3 notation
Issue 10845: Annex D.4 typo
Issue 10846: Annex D.4 sets
Issue 10847: Chapter 16 purpose
Issue 10848: Metalevels
Issue 10849: Figure 16.1 incomplete
Issue 10850: Formal structure
Issue 10851: Classes and properties
Issue 10852: Classes and properties wording
Issue 10853: Associations
Issue 10854: Class = set of instances
Issue 10855: Extents. In Section 16.2.2
Issue 10856: Modeled instances
Issue 10857: Table 16.5
Issue 10858: M0 implementation of a class
Issue 10859: Name as instance
Issue 10860: Concretely represented
Issue 10861: UML Thing 1
Issue 10862: Table 16.6
Issue 10863: Distinct associations, ownedAttribute associations
Issue 10864: Distinct associations, restrictions
Issue 10865: Identifiers
Issue 10866: Associations
Issue 10867: Subproperites and redefintion
Issue 10868: Page 188 formatting
Issue 10869: N-aries
Issue 10871: Association member ends
Issue 10872: Table 16.9 and Naries
Issue 10873: Translation of binary associations.
Issue 10874: UML Thing 2
Issue 10875: Individuals
Issue 10876: Disjoint.
Issue 10877: Classes of classes
Issue 10878: Restriction.
Issue 10879: Mandatory properties
Issue 10880: Constants
Issue 10881: Herbrand semantics
Issue 10882: Transitive closure
Issue 10883: All/SomeValuesFrom
Issue 10884: Derivation.
Issue 10885: Table 16.10
Issue 10886: Table 16.11
Issue 10887: Table 16.12, Thing
Issue 10888: Table 16.12, AllValuesFrom
Issue 10889: Table 16.12, classes as instances
Issue 10890: Table 16.12, disjoint
Issue 10891: Inferring subsumption
Issue 10892: Boolean combination
Issue 10893: Names, unique names.
Issue 10894: Names, UML namespaces
Issue 10895: Other OWL
Issue 10896: Behavioral Features
Issue 10897: Complex Objects
Issue 10898: Keywords
Issue 10899: Profiles
Issue 10900: UML to OWL, OWL-DL
Issue 10901: UML to OWL, Table 16.10
Issue 10902: Object identification in UML
Issue 10903: Symmetric
Issue 10904: N-aries. Section 16.3.6
Issue 10905: Multiplicity.
Issue 10906: navigableOwnedEnd
Issue 10907: Enumeration literals
Issue 10908: Individuals, mapping
Issue 10909: complementOf and disjointWith
Issue 10910: Multiple Domains or Ranges for Properties.
Issue 10911: Ontology Properties
Issue 10912: Anonymous Classes
Issue 10913: Universal Superclass
Issue 10914: Constructed Classes
Issue 10915: Range Restriction Restriction Classes
Issue 10916: Range Restriction Restriction Classes
Issue 10917: Properties in OWL
Issue 11099: Constraints in the RDF Metamodel Chapter (10) should be specified in OCL
Issue 11100: Constraints in the OWL Metamodel Chapter (10) should be specified in OCL
Issue 11101: Common Logic Metamodel is out of sync with the ISO FDIS CL specification
Issue 11102: Mapping from Common Logic to OWL should be revised
Issue 11103: Role name of superClass
Issue 11104: Role name of superProperty
Issue 11105: Bi-directional URIReferenceForNamespace association
Issue 11106: Cardinality of OWLInverseOf
Issue 11107: Set value for annotation property in UML profile for OWL
Issue 11304: The RDF/S and XML Schema library has some metalevel mixups
Issue 11320: Thing in the Profile
Issue 11321: RDFSContainer-MembershipProperty
Issue 12386: RDFSDatatype uriRef Property Multiplicity Issue
Issue 12387: Specification: RDFSisDefinedBy text issue
Issue 12388: Specification: RDFSseeAlso text issue
Issue 12389: Specification: RDFType text issue
Issue 12390: Specification: RDFSComment optional representation as plain literal
Issue 12391: OWL Annotation properties are impoverished in the OWL profile
Issue 12392: URIReferenceNode definition is misplaced in the specification
Issue 12393: URIReferenceNode constraint text
Issue 12394: OWL Model Library elements are missing owl:versionInfo attributes
Issue 12395: OWL Cardinality Constraints text revision
Issue 12396: OWL Properties have conflicting definitions
Issue 12397: No stereotype for OWL individuals
Issue 12398: Definition of RDF Property and its use in the figures is inconsistent
Issue 12399: Text describing owl:someValuesFrom and owl:hasValue limits implementations
Issue 12400: Examples provided for owl:inverseOf are misleading
Issue 10839: UML References (odm-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Clarification
Severity: Minor
Summary:
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
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"
RestrictionClass constraint [1]. In 14.2.5.3 RestrictionClass, Constraints. [1], the last word should be "restriction" rather than "constraint".
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.
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
Annex D.4 typo. Annex D.4, second sentence, "OntoClear" should be "OntoClean".
Defer to 2nd FTF
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
Defer to 2nd FTF
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.
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
Defer to 2nd FTF
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.
Defer to 2nd FTF
Formal structure. Under Figure 16.1, the first sentence refers to "formal structure". Should explain what this is. Is it the metamodel?
Defer to 2nd FTF
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.
Defer to 2nd FTF
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
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.
Defer to 2nd FTF
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.
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.
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".
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.
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.
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.
Defer to 2nd FTF
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?
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.
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.
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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")
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
Page 188 formatting. In 16.2.2 (Class and Property - Basics), the last few paragraphs on page 188 should be one paragraph.
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
Disjoint. In 16.2.3 (More Advanced Concepts), sixth paragraph, parenthetical remark should note that with UML Thing the same is true in UML).
Defer to 2nd FTF
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".
Defer to 2nd FTF
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).
Defer to 2nd FTF
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
Defer to 2nd FTF
Constants. In 16.2.3 (More Advanced Concepts), under the XML example, paragraph starting "It is not required", the same is true in UML.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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).
Defer to 2nd FTF
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).
Defer to 2nd FTF
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).
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
Table 16.12, disjoint. In 16.2.3 (More Advanced Concepts), Table 16.12, last row. UML supports declaring disjoint classes.
Defer to 2nd FTF
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
Defer to 2nd FTF
Boolean combination. In Section 16.5.1 (Predicate Definition Language), third sentence, UML supports the equivalent of unionOf.
Defer to 2nd FTF
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.
Defer to 2nd FTF
Names, UML namespaces. In Section 16.5.2 (Names), next to last paragraph, namespaces are supported at all metalevels in UML/MOF.
Defer to 2nd FTF
Other OWL. In Section 16.5.3 (Other OWL Developments), should refer to OWL 1.1.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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?
Defer to 2nd FTF
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
Defer to 2nd FTF
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.
Defer to 2nd FTF
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
Defer to 2nd FTF
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).
Defer to 2nd FTF
Multiplicity. Section 16.3.7 (Multiplicity), the translation can also be to OWL FunctionalProperty or InverseFunctionalProperty if the multiplicity is 1.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
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).
Defer to 2nd FTF
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.
Defer to 2nd FTF
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?
Defer to 2nd FTF
Ontology Properties. Section 16.4.3.2 (Ontology Properties to Comments) should use dependencies for some of the translations. See the profile (Chapter 14).
Defer to 2nd FTF
Anonymous Classes. Section 16.4.4.3 (Anonymous Class to Class) can translate blank nodes to anonymous classes in UML.
Defer to 2nd FTF
Universal Superclass. Section 16.4.5.2 (Universal Superclass) should also refer to Annex A.
Defer to 2nd FTF
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).
Defer to 2nd FTF
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".
Defer to 2nd FTF
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).
Defer to 2nd FTF
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
Defer to 2nd FTF
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.
Defer to 2nd FTF
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.
Defer to 2nd FTF
Specification: Ontology Definition Metamodel FormalNumber: ptc/06-10-11 Section: 12 Summary: Common Logic Metamodel is out of sync with the ISO FDIS CL specification. 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 include text and diagram / model / xmi changes, which, although minor, should be resynchronized now that the ISO standardization process is complete
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.
Defer to 2nd FTF
In section 10.4.1, the role name of superClass in ClassGeneralization is confusing. It might be changed to subClass
In section 10.5.1, the role name of superProperty in PropertyGeneralization is confusing. It might be changed to subProperty
In section 10.7.3, URIReferenceForNamespace should be changed to two uni-directional associations between URIReference and Namespace. In the current model, if two URIReference have the same Namespace, it could not be represented.