Issues for 2nd Ontology Definition Metamodel Finalization Task Force

List of Open Issues. Other options: All Issues; Closed Issues.

(red=unresolved; yellow=pending Board vote)

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

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

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

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

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

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: 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 14.2.3.1, it is not clear on how to set values for annotation property

Defer to 2nd FTF

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.

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

The uriRef property is defined in the specification as a LiteralString [0..*], which is incorrect. The uriRef property is required to have value, and thus the multiplicity should be [1..*]

The text of the Constraints section for RDFSisDefinedBy requires revision (per ODM FTF2 meeting minutes of Feb 6, 2008): delete (a) "i.e., the classifier owning the dependency", (b) "i.e., the type of the dependency", and (c) the end of the last sentence, starting with ", or, at a minimum ..." to the end

The text of the Constraints section for RDFSseeAlso requires revision (per ODM FTF2 meeting minutes of Feb 6, 2008): delete (a) "i.e., the classifier owning the dependency", (b) "i.e., the type of the dependency", and (c) the end of the last sentence, starting with ", or, at a minimum ..." to the end

The text describing RDFType requires revision (per ODM FTF2 meeting minutes of Feb 6, 2008): "This can be represented in a UML model by the relation between an instance specification and its classifiers" (fix second sentence)

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)

Per ODM FTF2 meeting minutes of February 20), OWLAnnotationProperty is defined in the profile as having a base class of UML::Property, whereas RDF properties have base classes including UML::Property and UML::AssociationClass. Add AssociationClass to the set of base classes for the <<owlAnnotation>> stereotype.

Section 14.1.4.1 URIReferenceNode should be moved to 14.1.3.7 -- it is "buried" under section 14.1.4 ReificationKind for some unknown reason.

Modify the text for the first constraint in section 14.1.4.1 URIReferenceNode from "The uriRef:String property, inherited from ..." to "The uriRef property, inherited from ..."

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 the ODM FTF2 meeting minutes of February 20th: Cardinality constraints -- the second paragraph of the description states: "Additionally, isOrdered = false on OWL properties, and isUnique = true on owl properties...". These "constraints" are not specified in the owl properties section (14.2.6) - should they apply to all owl properties, or only to cardinality constraints? According to Conrad, this text should apply to all RDF and OWL properties, but it comes from the text on multiplicities in UML, which is why it landed in this section of the document. Note that it does occur under the rdfProperty section of the profile specification, so it does apply to all properties ... thus we might remove the "OWL" from the sentence for further clarification.

From the ODM FTF2 meeting, Burlingame meeting: In 14.2.6.1 owl:DatatypeProperty specifies base class of AssociationClass AND Property. 14.2.6.2 and 14.2.6.3 specify a base class of AssociationClass OR Property. What is it, AND or OR? The text for section 14.2.6.2 owl:ObjectProperty and 14.2.6.3 owl:Property, defining the base class and stereotype is wrong - it should be AND. 

From the ODM FTF2 meeting minutes, February 20th: There is currently no stereotype available for individuals in the OWL Profile. Participants agreed that we would like to have a stereotype <<owlIndividual>> on UML instance specifications for individual, and would want an additional constraint saying that such an instance specification would only have one value, i.e., that it specifies a single individual; also, what if we have a singleton, but not the corresponding individual? We would still translate the singleton class to an OWL individual in this case ... see issue 10908 (related issue in the mapping chapter).

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.1.7, In Figure 4.3 the line is an "association". However, the specified base classes are "AssociationClass" and "Property". To duplicate this example in Enterprise Architect, it was necessary to define a profile in which the rdfProperty stereotype extend the "Association" metaclass.

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