The ODM Metamodel and Profile should support OWL2 reflexive, irreflexive and asymmetric properties

see pages 203 - 205 of ptc/2013-12-01 for details

There are ontologies such as Dublin Core which consist of RDFS Classes, but, for various reasons, also have an OWL Ontology. Currently the ODM metamodel does not have a way to represent this association – only OWL Classes can be linked to an OWL Ontology (the ODM Profile can easily reuse the UML association between Package and PackagedElement but this usage should really be documented).

This is addressed by the association ResourcesGrouped between Namespace and RDFSResource which was added by the resolution to issue 18862. Thus, this issue is resolved by 18862.

The resolution to 12563 documented how to represent qualified Restrictions as added to OWL 2, using the UML Profile: the metamodel needs to be extended to provide an equivalent level of coverage.

see pqges 197 - 202 of ptc/2013-12-01 for details

Recent changes/clarifications in the RDF 1.1 specification reduce the need for a separate RDFWeb package. Further, there has been, and there is unlikely to be, any movement by other standards to use it to “map to similar features in a Common Logic ontology, Topic Map, UML, or ER conceptual model”. Finally, it adds confusion through the existence of duplicated class names with the RDFConcepts package.

Therefore the package (section 10.9) should be removed and any metamodel elements merged into RDFConcepts.

–

A. In section titles for 10.2 thru 10.5, remove “RDFBase Package,” and in titles 10.6 thru 10.8 remove “RDFS Package” and in 10.9 title remove “(RDFWeb Package)”

B. Remove the package RDFWeb from the metamodel, merging all of its classes into RDF Concepts (using MOF/UML PackageMerge rules)

C. Delete the first 2 paragraphs of section 10.9

D. Retitle Figure 10.9 as “RDF Documents”

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.

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.

This issue and ensuing discussions have led the FTF working group to recognize the need for an additional way to represent an RDF property in UML, that is, reified as a UML::Class, in addition to adding UML::Association to the set of base classes available for modeling RDF properties in the profile.
Tool implementation of AssociationClass (tested in IBM Rational Software Architect, No Magic MagicDraw, and Sparx Enterprise Architect) is unsatisfactory from an RDF/OWL perspective, as one cannot draw free-standing RDF properties (as association classes with an "rdfProperty" stereotype applied) without dragging the default relationships to rdfs:Resource or owl:Thing onto a diagram). In many cases when defining RDF vocabularies, it is desirable to define a property on its own, without specifying any domain or range, but sometimes showing property inheritance. Downstream vocabularies may then further refine these definitions as appropriate.
The proposed resolution is to
§ add UML::Association as a base class for all cases where RDF properties are used in the RDF and OWL profiles
§ add UML::Class as a base class for all cases where RDF properties are used in the RDF and OWL profiles
§ introduce two new stereotypes, "rdfsDomain" and "rdfsRange", to support domain and range property restrictions when UML classes are used to represent RDF properties,

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

Add a stereotyped instance specification for <<owlIndividual>> and the corresponding constraint, as suggested.

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.

Correct the Stereotype and Base Class text for owl:ObjectProperty (14.2.6.2) and owl:Property (14.2.6.3) as suggested.

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.

In section 14.2.5.4, clarify the text for OWL cardinality constraints as suggested.

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

revise test as suggested

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.

Renumber paragraph 14.1.4.1 to 14.1.3.7 and move it to the end of section 14.1.3, where it belongs.

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.

In section 14.2.3.1, revise the Stereotype and Base Class for OWLAnnotationProperty as suggested.

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)

revise text as suggested

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

revise text as suggested

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

revise text as suggested

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..*]

Revise multiplicity as suggested and remove first constraint.

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.

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

1. In section 10.2.2, replace the following OCL (from resolution to 16495):
context Node inv DisjointPartition:
(self.resource->notEmpty() implies self.oclIsTypeOf(ReferenceNode)) and
(self.oclIsTypeOf(ReferenceNode) or self.oclIsTypeOf(BlankNode) or
self.oclIsTypeOf(RDFSLiteral)) and
not (self.oclIsTypeOf(ReferenceNode) and self.oclIsTypeOf(BlankNode)) and
not (self.oclIsTypeOf(BlankNode) and self.isTypeOf(RDFSLiteral)) and
not (self.oclIsTypeOf(ReferenceNode) and self.oclIsTypeOf(RDFSLiteral))

