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

Factor the Statements diagram in Figure 10.2 in RDFBase into 3 diagrams: Graph Data Model, Reification, and Graphs. This separates rdf triples from statements about them and creates a separate construct for Named Graph since it is not a part of the current rdf specification. The diagram for rdf:statements is now called Reification (rdfs calls this the reification vocabulary), the Graph Data Model diagram depicts triples, and the Graphs diagram depicts RDF graphs and named graphs. New subsections in RDFBase will be added for RDF Reification and Graphs: Reification after the Literals section and Graphs after Reification.
Places in odm metamodels which extended or otherwise referred to statements are changed to refer to triples. This includes the Documents model in the RDFWeb package and the Ontology model in OWLBase.
Changes include:
§ Changing section 10.2 from describing RDF Statements to describing Triples.
§ Revising figure 10.2 to describe triples, moving RDF Graph to 10.5, eliminating Reification kind, and introducing a supertype which is a complete and disjoint covering for URIReferenceNode, BlankNode, and RDFLiteral called Node for RDFSubject and RDFObject roles from Triple.
§ Adding a new section 10.4 called RDF Statements to describe the RDF reification vocabulary. Including a diagram describing Statements and its relationship to Triples.
§ Adding a new section 10.5 called Graphs describing rdf graphs and named triples. This includes a Graphs diagram depicting RDF Graphs and Named Graphs as separate classes and including associations on named graphs to for equivalentGraphs and subGraphs per the seminal named graphs reference.
§ Revising Documents and Namespaces in the RDFWeb package to refer to triples instead of statements and revising the Documents diagram accordingly.
§ Revising OWL Ontology section and diagram in the OWLBase package to refer to triples instead of statements and to eliminate

attribute for sets of triples.

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

Replace Annex A, in its entirety with the attached PDF revision. Revisions include:
§ Revised Table 30 to correct meta-level concerns raised in issue 11304
§ New Table 31 to provide library for RDF profile for XML Schema Datatypes
§ New Table 32 representing the missing model library for the OWL profile noted in issue 10840

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

Remove the text about this being problematic in UML.

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

Change the text to use less ambiguous wording.

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

Replace the word implementation with representation.

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

Change the formatting of the text near the bottom of page 188 which begins "The translation from UML to OWL is straightforward" to the end of the page to make this clearly all one paragraph.

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

Remove column with heading "Owned attributes" from Table 16.6 since the OWL analog to these attributes were not shown in this table. Note that the UML Owned attributes to owl:Property mapping for these classes is shown in table 16.7 on the next page of the document.

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

Fix the text to correct the statement about instances in a model library.

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

Fix the text to say that the extent consists of M0 objects.

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

The statement was meant to include the empty set. The sentence was slightly revised to make this clearer.

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

Fix the table to match the model specified in the earlier section.

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

Replace the entire first sentence of 16.1 Introduction as described below.

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

Replace text as indicated.

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

Replace text as indicated.

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

Replace Annex A, in its entirety with the attached PDF revision. Revisions include:
§ Revised Table 30 to correct meta-level concerns raised in issue 11304
§ New Table 31 to provide library for RDF profile for XML Schema Datatypes
§ New Table 32 representing the missing model library for the OWL profile noted in issue 10840

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

Author agreed with the issue. A replacement sentence was drafted leading to the fix below.

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

Replace references as indicated.

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

Replace text as described below.

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

Replace and append text as described below.

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

Replace text as described below.

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

Edit the text in the ninth paragraph of section 16.2.3 as described below.

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

Replace text as described below.

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

Replace text as described below

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

Replace text as described below

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

Replace and append text as described below.

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

Delete paragraph underneath table 16.5.

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

Replace text as described below

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

Replace text as described below

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

No Data Available

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

Replace text as requested.

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

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

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

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

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

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

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

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

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

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

Disposition: See issue 12391 for disposition

Specification: Ontology Definition Metamodel
FormalNumber: ptc/06-10-11
Section: 12
Summary: Common Logic Metamodel is out of sync with the ISO FDIS CL specification.

Description: Minor changes were made to the CL language as it was finalized through the ISO process, which are not reflected in the ODM specification. These include text and diagram / model / xmi changes, which, although minor, should be resynchronized now that the ISO standardization process is complete

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