Issues for 2nd Ontology Definition Metamodel Finalization Task Force

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

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

Jira Issues

Issue 10839: UML References Jira Issue ODMF2-14
Issue 10840: Annex A missing model library Jira Issue ODMF2-15
Issue 10841: RestrictionClass constraint [1]. Jira Issue ODMF2-16
Issue 10842: Section 8.2 wording Jira Issue ODMF2-17
Issue 10843: Annex D.2, OWL Full Jira Issue ODMF2-1
Issue 10845: Annex D.4 typo Jira Issue ODMF2-2
Issue 10847: Chapter 16 purpose Jira Issue ODMF2-18
Issue 10848: Metalevels Jira Issue ODMF2-3
Issue 10851: Classes and properties Jira Issue ODMF2-4
Issue 10852: Classes and properties wording Jira Issue ODMF2-19
Issue 10854: Class = set of instances Jira Issue ODMF2-20
Issue 10855: Extents. In Section 16.2.2 Jira Issue ODMF2-21
Issue 10856: Modeled instances Jira Issue ODMF2-22
Issue 10857: Table 16.5 Jira Issue ODMF2-23
Issue 10858: M0 implementation of a class Jira Issue ODMF2-24
Issue 10859: Name as instance Jira Issue ODMF2-5
Issue 10860: Concretely represented Jira Issue ODMF2-25
Issue 10861: UML Thing 1 Jira Issue ODMF2-26
Issue 10862: Table 16.6 Jira Issue ODMF2-27
Issue 10868: Page 188 formatting Jira Issue ODMF2-28
Issue 10869: N-aries Jira Issue ODMF2-6
Issue 10878: Restriction. Jira Issue ODMF2-7
Issue 10880: Constants Jira Issue ODMF2-8
Issue 10881: Herbrand semantics Jira Issue ODMF2-9
Issue 10882: Transitive closure Jira Issue ODMF2-10
Issue 10883: All/SomeValuesFrom Jira Issue ODMF2-11
Issue 10896: Behavioral Features Jira Issue ODMF2-12
Issue 10903: Symmetric Jira Issue ODMF2-13
Issue 11101: Common Logic Metamodel is out of sync with the ISO FDIS CL specification Jira Issue ODM-1
Issue 11103: Role name of superClass Jira Issue ODM-2
Issue 11104: Role name of superProperty Jira Issue ODM-3
Issue 11105: Bi-directional URIReferenceForNamespace association Jira Issue ODM-4
Issue 11106: Cardinality of OWLInverseOf Jira Issue ODM-5
Issue 11107: Set value for annotation property in UML profile for OWL Jira Issue ODM-6
Issue 11304: The RDF/S and XML Schema library has some metalevel mixups Jira Issue ODMF2-29
Issue 12386: RDFSDatatype uriRef Property Multiplicity Issue Jira Issue ODM11-159
Issue 12387: Specification: RDFSisDefinedBy text issue Jira Issue ODM11-160
Issue 12388: Specification: RDFSseeAlso text issue Jira Issue ODM11-161
Issue 12389: Specification: RDFType text issue Jira Issue ODM11-162
Issue 12391: OWL Annotation properties are impoverished in the OWL profile Jira Issue ODM11-163
Issue 12392: URIReferenceNode definition is misplaced in the specification Jira Issue ODM11-164
Issue 12393: URIReferenceNode constraint text Jira Issue ODM11-165
Issue 12395: OWL Cardinality Constraints text revision Jira Issue ODM11-166
Issue 12396: OWL Properties have conflicting definitions Jira Issue ODM11-167
Issue 12397: No stereotype for OWL individuals Jira Issue ODM11-168
Issue 12398: Definition of RDF Property and its use in the figures is inconsistent Jira Issue ODM11-169
Issue 12793: Design of RDF metamodel for rdf:Statement, triple, and graph controversial Jira Issue ODMF2-30

Issue 10839: UML References (odm-ftf)

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

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

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

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

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

Discussion:  OWL DL and OWL Lite prohibit "messing with the vocabulary".  This is intended to prevent users from changing the semantics of the language.  OWL Class is an element of this vocabulary.  When we asked Description Logic experts about this issue, they reported that the OWL DL semantics prohibits subclassing OWL Class.  This prohibition also holds for OWL Lite which is a syntactic subset of OWL DL.  Thus the text at issue is correct, subclassing OWL Class puts one into OWL Full.  Disposition:	Closed, no change  

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

Defer to 2nd FTF

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

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

Defer to 2nd FTF

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

Defer to 2nd FTF

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

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

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

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

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

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

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

Defer to 2nd FTF

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

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

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

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

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

Defer to 2nd FTF

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

Defer to 2nd FTF

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

Defer to 2nd FTF

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

Defer to 2nd FTF

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

Disposition:	See issue 10880 for disposition

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

Defer to 2nd FTF

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

Defer to 2nd FTF

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

Defer to 2nd FTF

Specification:  Ontology Definition Metamodel  FormalNumber: ptc/06-10-11  Section: 12  Summary: Common Logic Metamodel is out of sync with the ISO FDIS CL specification.      Description:  Minor changes were made to the CL language as it was finalized through the ISO process, which are not reflected in the ODM specification. These include text and diagram / model / xmi changes, which, although minor, should be resynchronized now that the ISO standardization process is complete

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

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

In section 10.7.3, URIReferenceForNamespace should be changed to two uni-directional associations between URIReference and Namespace. In the current model, if two URIReference have the same Namespace, it could not be represented.     

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

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

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

See issue 10840 for disposition

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

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

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

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

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

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

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

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

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

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

From email dated 3/12/2008 from SRI, and as discussed (and documented in the minutes from the ODM FTF2 F2F DC meeting: Section 14.1.7, In Figure 4.3 the line is an "association". However, the specified base classes are "AssociationClass" and "Property". To duplicate this example in Enterprise Architect, it was necessary to define a profile in which the rdfProperty stereotype extend the "Association" metaclass.  

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