By:
context Node inv DisjointPartition:
(self.oclIsTypeOf(ReferenceNode) or self.oclIsTypeOf(BlankNode) or
self.oclIsKindOf(Literal)) and
not (self.oclIsTypeOf(ReferenceNode) and self.oclIsTypeOf(BlankNode)) and
not (self.oclIsTypeOf(BlankNode) and self.isKindOf(Literal)) and
not (self.oclIsTypeOf(ReferenceNode) and self.oclIsKindOf(Literal))

The current method for specifying OWL restrictions (e.g., owl:allValuesFrom, owl:someValuesFrom, owl:hasValue) in the profile does not provide a means to differentiate, on a diagram, between the restriction types. Further, it does not create the proper "necessary and sufficient" or "necessary" relationships between the class to which the restriction applies and the anonymous class specified by the restriction.

There are several issues with the use of property redefinition to support restrictions in OWL. One of these involves the notion of property identity: OWL restrictions specify classes whose members have a restricted range of values for a particular property. In UML, property redefinition involves defining two distinct properties, potentially having the same name, one of which redefines the other, but that have unique identity and are related contextually via a constraint. Property identity is preserved in OWL, however – there is only one uniquely defined property referenced in property restrictions.
In addition, the notation specified in the current ODM document (for all three kinds of restrictions – existential and universal quantification as well as restricting the range of the property to a particular individual or data value) does not provide the ability to indicate whether property redefinition means that the restriction is necessary for class membership or necessary and sufficient for class membership. In OWL, restrictions are formed by creating an anonymous restriction class that limits the values possible for the range of a particular property, and then linking this restriction class to other class expressions, such as a named class, either through a generalization (rdfs:subClassOf), corresponding to necessary conditions for class membership, or equivalence relationship (owl:equivalentClass), corresponding to necessary and sufficient conditions. There should be a visible way for modellers to make this distinction in an ODM-compliant model. Such anonymous restrictions can be used with other class expressions to build up complex expressions useful for classification and identity reasoning (for example, does some individual x meet the criteria to be a member of y).
The proposed solution makes use of the «owlRestriction» stereotype, already available in the ODM specification, and augments that with a set of dependencies that connect the restriction to the property being restricted and to the class or individual/literal that provide the requisite source of value(s), as well as the use of either the «rdfsSubClassOf» stereotyped generalization or the «equivalentClass» stereotyped dependency or generalization that are already in the profile.
Per RTF discussion all of the stereotypes and notation for restrictions have been consolidated under a single heading, rather than distributing them across several sections. As a result, the recommendation, below, incorporates details for both object and data restrictions, for number as well as value restrictions, together in section 14.2.5.3, and eliminates sections 14.2.5.4 through 14.2.5.6.

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

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)

Resolved to the resolution of 16496

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.

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.

This is a valid issue. Revise the text to support OWL Full as indicated above

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.

Close, no change. The only elements in the OWL model library are Thing and Nothing, which should not have owl:versionInfo as attributes (or any attributes, for that matter – reserved language from OWL should not be modified).

Revised Text: none

Disposition: Closed, no change

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

Revise Table A.5 in Appendix A, Section A.3, column heading “Base Class & Stereotype” to replace all occurrences of “UML::LiteralString;«typedLiteral»” with “UML::Datatype;«rdfsDatatype»”.

Revise Table A.5 in Appendix A, Section A.3, column heading “Description, Constraints” to replace all occurrences of “datatypeURI” with “uriRef”. Note that there were also copy/paste errors in the original table (Description, Constraints column), with respect to the name of the datatype and URI provided in each row – this has also been addressed in the revised table, below.

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

The correct association name is NamespaceDefinitionForNamespace.
The erroneous section 10.9.3 was removed as part of the resolution to issue 18861

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

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

This is a fairly straightforward correction, as described in the resolution, below

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

Resolution:
Resolved to the resolution of 16495.

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

Resolution:
Resolved to the resolution of 16498.

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

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

Resolution: Closed to the resolution of Issue 12563.
Revised Text: n/a

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

Eliminate UML::Class as a base class for RDF properties, modify the notation for rdfs:domain and rdfs:range to use dependencies rather than associations, and add a capability for surrogate property definition, where the surrogate notation uses UML::Class with dependencies linking the surrogates back to the AssociationClass(es) that define the base property. Clarify text defining the notation for RDF property (and OWL object and datatype properties) as appropriate.
Note: The revisions described below should be applied prior to application of the changes for Issue 12563.

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

