Issues for Ontology Definition Metamodel (ODM) 1.2 Revision Task Force

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 10844: Figure D.3 notation (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

Figure D.3 notation. In Annex D, in Figure D.2, the instance names should be underlined. Some of the association end names are so far from the ends of the lines that it's hard to tell which they are referring to.

Resolution: Closed to the resolution of issue 18836, delete Annex D, "Extending the ODM" from the specification.
Revised Text:
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

The RTF agrees with the issue raised against this figure.  We advocate methods such as OntoClean, described in this annex for ontology evaluation, but suggest that a better approach would be to develop ontology libraries and additional profiles, together with custom applications, to achieve evaluation goals using the ODM.  Using the methods described in the annex for extending the ODM is not recommended.  Our recommendation after reviewing this issue and issue 10846 is to remove Annex D altogether

Issue 10846: Annex D.4 sets (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: Closed to the resolution of issue 18836, delete Annex D, "Extending the ODM" from the specification
Revised Text:
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

The RTF agrees with the issue raised against the recommended representation of n-ary relations.  There are a number of ways of modeling n-ary relations in OWL, including reification of the relationships as classes, as described in http://www.w3.org/TR/swbp-n-aryRelations/ and as partially described in the Annex.  These have a corresponding patterns in ontologies represented using the ODM metamodels, but would not require an extension to the metamodel itself, necessarily.  The representation described in Annex D would indeed require an additional constraint if implemented, but using the methods described for extending the ODM is not recommended.  Our recommendation after reviewing this issue and issue 10846 is to remove Annex D altogether

Issue 10850: Formal structure (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

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

Resolution: Replace text as described below.
Revised Text: Replace first two sentences after figure 16.1 which currently reads: The formal structure of UML is quite different from OWL. What we are trying to do is to understand the relationship between an M1/M0 model in UML and the equivalent model in OWL, so we need to understand how the M1 model is represented in the M2 structure shown. with The M2 model definition is quite different from OWL. We need to understand the relationship between an M1/M0 model in UML and the equivalent model in OWL, so we need to understand how the M1 model is represented in the M2 structure shown.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10865: Identifiers (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: Replace text as described below.
Revised Text: Replace the third and fourth paragraph after Table 16.7 which currently reads: That is there are cases in which a relational database implementation would use a compound key to identify an instance of a class. Since OWL individuals are always unitary names, the translation of the UML class would construct a unitary name from the values of the individual properties. with That is, there are cases in which a relational database implementation would use a compound key to identify an instance of a class. The translation of the UML class, when using compound keys, would construct a unitary name for an OWL individual from the value of the individual property.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10867: Subproperites and redefintion (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: Issue actually references the second paragraph after table 16.7. Replace text as described below.
Revised Text: Replace the text in the second paragraph after Table 16.7 which currently reads: The second source of owl properties in a UML M1 model is the M1 population of the M2 class association. A binary UML association translates directly to an owl:ObjectProperty. The translation of Table 16.4 is given in Table 16.8. Note that since associations in UML are always between types, the OWL property always has domain and range specified. If the association name occurs more than once in the same model, it must be disambiguated in the OWL translation, for example by concatenating the member names to the association name. with The second source of owl properties in a UML M1 model is the M1 population of the M2 class association (see Section 16.2.3 for details).
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10871: Association member ends (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: Replace text as described below
Revised Text: Replace the text in the third paragraph after Figure 16.3 which currently reads: Figure 16.3 extends the model of Figure 16.2 by making enrolled an association class that owns an attribute grade. The association class enrolled is a member end of an association instructor, whose other member end is staff. Some students enrolled in a given course may be assigned to one staff member as instructor, some as another. with Figure 16.3 extends the model of Figure 16.2 by making enrolled an association class that owns an attribute grade. Some students enrolled in a given course may be assigned to one staff member as instructor, some to another.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10873: Translation of binary associations. (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: Replace text as described below. (Note: This issue actually refers to the forth paragraph.)
Revised Text: Replace forth sentence of the forth paragraph of section 16.2.3 which currently reads: A UML binary association with one navigable end and one non-navigable end will be translated into a property whose domain is the navigable end. with A UML binary association with one navigable end and one non-navigable end will be translated into a property whose domain is the non-navigable end.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10874: UML Thing 2 (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: Delete last sentence of the fifth paragraph. (Note: this issue actually refers to fifth paragraph)
Revised Text:
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10875: Individuals (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: Replace text as described below. (Note: this issue actually refers to the sixth paragraph)
Revised Text: Replace first sentence in sixth paragraph in section 16.2.3 which currently reads: An OWL individual can therefore be difficult to represent in a UML model. with An OWL individual can be difficult to represent in a UML model.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10876: Disjoint. (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: Replace text as described below. (Note: this issue actually refers to the seventh paragraph)
Revised Text: Replace second and third sentences in seventh paragraph in section 16.2.3 which currently reads: Both allow subclasses of a class to be declared disjoint. (In OWL, all classes are subclasses of Thing, so any pair of classes can be declared disjoint.) with Both allow any subclasses of a class to be declared disjoint.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10879: Mandatory properties (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

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

Resolution: Close no change
Revised Text:
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

Issue 10884: Derivation. (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: 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.
Revised Text:
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10886: Table 16.11 (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: 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)
Revised Text:
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10887: Table 16.12, Thing (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: Close no change.
Revised Text:
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

Issue 10888: Table 16.12, AllValuesFrom (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: Replace text as described below
Revised Text: Replace second row of Table 16.12 which currently reads: allValuesFrom, someValuesFrom with someValuesFrom
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10890: Table 16.12, disjoint (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: Replace text as described below.
Revised Text: Replace last row of Table 16.12 which currently reads: disjointWith, complementOf with complementOf
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10894: Names, UML namespaces (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

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

Resolution: Delete text as described below
Revised Text: Delete the first sentence of the next to last paragraph in section 16.5.2 which currently reads: UML supports named elements with namespaces only at the M1 level.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10895: Other OWL (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Significant
Summary:

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

Resolution: Delete text as described below
Revised Text: Delete section 16.5.3
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10897: Complex Objects (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: Add text as described below
Revised Text: Replace the second sentence of the second paragraph in section 16.6.2 which current reads: They are used to hierarchically decompose a class into its internal structure which allows a complex objects to be broken down into parts. with: They are used to show the valid combination of instances of internal classes and how these instances are combined to form the structure of the containing class
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10898: Keywords (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: Delete section 16.6.4 and Replace text in section 16.6.5 as described below
Revised Text: Replace the text of the first 2 sentences in the third paragraph in section 16.6.5 which currently reads: Profiling in UML is necessary because of the strict separation of metalevels, and is useful partly because it allows re-use of the UML graphical rendering conventions, and also the UML graphical editors and other tools. OWL does not at present have a standard graphical representation. with Profiling makes it possible to reuse UML graphical rendering conventions, and take advantage of UML graphical editors and other tools. Stereotypes are used to extend the functionality of basic symbols, and thus reduce the number of symbols users are required to remember. While OWL does not have a standard graphical representation, the ODM profiles for RDF and OWL provide one.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10899: Profiles (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: Delete section 16.6.4 and Replace text in section 16.6.5 as described below.
Revised Text: Replace the text of the first 2 sentences in the third paragraph in section 16.6.5 which currently reads: Profiling in UML is necessary because of the strict separation of metalevels, and is useful partly because it allows re-use of the UML graphical rendering conventions, and also the UML graphical editors and other tools. OWL does not at present have a standard graphical representation. with Profiling makes it possible to reuse UML graphical rendering conventions, and take advantage of UML graphical editors and other tools. Stereotypes are used to extend the functionality of basic symbols, and thus reduce the number of symbols users are required to remember. While OWL does not have a standard graphical representation, the ODM profiles for RDF and OWL provide one.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10900: UML to OWL, OWL-DL (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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?

Resolution: Replace text as described below.
Revised Text: Replace the text in the third sentence of first paragraph in section 16.3 which currently reads: The mapping is limited to OWL DL, which means only OWL-DL constructs will be used in mapping definitions. with This mapping is limited to OWL DL, which means only OWL-DL constructs will be used in mapping definitions.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10901: UML to OWL, Table 16.10 (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: Replace text as described below
Revised Text: Replace the text in the third paragraph in section 16.3 which currently reads: Mappings are shown for all constructs in Table 16.10 for which there is an OWL equivalent, except for Instance. The Instance model is not part of the classes model, and is intended to show partial specifications of instances rather than concrete instances. The profiles represent OWL individuals as singleton classes rather than UML instances. So the mappings do not include Instance. with Mappings are shown for all constructs in Table 16.10 for which there is an OWL equivalent, except for Instance. The Instance model is not part of the class model, and is intended to show partial specifications of instances rather than concrete instances
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10902: Object identification in UML (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: Replace text as described below
Revised Text: Replace the text in the first two paragraphs in section 16.3.1 which currently reads: In OWL, all objects are identified either by uniform resource identifiers (uri) or by an arbitrarily assigned identifier unique within the ontology (blank nodes). A typical method is for objects within an ontology to be identified by uri that is a fragment on a base uri that identifies the ontology. It is also possible for an object to have a uri independent of that of the ontology. Blank node identifiers can be treated as fragments in this way during the course of the mapping, even though the identifiers do not persist. A uri is conceptually global. It universally identifies the same object no matter where it appears. In UML, objects are identified by name within a minimally disambiguating context. If there are several packages involved in a mapping, they have different names. But other packages may exist elsewhere that have the same name. Within a package, classes, associations, and some other objects are identified by names unique to the package. Lower level kinds of objects like properties are identified by names unique within their parent object. For example, several different classes may have attributes with the same name. with In OWL, all elements are identified either by uniform resource identifiers (URI) or optionally by an arbitrarily assigned identifier unique within the ontology (blank nodes). A typical method is for elements within an ontology to be identified by a URI reference, which adds a local name to a base URI that identifies the ontology. It is also possible for an element to have a URI independent of that of the ontology. Blank node identifiers can be treated as local names during the course of the mapping, even though they do not persist. A URI is conceptually global. It universally identifies the same element no matter where it appears. In UML, elements can be identified by name within a minimally disambiguating context. If there are several packages involved in a mapping, the packages themselves must have unique names within the scope of the mapping and provide scope for the elements they contain. But other packages may exist elsewhere that have the same name. Within a package, classes, associations, and other elements can be identified by names unique to the package. Lower level elements such as properties are identified by names unique within their parent element. For example, several different classes may have attributes with the same name.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10904: N-aries. Section 16.3.6 (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: Close no change. It was previously resolved in FTF2 in response to issue 10869
Revised Text:
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10907: Enumeration literals (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: Replace text as described below
Revised Text: Replace the text in the third paragraph in section 16.3.4 which currently reads: If the type of the property is Class, or the ownedLiteral of an Enumeration type has at least one classifier, the property can be mapped to OWLObjectProperty. with If the type of the property is Class, or the ownedLiteral of an Enumeration type has at least one classifier, (which does not map to a member of the XSD model library or some user defined type), the property can be mapped to OWLObjectProperty. Replace the text in the first paragraph in section 16.3.9 which currently reads: An enumeration in UML is a designated collection of literals, so corresponds to an enumerated datatype in OWL. with An enumeration in UML is typically a designated collection of literals, and in that case corresponds to an enumerated datatype in OWL.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10913: Universal Superclass (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Replace text as described below
Revised Text: Replace the text in the first paragraph in section 16.4.5.2 which currently reads: OWL has a universal superclass called owl:Thing acting as a default domain and range for properties. Need to create a comparable UML class, called Thing (see Section 14.2.5). with OWL has a universal superclass called owl:Thing acting as a default domain and range for object properties. A comparable model library element for use in UML is available in Annex A, Section A.6, Table A.4 and is created for use in the QVT mapping below
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 10915: Range Restriction Restriction Classes (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: Replace text as described below.
Revised Text: Replace the text in the first paragraph in section 16.4.8 which currently reads: The restriction classes allValuesFrom, someValuesFrom, and HasValue all define subclasses of the domain on which a specified property behaves in a specified way. UML does not have the machinery to represent the specified behavior. So the mapping in each case is to an anonymous class, declared as a subclass of the domain of the property (if any), with the restriction indicated in an attached comment. The mapping for hasValue only includes the case where the value is a literal, since there is not a good general representation of Individuals in UML. with The restriction classes allValuesFrom, someValuesFrom, and HasValue define subclasses of the domain for which the specified property has constrained values. The mapping provided here uses an anonymous class, declared as a subclass of the domain of the property (if any), with the restriction indicated in an attached comment.. The mapping for hasValue only includes the case where the value is a literal.
Actions taken:
March 30, 2007: received issue
April 25, 2014: closed issue

Discussion:

FTF resources were scarce and priority was given to issues against normative sections, hence many issues such as this were left unresolved.    Disposition:	Deferred to RTF

Issue 11320: Thing in the Profile (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: 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
Revised Text:
Actions taken:
August 29, 2007: received issue
April 25, 2014: closed issue

Discussion:

We addressed the most urgent profile issues.  We would expect this to be among those addressed first in RTF. Disposition:	Deferred to RTF

Issue 11321: RDFSContainer-MembershipProperty (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: 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
Revised Text: 1. Revise the introductory paragraph in section 14.1.8, as follows: The stereotypes Most of the stereotypes associated with the definitions given in 10.8 (�RDFS Package, Containers and Collections�) are defined in Annex A (�Foundation Library (M1) for RDF and OWL�) including definition of container membership properties and lists. 2. Insert the following text after this revised paragraph: 14.1.8.1 RDFSContainerMembershipProperty Description rdfs:ContainerMembershipProperty provides a mechanism for defining ordered properties and linking them to a specified container in RDF. Instances of this property include rdf:_1, rdf:_2,rdf:_3 ..., and are used to state that the object of the property is member of the container specified as the subject (see 10.6.5 (�RDFSContainerMembershipProperty�). Stereotype and Base Class �rdfsContainerMembershipProperty� with base class of UML::Property, UML::Association Parent �rdfProperty� Properties None. Constraints None. 3. Modify the text in the first row of Table A.4, describing M1 Objects _1,_2, _3, _4, _5, _6,_7, _8, _9, _10, etc., second column, from UML::Property; �rdfsContainerMembershipProperty� to UML::Property, UML::Association; �rdfsContainerMembershipProperty� 4. Delete row 7 in Table A.4, describing M1 Object RDFSContainerMembershipProperty.
Actions taken:
August 29, 2007: received issue
April 25, 2014: closed issue

Discussion:

We addressed the most urgent profile issues.  We would expect this to be among those addressed first in RTF.    Disposition:	Deferred to RTF

Issue 12390: Specification: RDFSComment optional representation as plain literal (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Minor
Summary:

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)

Resolution: Resolved to the resolution of 16496
Revised Text:
Actions taken:
April 17, 2008: received issue
April 25, 2014: closed issue

Discussion:

This issue has been resolved in the resolution for issue 16496, which does allow language tags to be used on comments as well as with custom annotations.

Issue 12394: OWL Model Library elements are missing owl:versionInfo attributes (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: 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
Revised Text:
Actions taken:
April 17, 2008: received issue
April 25, 2014: closed issue

Issue 12399: Text describing owl:someValuesFrom and owl:hasValue limits implementations (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: This is a valid issue. Revise the text to support OWL Full as indicated above
Revised Text: In section 14.2.5.6, revise the first sentence in the second paragraph to include �(or class in OWL Full)� at the end of the sentence, so that it reads: The value constraint owl:hasValue is a built-in OWL property that links a restriction class to a value V, which can be either an individual or a data value (or class in OWL Full).
Actions taken:
April 17, 2008: received issue
April 25, 2014: closed issue

Issue 12563: UML Profile for RDF and OWL, Section 14.2.5 (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: 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.
Revised Text: see pages 57 - 78 of ptc/2013-12-01 for details
Actions taken:
July 10, 2008: received issue
April 25, 2014: closed issue

Issue 13074: Section: 10.2.2 (odm-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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!

Resolution: 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))
Revised Text:
Actions taken:
November 7, 2008: received issue
April 25, 2014: closed issue

Discussion:

Agreed.   The OCL was already updated by the resolution to 16495 which replaced URIReferenceNode. Also RDFSLiteral was renamed to Literal.   Actually the first part of the constraint is redundant since the resource property is only defined on ReferenceNode.  With respect to the other 2 constraints mentioned in the issue, 16495 deleted the constraint in section 10.2.9 (page 41) and added the () to isEmpty for the constraint on 10.6 2 (p49) � so no further change is needed .

Issue 13075: Section: 10.9.3 (odm-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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)

Resolution: The correct association name is NamespaceDefinitionForNamespace. The erroneous section 10.9.3 was removed as part of the resolution to issue 18861
Revised Text: Resolved through 18861.
Actions taken:
November 7, 2008: received issue
April 25, 2014: closed issue

Issue 13937: Section: Appendix A, Section A.3 (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: 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.
Revised Text: see pages 82 - 86 of ptc/2013-12-01 for details
Actions taken:
May 18, 2009: received issue
April 25, 2014: closed issue

Discussion:

Issue 13938: NamespaceDefinition is defined as a metaclass, without a stereotype (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: This is a fairly straightforward correction, as described in the resolution, below
Revised Text: Revise section 14.1.2.1 NamespaceDefinition, as follows: 1. Rename the section from �NamespaceDefintion� to �Namespace Definitions� 2. Under Stereotype and Base Class, change �None� to ��namespaceDefinition� with base class of UML::InstanceSpecification� 3. Under Properties, change namespaceURI: String [1] � the string representing the namespace URI to namespaceIRI: String [1] � the string representing the namespace IRI 4. Under Constraints, change [2] The string value of the namespace URI must conform to the character encoding (including escape sequences and so forth) defined in [RDF Syntax] and [XMLNS]. to [2] The string value of the namespace IRI must be a Unicode string that conforms to the syntax defined in RFC 3987, normalized according to Section 5 of RFC 3987 if possible.
Actions taken:
May 27, 2009: received issue
April 25, 2014: closed issue

Issue 13940: Section: 14.2.8.1 (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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: Resolution: Resolved to the resolution of 16498.
Revised Text:
Actions taken:
May 29, 2009: received issue
April 25, 2014: closed issue

Discussion:

This issue is related to issue 16498, which addresses the need for better support for data types, restrictions, data ranges, and datatype facets in general, and the resolution for it is addressed in the resolution of that issue.

Issue 13941: Section: 14.1.3.5 (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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: Resolution: Resolved to the resolution of 16495.
Revised Text:
Actions taken:
May 29, 2009: received issue
April 26, 2010: closed issue
April 25, 2014: closed issue

Discussion:

This issue is related to issue 16495, which addresses the need for better support for internationalized URIs (IRIs) and reworks the RDF profile with respect to how graphs, statements, and URIs/IRIs should be represented. The resolution for 13941 is addressed in the resolution of that issue (namely 16495).

Issue 13977: rdfsDomain/Range should be based on dependency. (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: 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.
Revised Text: see pages 92 - 102 of ptc/2013-12-01 for details
Actions taken:
June 11, 2009: received issue
April 25, 2014: closed issue

Discussion:

While direct representation of RDF properties as classes may not have provided  �proper� notation from a UML perspective, neither would representation of RDF properties without some capacity to represent property hierarchies without unnecessary detail, (as one of many examples), be acceptable to vocabulary and ontology developers.  In fact, for representation of properties in OWL, a �standalone� notation for complex properties and restrictions that does not require the modeller to drag property endpoints around on diagrams is essential.    This resolution is intended to (1) eliminate the concerns with respect to basic property notation for RDF and OWL and (2) address the modelling requirements for properties in RDF and OWL that motivated the use of UML::Class as a base for properties in the first place, through introduction of the surrogate.

Issue 13978: Section: UML Profile for OWL and RDF (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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: Resolution: Closed to the resolution of Issue 12563. Revised Text: n/a
Revised Text:
Actions taken:
June 11, 2009: received issue
April 25, 2014: closed issue

Discussion:

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.

Issue 13979: Figure 14.10 missing property subsetting (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

Figure 14.10 missing property subsetting. Figure 14.10 (Property Subsetting, Unidirectional Association) should have {subsets follows} under the chases end label.

Resolution: Close to the resolution for 13977, which includes a revision for this figure.
Revised Text:
Actions taken:
June 11, 2009: received issue
April 25, 2014: closed issue

Issue 13980: owlValue and allValuesFrom (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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?

Resolution: 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.
Revised Text: Resolution: Closed to the resolution of Issue 12563.
Actions taken:
June 11, 2009: received issue
April 25, 2014: closed issue

Issue 13981: Figure 14.19 is property subsetting (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

Figure 14.19 is property subsetting. Figure 14.19 (Figure 14.19 - Property Redefinition For owl:allValuesFrom With Association Classes) is property subsetting rather than redefinition. The lower association should be hasBrightColor, rather than has hasColor, with {subsets Hascolor}. It should be moved to the section on rdfsSubpropertyOf, it's not an example of allValuesFrom.

Resolution: 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.
Revised Text: Resolution: Closed to the resolution of Issue 12563.
Actions taken:
June 11, 2009: received issue
April 25, 2014: closed issue

Issue 13982: owlValue and allValuesFrom 2 (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: 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.
Revised Text: Closed to the resolution of Issue 12563.
Actions taken:
June 11, 2009: received issue
April 25, 2014: closed issue

Issue 13983: RDFGlobalProperty shouldn't apply to classes (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: Eliminate UML::Class as a base class for RDFGlobalProperty, as follows
Revised Text: (2) Paragraph 14.1.7.2, p. 148 of the ODM 1.0 Specification, under �Stereotype and Base Class�. Change �rdfGlobal� with base class of UML::Class, UML::AssociationClass, UML::Property, and UML::Association to �rdfGlobal� with base class of UML::AssociationClass, UML::Property, and UML::Association (3) Paragraph 14.1.7.2, p. 148 of the ODM 1.0 Specification, under �Description�, change An optional stereotype on a unidirectional association class, class, or property with �rdfProperty� applied, indicating the association/class property is defined globally, i.e., that class having the property, or on the non-navigable end of the association, is the class on which the class property/association is introduced, i.e., the property is not inherited from a superclass. to An optional stereotype on a unidirectional association class, association, or property with �rdfProperty� applied, indicating that the property is defined globally, i.e., that the class having the property or non-navigable end of the association, is the class on which the property is introduced, meaning, the property is not inherited from a superclass.
Actions taken:
June 12, 2009: received issue
April 25, 2014: closed issue

Discussion:

In keeping with the resolution to issues 13977, and 13984-6, eliminate the class notation for RDFGlobalProperty

Issue 13984: rdfsDomain/Range should be based on dependency 2 (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: Close to the resolution for 13977, which includes deletion of this figure.
Revised Text:
Actions taken:
June 12, 2009: received issue
April 25, 2014: closed issue

Issue 13985: rdfsDomain/Range should be based on dependency 3 (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: Close to the resolution for 13977, which corrects this figure and the related text.
Revised Text:
Actions taken:
June 12, 2009: received issue
April 25, 2014: closed issue

Issue 13986: RDFProperty, RDFObjectProperty, and RDFDatatypeProperty shouldn't apply to classes (odm-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: Close to the resolution for 13977, which corrects this figure and the related text.
Revised Text:
Actions taken:
June 12, 2009: received issue
April 25, 2014: closed issue

Issue 14425: rdfs:Literal (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution: 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.
Revised Text:
Actions taken:
September 18, 2009: received issue
April 25, 2014: closed issue

Discussion:

This issue can be resolved by correcting the text at the start of section 14.1.7.1 in the description of RDFProperty

Issue 16030: The PrimitiveTypes in the metamodel XMI file are instances of Class not PrimitiveType (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Resolution: Resolved through 18835.
Revised Text:
Actions taken:
February 16, 2011: received issue
April 25, 2014: closed issue

Discussion:

This is addressed by using UML 2.4.1/MOF 2.4.1 for the metamodel as a result of 18835.

Issue 16031: In the OWL metamodel the Restriction Cardinality elements should own their TypedLiteral (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Resolved through 19071
Revised Text:
Actions taken:
February 16, 2011: received issue
April 25, 2014: closed issue
April 25, 2014: closed issue

Discussion:

The metamodel for Restrictions has been revised and redrawn as a result of issue 19071. That addresses this issue also.

Issue 16032: multiple inheritance for MOF shown in Figure F.4 (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
February 16, 2011: received issue
April 25, 2014: closed issue

Discussion:

The RTF has determined that due to SMOF, Annex F is no longer required and the Annex should be deleted, per the resolution to issue 18834.  Thus, this issue is closed to the resolution of 18834.    Disposition:	Resolved

Issue 16033: It would be preferable for isDeprecated to be non-optional with a default value of false. (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
February 16, 2011: received issue
April 25, 2014: closed issue

Discussion:

The RTF has determined that due to SMOF, Annex F is no longer required and the Annex should be deleted, per the resolution to issue 18834.  Thus, this issue is closed to the resolution of 18834.    Disposition:	Resolved

Issue 16034: OWLClass::isClassKind:OCLClassKind breaks convention that �is� at the start of properties is used to indicate Booleans (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
February 16, 2011: received issue
April 25, 2014: closed issue

Discussion:

The RTF has determined that due to SMOF, Annex F is no longer required and the Annex should be deleted, per the resolution to issue 18834.  Thus, this issue is closed to the resolution of 18834.    Disposition:	Resolved

Issue 16035: In Annex F the use of OWLClass::/isClassKind: and OWLClass::/hasRestrictionKind is not sufficient (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 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.

Resolution:
Revised Text:
Actions taken:
February 16, 2011: received issue
April 25, 2014: closed issue

Discussion:

The RTF has determined that due to SMOF, Annex F is no longer required and the Annex should be deleted, per the resolution to issue 18834.  Thus, this issue is closed to the resolution of 18834.    Disposition:	Resolved

Issue 16037: I propose that the following properties are owned by the Association (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Resolved through 18861.
Revised Text:
Actions taken:
February 16, 2011: received issue
April 25, 2014: closed issue

Discussion:

This issue is moot due to the removal of the RDFWeb package completely by issue 18861.

Issue 16038: derived Association OWLBase::/TripleForGraph (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

 It�s unclear how derived Association OWLBase::/TripleForGraph is supposed to interact/be merged with underived RDFBase::TripleForGraph. There seems no need for a derived OWLGraph::/triple when OWLGraph inherits triple from RDFGraph. Or is it the intent that OWLGraph::triple {redefines RDFGraph::triple} � in which case that should be stated along with how it would be derived: via OWLGraph::ontology and Ontology::triple? And is it the intent that Triple has both a derived /owlGraph and a (non-derived) graph property? In which case the former should {subset} the latter and the derivation should be expressed.

Resolution: 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)
Revised Text:
Actions taken:
February 16, 2011: received issue
April 25, 2014: closed issue

Discussion:

This association is not needed; neither is OWLGraph needed as a specialization of RDFGraph

Issue 16495: ODM does not support internationalized URIs (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: see pages 124 - 146 of ptc/2013-12-01 for details
Revised Text:
Actions taken:
August 19, 2011: received issue
April 25, 2014: closed issue

Discussion:

When the ODM 1.0 specification was originally published, the W3C Recommendation for internationalized URIs (IRIs) had not yet been published.  It was made available shortly after ODM publication, however, and the OWL 2 recommendation in particular relies on it heavily. The ODM metamodels and profiles for RDF and OWL should be revised accordingly.  One specific change is the lack of a need to separate URIReference from UniformResourceIdentifier (which inherited from it) going forward. For most use cases of the ODM metamodels and profiles, the distinction between an IRI and a URI can be eliminated, although in practice, a URI represents a more constrained character string, i.e., additional escaped and special Unicode characters are permitted in IRIs that are not allowed in URIs.  The RTF has elected to eliminate the URIReference altogether, and retain the definition of a URI as support for those applications/models that require it.  Note 1:  Application of this resolution anticipates that the resolution of issue 13938, which addresses the changes required to section 14.1.2.1 Namespace Definitions, will be applied first.

Issue 16496: ODM should support recent W3C definitions for plain literals (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: see pages 147 - 157 of ptc/2013-12-01 for details
Revised Text:
Actions taken:
August 19, 2011: received issue
April 25, 2014: closed issue

Discussion:

While the ODM 1.0 specification incorporated a model for plain literals based on implicit definitions in the original RDF 1.0 specifications, an explicit definition was published at the time the OWL 2 specifications were published.  In addition, recent revisions to the RDF specification, which will be released as RDF 1.1 later this year, clarify the definition of literals in RDF.    The distinction between plain and typed literal has been difficult to discern since the original documents were published by the W3C.  The OWL working group devised a specification for rdf:PlainLiteral that requires every literal to include a language tag, which is far from ideal.  The latest approach, codified in the RDF 1.1 specification, makes much more sense from an OMG perspective, and states that any literal that is not explicitly typed is, by default, of type xsd:string.  This approach clarifies and simplifies the equivalent representation in UML and MOF, and makes sense for ODM implementations.  See http://www.w3.org/TR/2009/REC-rdf-plain-literal-20091027/ and http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/ for additional details.    Note that this resolution assumes application of the resolution to issue 16495 first.

Issue 16498: ODM does not support XML Schema Datatype facets, which were added in OWL 2 (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: see pages 158 - 170 of ptc/2013-12-01 for details
Revised Text:
Actions taken:
August 19, 2011: received issue
April 25, 2014: closed issue

Discussion:

Treatment of datatypes and data ranges has been vastly improved in OWL 2, and is required for development of emerging standards such as the Information Exchange Policy Vocabulary and Financial Industry Business Ontology families.  The resolution, below, revises the OWL 2 metamodel and profile in support of these capabilities

Issue 16499: Label and URI properties are duplicated on many elements in the RDF and OWL profiles (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: see pages 171 - 175 of ptc/2013-12-01 for details
Revised Text:
Actions taken:
August 19, 2011: received issue
April 25, 2014: closed issue

Discussion:

The current profiles for RDF and OWL provide many examples of unique properties representing the URI/IRI and/or label on stereotypes, for example, for the definition of RDFProperty as defined in 14.1.7.1, which has its own uriref property. This means that the XMI for any vocabulary or ontology developed in tools that implement the profile will necessarily include many definitions of uriref, uri, and label, each of which has a unique UUID.  In order to ensure that any profile element, in either the RDF or OWL profile, that can be labeled and/or named (i.e., can have an IRI), has the same label and identifier (name/IRI) property rather than one of several, additional, abstract stereotypes that provide a single source for each of these are needed.  These new stereotypes can be applied in the RDF profile and inherited by stereotypes in the OWL profile to fulfill the requirement.

Issue 16500: Datatype definitions should be mapped to UML primitives (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
August 19, 2011: received issue
April 25, 2014: closed issue

Discussion:

The requirement in this case can be fulfilled by augmenting the definition of rdfs:Datatype with an optional property representing the appropriate UML primitive type.  Note that resolution of this issue presumes application of the resolution to issue 16495.

Issue 16501: Typed literal definitions should be mapped to their defining datatypes (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: Resolved to the resolution of 16496
Revised Text:
Actions taken:
August 19, 2011: received issue
April 25, 2014: closed issue

Discussion:

This issue has been resolved in the resolution for issue 16496, which does include the reference to the rdfs:Datatype, optionally, as a part of the specification for �literal�.  .

Issue 16502: Need a stereotype to visually link individuals to their classifiers (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: 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
Revised Text:
Actions taken:
August 19, 2011: received issue
April 25, 2014: closed issue

Discussion:

This resolution presupposes application of the resolution to issue 16495.

Issue 16503: Need a stereotype to link local extended defs to the definitions they reference in imported vocabularies (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: Resolved to the resolution of 16495.
Revised Text:
Actions taken:
August 19, 2011: received issue
April 25, 2014: closed issue

Discussion:

This issue is related to issue 16495, and the resolution for it is addressed in the resolution of that issue.

Issue 16504: Need to augment stereotyped literal strings with InstanceSpecification metaclass (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: Resolved to the resolution of 16496.
Revised Text:
Actions taken:
August 19, 2011: received issue
April 25, 2014: closed issue

Discussion:

This issue has been resolved in the resolution for issue 16496, which does include UML::InstanceSpecification as a base class as a part of the specification for �literal�.

Issue 18833: Move Chapter 16 to an Informative Annex (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: 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.
Revised Text:
Actions taken:
July 26, 2013: received issue
April 25, 2014: closed issue

Discussion:

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.

Issue 18834: Annex F has been superceded by SMOF (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: Delete Annex F, "RDF and OWL Workarounds for MOF Multiple Classification Issue" from the specification
Revised Text:
Actions taken:
July 26, 2013: received issue
April 25, 2014: closed issue

Discussion:

The MOF Support for Semantic Structures (SMOF) 1.0 Specification, available at https://www.omg.org/spec/SMOF/1.0/, corrects the issues that Annex F raises and provides a work-around for.  While the RTF does not know the implementation status for SMOF, from a specification perspective, Annex F is obsolete, and should be removed from the specification.

Issue 18835: Revise the ODM to support UML/MOF 2.4.1 (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Critical
Summary:

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.

Resolution: 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 https://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 https://www.omg.org/spec/UML/2.4.1/. 4. In section 3, delete the reference [UML Infra]
Revised Text:
Actions taken:
July 26, 2013: received issue
April 25, 2014: closed issue

Issue 18836: Annex D has a number of issues and should be removed (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: Delete Annex D, "Extending the ODM" from the specification.
Revised Text:
Actions taken:
July 26, 2013: received issue
April 25, 2014: closed issue

Discussion:

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.

Issue 18861: RDFWeb serves no purpose (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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�
Revised Text:
Actions taken:
August 20, 2013: received issue
April 25, 2014: closed issue

Discussion:

This is a useful clean up.  While rationalizing headings, there are many mentions to �RDFBase Package� which does not exist: in general the package name actually makes the document hard to navigate so should be removed.

Issue 18862: Revise the RDF Metamodel and Profile to support RDF source and dataset (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: see pages 187 - 196 of ptc/2013-12-01 for details
Revised Text:
Actions taken:
August 20, 2013: received issue
April 25, 2014: closed issue

Discussion:

The resolution described below was developed after many months� discussion within the RTF and with external experts involved in the RDF 1.1 revision.  For historical context, the RTF identified a gap in mid- to late-2011, whose issue we addressed with a stereotype and set of relationships we called a �MagicBox� (to the consternation of some RTF members and others), to fill the role of what the RDF 1.1 working group identified in parallel as an �RDF Source�.   That solution has evolved over time and after significant discussion among RTF members into what is presented below.  The solution for the profile has been vetted in the Visual Ontology Modeler plug-in for MagicDraw and is used for both the IEPPV and FIBO ontologies.  The approach taken for the metamodel is under development by Adaptive, but has been reviewed by RDF experts and is considered an accurate representation.

Issue 19071: Qualified Restrictions In Metamodel (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity: Minor
Summary:

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.

Resolution: see pqges 197 - 202 of ptc/2013-12-01 for details
Revised Text:
Actions taken:
November 8, 2013: received issue
April 25, 2014: closed issue

Discussion:

Representation of restrictions on properties was revised extensively for the profile via the resolution to 12563, and is required for development of emerging standards such as the Information Exchange Policy Vocabulary and Financial Industry Business Ontology families.  The resolution, below, revises the OWL 2 metamodel and makes minor revisions to the profile based on usage experience in support of these capabilities.  The primary aspects to be addressed in the metamodel are as follows:  -	Addition of hasSelf restriction at OWL2  -	Use of integers rather than Literals to express cardinality of restrictions  -	Addition of qualified cardinality restrictions at OWL2  -	Use of DataRange rather than Enumeration for Data All/SomeValuesFrom  -	The introduction of ClassExpression rather than Class in restrictions  For organizational purposes, Restrictions are important enough to have their own subsection  This resolution incorporates changes to address 16031 (ownership of Literals). A lot of this is addressed by the second bullet above, only leaving HasValueRestriction.  Note that application of this resolution requires that the resolution to issue 12563 is applied first.

Issue 19072: Further characteristics of Properties (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: see pages 203 - 205 of ptc/2013-12-01 for details
Revised Text:
Actions taken:
November 8, 2013: received issue
April 25, 2014: closed issue

Discussion:

Representation of properties was revised extensively for the profile via the resolution to 13977, 13979, and 13984 through 13986, although support for reflexive, irreflexive and asymmetric properties was not provided in that resolution. The resolution, below, revises the OWL 2 metamodel with respect to OWL object properties and makes similar revisions to the profile.  Note that application of this resolution requires that the resolution to issues 13977, 13979, and 13984 through 13986 (all one resolution) is applied first.  For the metamodel, rather than introducing a further subclass for each of the new characteristics, this provides an opportunity to rationalize the metamodel approach with the profile and use Booleans for each.

Issue 19073: How to relate RDF Classes to an OWL Ontology in ODM metamodel (odm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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.
Revised Text:
Actions taken:
November 8, 2013: received issue
April 25, 2014: closed issue

Discussion:

This can be addressed more generically at the RDF level.

Issue 19135: ODM 1.1 Report contains editing bugs (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: see pages 207 - 215 of ptc/2013-12-01 for details
Revised Text:
Actions taken:
December 9, 2013: received issue
April 25, 2014: closed issue

Discussion:

Many of the challenges uncovered during AB review of the submitted convenience documents (ptc/2013-08-02 and ptc/2013-08-03) and related ODM 1.1 RTF report, ptc/2013-08-01, are related to the order in which the issues must be applied, and confusion around the resulting section and figure numbers.    Other minor errors in the editing instructions in the original resolutions were also uncovered.  The set of issues/changes identified below corrects problems in the editing instructions and provides section and figure numbering maps to assist with ensuring that the resulting specification is as intended.   Editing changes are ordered by chapter in the ODM 1.1 specification and within chapter by OMG issue number.  In addition, one table detailing the section mapping for Chapter 10 and several tables detailing figure and section mapping for Chapter 14 are provided to aid in understanding and provide the definitive naming for section headings in particular.

Issue 19136: ODM 1.1 Editorial Changes (odm-rtf)

Click here for this issue's archive.
Source: Thematix Partners LLC (Mrs. Elisa F. Kendall, ekendall(at)thematix.com)
Nature: Clarification
Severity: Minor
Summary:

  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.

Resolution: see pages 216 - of ptc/2013-12-01 for details
Revised Text:
Actions taken:
December 9, 2013: received issue
April 25, 2014: closed issue

Discussion:

A number of changes were made over time to the profiles for RDF and OWL in particular that were not synchronized / revised as needed with respect to some of the earlier resolutions.  Some of these were caught in the process of editing the convenience document, but are not reflected in existing resolutions.  This resolution provides a blanket mechanism for capturing these changes.