This issue and a number of others related to representation of restrictions in OWL have been addressed via extensive changes in the resolution to issue 12563. As a part of that resolution «owlValue» was eliminated entirely, making this issue moot.

Figure 14.19 is property subsetting. Figure 14.19 (Figure 14.19 - Property Redefinition For owl:allValuesFrom With Association Classes) is property subsetting rather than redefinition. The lower association should be hasBrightColor, rather than has hasColor, with

. It should be moved to the section on rdfsSubpropertyOf, it's not an example of allValuesFrom.

This issue and a number of others related to representation of restrictions in OWL have been addressed via extensive changes in the resolution to issue 12563. As a part of that resolution Figure 14.19 (now 14.26) was replaced, making this issue moot.

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

Close to the resolution for 13977, which corrects this figure and the related text.

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

Close to the resolution for 13977, which corrects this figure and the related text.

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

This issue and a number of others related to representation of restrictions in OWL have been addressed via extensive changes in the resolution to issue 12563. As a part of that resolution, the «owlValue» stereotype was eliminated altogether, making this issue moot.

Figure 14.10 missing property subsetting. Figure 14.10 (Property Subsetting, Unidirectional Association) should have

under the chases end label.

Close to the resolution for 13977, which includes a revision for this figure.

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

Eliminate UML::Class as a base class for RDFGlobalProperty, as follows

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

Revise the text under Description in section 14.1.7.1 as follows.
In the second sentence of the second paragraph, which begins, “For RDF properties that are defined without specifying a domain or range,” change
…”the profile uses an anonymous class (analogous to owl:Thing in OWL ontologies) for the “missing” end class.
to
…”the profile allows users to
• use an anonymous UML::Class, stereotyped by «rdfsClass», that is either the RDFS library class representing rdfs:Resource (analogous to owl:Thing in OWL ontologies) or rdfs:Class, for the “missing” domain end class, and
• either of those options or a UML::Datatype, stereotyped by «rdfsDatatype», library element representing rdfs:Literal, as appropriate, for the “missing” range end class.

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

No Data Available

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

Resolved through 19071

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

Close to the resolution for 13977, which includes deletion of this figure.

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

Resolution:
Resolved through 18835.

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

No Data Available

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

No Data Available

It’s unclear how derived Association OWLBase::/TripleForGraph is supposed to interact/be merged with underived RDFBase::TripleForGraph. There seems no need for a derived OWLGraph::/triple when OWLGraph inherits triple from RDFGraph. Or is it the intent that OWLGraph::triple

– in which case that should be stated along with how it would be derived: via OWLGraph::ontology and Ontology::triple? And is it the intent that Triple has both a derived /owlGraph and a (non-derived) graph property? In which case the former should

the latter and the derivation should be expressed.

1. In section 11.2.1 remove “OWLGraph” from the following clause:
Exceptions to this convention include OWLUniverse, OWLGraph, and OWLStatement,
2. In Figure 11.2 remove OWLGraph, and the lines to it. Also remove RDFGraph which has no purpose in this diagram

3. Remove section 11.2.1, OWLGraph

4. In section 11.2.2, OWLOntology:
Remove the first association:
owlGraph: OWLGraph [1..*] in association GraphForOntology - links an ontology to one or more graphs containing the triples that define it.
Remove all 4 constraints [1] through [4].

5. Remove section 11.2.4 Triple (Augmented Definition)

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

1. Rename section 14.1.6.6 from “RDFType” to “RDF Types” and renumber it to 14.1.6.7
2. Replace the text under Description beginning with “For M1, …” to the end of that paragraph with the following:
In some cases, it may also be convenient to show this relationship directly in a diagram, and therefore we provide this optional stereotype as a dependency from the resource (or individual or literal in OWL) to its classifier(s).
3. Insert additional text below the description, as follows:

Stereotype and Base Class
«rdfType», with base class of UML::Dependency

Parent
None

Properties
None

Constraints
None

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

Resolved to the resolution of 16496

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

Revise section 14.1.6.2 RDFSDatatype, to add the following under Properties:
• umlPrimitiveType: PrimitiveType [0..1] – the UML primitive type corresponding to the datatype

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

see pages 147 - 157 of ptc/2013-12-01 for details

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

see pages 124 - 146 of ptc/2013-12-01 for details

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

see pages 171 - 175 of ptc/2013-12-01 for details

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

• URIReference ::namespace

• URIReference ::fragmentIdentifier

• Triple::document

• Triple::ontology

Resolved through 18861.

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

see pages 158 - 170 of ptc/2013-12-01 for details

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

No Data Available

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

Delete Annex F, "RDF and OWL Workarounds for MOF Multiple Classification Issue" from the specification

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

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

Move Chapter 16, “Mapping UML to OWL”, to an informative annex. This should follow Annex C, “Description Logic Metamodel” and precede Annex E, “Mappings – Informative, Not Normative”, in terms of its ordering in the document.

The RDF 1.1 Concepts and Abstract Syntax document, which has been stable for months and is now in Last Call at the W3C, has substantially redefined the notion of packaging from the perspective of an RDF vocabulary. An RDF source can include documents as well as realizations of an RDF graph in a repository, such as a triple store, which and been a gaping hole in earlier versions of the specification. These revisions are critical to proper packaging of RDF in ODM applications, and should be reflected in the metamodel and profile.

see pages 187 - 196 of ptc/2013-12-01 for details

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

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

Delete Annex D, "Extending the ODM" from the specification.

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

Resolved to the resolution of 16496.

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

Resolved to the resolution of 16495.

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

1. The ODM machine readable files for the metamodel and UML Profile should be expressed in UML 2.4.1 (with MOF 2.4.1 for the Tags), and the non-normative ancillary files should use a version of MagicDraw that implements UML 2.4.1.
2. In section 3, the reference to MOF should be as follows:
[MOF] Meta Object Facility (MOF) Core Specification, Version 2.4.1. OMG Specification, formal/2013-06-01. Latest version is available at http://www.omg.org/spec/MOF/2.4.1/.
3. In section 3, the reference to UML2 should be as follows:
[UML2] Unified Modeling Language: Superstructure, version 2.4.1. OMG Specification, formal/2011-08-06. Available at http://www.omg.org/spec/UML/2.4.1/.
4. In section 3, delete the reference [UML Infra]

This issue addresses a number of editorial changes made to the ODM specification by the ODM 1.1 RTF against the originally submitted convenience documents, ptc/2013-08-02 and ptc/2013-08-03.

see pages 216 - of ptc/2013-12-01 for details

This issue addresses a number of editing problems uncovered in the ODM 1.1 RTF report, ptc/2013-08-01.

see pages 207 - 215 of ptc/2013-12-01 for details

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

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.

This issue really identifies the need for two relationships between these classes.
It calls for an additional role that would yield links to all the URIReferences
"contained" in a Namespace. The current association between these two classes is meant to represent URIReferences which identify namespaces, hence the association name URIReferenceForNamespace, while the URIReferences in question would identify elements in an owl ontology or rdfs vocabulary and not Namespaces. As the model stands, there is no easy way to derive this information.

The change to address this involves the addition of a new bi-directional association, URIReferenceInNamespace, between the URIReference and Namespace classes, as shown below.

In section 10.5.1, the role name of superProperty in PropertyGeneralization is confusing. It might be changed to subProperty

During the Jun 27th telecon, participants agreed that superProperty seems synonymous with RDFSsubPropertyOf, and that it should be changed to superPropertyOf, for consistency with other naming conventions in the metamodel.

In section 10.4.1, the role name of superClass in ClassGeneralization is confusing. It might be changed to subClass

During the June 27th telecon, participants agreed that superClass seems synonymous with RDFSsubClassOf, and that it should be changed to superClassOf, for consistency with other naming conventions in the metamodel.

In section 11.4.5, the cardinality of OWLInverseOf in InverseProperty association should be changed from 0..1 to 0..*. One property can have multiple inverse properties

In section 11.4.5, the cardinality of OWLInverseOf in InverseProperty association should be changed from 0..1 to 0..*. One property can have multiple inverse properties.

In section 14.2.3.1, it is not clear on how to set values for annotation property

Disposition: See issue 12391 for disposition

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

Revise the CL metamodel and related text as follows. Changes include:
§ Revised reference to the FDIS CL specification
§ Addition of Association CommentedText to and elimination of Association CommentedPhrase from the Phrases Diagram (Figure 12.1)
§ Rename Association ArgumentsForFunctionalTerm to ArgumentSequenceForFunctionalTerm (Figure 12.2)
§ Rename Association ArgumentsForAtomicSentence to ArgumentSequenceForAtomicSentence (Figure 12.3)
§ Rename Association BindingSequence to BindingSequenceForQuantifiedSentence (Figure 12.6) and provide missing paragraph (12.7.1 Binding)