The title of Section 11.2.2 is "RDFSLiteral (Augmented Definition)". Class RDFSLiteral has been renamed to Literal, so the title should change.
Triples are necessary to state certain semantics in the metamodel (as opposed to the profile). For example, property assertions must be expressed using triples. The metamodel sections do not state how and when triples are to be used.
This issue requests that documentation be added to metamodel sections describing how to use triples.
There is a general lack of composition relationships for model management in both the RDF and OWL metamodels
Because of the composition relationships in the current RDF and OWL metamodels, it is not possible to create a model that:
Class NamedGraph is the only class that can own Namespace (that is, the association between NamedGraph and Namespace is the only composite association involving Namespace). Therefore, a model with an instance of Namespace must either be serialized with a root element of Namespace or NamedGraph. In either case, the serialization cannot contain a Source or a NamespaceDefinition. No associations in the metamodel allow a Namespace or a NamedGraph to own a Source or a NamespaceDefinition, either directly or indirectly.
Conversely, a model with a Source has no serialization in which the Source can own, directly or indirectly, a Namespace.
The serialization of an ontology represented using the metamodel must contain (at least) two instances of metamodel classes. This is problematic for ECore, where the persistent representation of an ontology must exist in multiple files.
Section 10.4.2 states:
All things described by RDF are called resources. This is the class of everything. All other classes are subclasses of this
class.
This is true of RDF, but it is not true of the RDF metamodel. Class RDFSResource is not the superclass of all classes in the RDF metamodel. The paragraph should be rewritten to clarify that it applies to RDF but not the RDF metamodel.
In the OWL metamodel, class CardinalityRestriction has an association with ClassExpression but not with DataRange. Consequently, the metamodel can represent a cardinality restriction such as:
objProp exactly 1 cls
and
dataProp exactly 1
but not
dataProp exactly 1 xsd:string
The metamodel does associate SomeValuesFromRestriction and AllValuesFromRestriction with both ClassExpression and DataRange. It needs the corresponding association for CardinalityRestriction.
OWLDatatype specializes DataRange, which specializes RDFSClass. But the OWL 2 Mapping to RDF Graphs states in Table 1 that an OWL datatype maps to the triple:
T(DT) rdf:type rdfs:Datatype .
OWLDatatype should specialize RDFSDatatype rather than RDFSClass.
Classes DataIntersectionOf, DataUnionOf, DataComplementOf, DataOneOf, and DatatypeRestriction also map to triples of this form. Together with OWLDatatype, that's all the subclasses of DataRange. Should DataRange specialize RDFSDatatype instead of RDFSClass?
The second association for class Document in the RDF metamodel (Section 10.8.1) is to Namespace, with role name xmlBase. The association's name is DefaultNamespaceForDocument. There is no corresponding association for Namespace (10.8.2). Association DefaultNamespaceForDocument exists between classes Source and Namespace. That role name is defaultNamespace, not xmlBase. Source has an association with role name xmlBase, but the associated class is IRI.
Given that an association to Namespace exists in a superclass of Document, the xmlBase association is either redundant or a specialization that needs to be further described.
Also, should the association between Source and Namespace be named DefaultNamespaceForSource instead of DefaultNamespaceForDocument?
Section 11.6.1 describes how the OWL DataRange concept is modeled. Its Constraint [1] has the phrase "ClassExpressions must be anonymous". The phrase should read "DataRanges must be anonymous".
In Figure 11.4, both classes DataRange and ClassExpression have two associations whose role names are "restrictionClass". UML does not permit a class to have multiple associations with the same role name.
This issue is being reported based on Figure 11.4, but it affects sections 11.3.1 and 11.6.1 as well.
Annex G (MOF QVT: A Brief Tutorial) contains some statements that are incorrect or incomplete:
Annex D illustrates transforming between UML and OWL using an example that shows courses, students, their relationships, and their properties. The examples are presented in fragments throughout section D.2. Readers would benefit from access to complete UML and RDF models. Furthermore, these models being definitive, rigorous, and complete, they would be the basis for the figures and tables in Section D.2 (and perhaps elsewhere in Annex D).
This issue includes two attachments:
These models are informative, not normative.
There are still mentions of OWL Full and OWL DL
The xmi for the RDF profile has been substantially simplified for ODM 1.1, but the section of the RDF profile in the document does not match the xmi. This should be corrected in the 1.2 RTF.
This section describes problems with MOF/UML due to the need to work around multiple classification issues, which was fixed by SMOF. The specification needs to be revised to (1) state that no changes are required to other OMG specs, (2) update references and add SMOF, and (3) add a discussion of the need for SMOF in the design principles section (section 7)
References in the profile section need to be revised to reflect UML 2.4.1 / 2.5 documents, and any new references need to be incorporated into chapters 3 and 19.
In Figure 10.8, class Graph has associations to classes Dataset and Source. Both these associations have role name "root". That is not valid, because it creates ambiguity in OCL expressions.
Multiple Domains or Ranges for Properties. Section 16.4.1.4 (Multiple Domains or Ranges for Properties) says that multiple domains or ranges for properties is equivalent to the intersection of the domains and ranges. UML properties have at most one type, and intersection can't be represented in UML without the profile (Chapter 14). How is this translated?
complementOf and disjointWith. Section 16.4.1.3 (Mapping for complementOf and disjointWith) says UML has constructions for complementOf and disjointWith in the PowerTypes pacakge. It actually has constructs for unionOf and disjointWith. Section 16.4.1.3 says no mapping is given because the OWL constructs are pairwise, but OWL unionOf and disjointWith are not pairwise, they can apply to any number of classes.
Inferring subsumption. In Section 16.5.1 (Predicate Definition Language), first sentence, UML can support subsumption reasoning also, see http://www.inf.unibz.it/~calvanese/papers-html/AIJ-2005.html
Figure 16.1 incomplete. Figure 16.1 (Key Aspects of UML Class Diagram) is missing the multiplicities on general/specific, and the subsetting between ownedEnd and memberEnd.
Range Restriction Restriction Classes. The introduction to Section 16.4.8 (Range Restriction Restriction Classes) says the translation is to a comments. But AllValuesFrom translates directly to redefinition of property types, see the profile (Chapter 14).
Constructed Classes. The introduction to Section 16.4.6 (Constructed Classes) refers to OWL "difference". I assume this is supposed to be complementOf. The introduction to the section says intersection can be mapped to subclass relationships, but this isn't true, at least not without the profile, see intersection in Chapter 14. It also says union can be translated to subclass relationships, but doesn't mention UML generalization sets and isCovering, see Section 16.3.10 (Powertypes).
Anonymous Classes. Section 16.4.4.3 (Anonymous Class to Class) can translate blank nodes to anonymous classes in UML.
Ontology Properties. Section 16.4.3.2 (Ontology Properties to Comments) should use dependencies for some of the translations. See the profile (Chapter 14).
Properties in OWL. The end of Section 16.4.9 (Properties in OWL) refers to multiple domains be ing equivalent to the domain being an intersection. This does not translate to UML, see issue on Constructed Classes
Annex D has several OWL examples that use the rdf:resource attribute in which the attribute's value is, I think, meant to be prefixed with a "#". For example, in Table D-7,
<rdfs:domain rdf:resource="Course"/>
should be:
<rdfs:domain rdf:resource="#Course"/>
The current conformance section includes requirements that have been made invalid by removal of the RDFWeb package in the metamodel, among other things. The entire section needs a rewrite to reflect changes made for RTF 1.1.
In 14 places, the ODM specification uses OWLDataRange: 12 times in the metamodel and twice in Annex D. The metamodel defines class DataRange, not OWLDataRange.
The first paragraph in section D.4.5.2 says Table A.4 in Annex A has the UML elements for OWL. These elements are now in Table A.6. The text needs to be brought up to date.
In the Associations for NamedGraph (Section 10.8.5, p. 55):
The second association for Document (Section 10.8.1, p. 53) has role xmlBase. Is this a legacy of a previous version? The role name isn't in Figure 10.8, and the description references association DefaultNamespaceForDocument, which is between Source and Namespace.
In section 10.4.3, in the Associations section, the 2nd bullet has "RDFSProperty" as the type of the RDFpredicate role. It should be RDFProperty.
Annex D uses a simple example, comprising courses, students, instructors, and their relationships. It presents this example in both UML and OWL. The OWL is fragmentary. A non-normative, machine-readable OWL file would resolve questions about the ontology's exact content.
navigableOwnedEnd. The introduction to Section 16.3.5 (Binary Association To Object Property) accounts for navigableOwnedEnd, but the introduction to Section 16.3.8 () Association Generalization) does not.
Table 16.12, classes as instances. In 16.2.3 (More Advanced Concepts), Table 16.12, class as instances appears in both this table and Table 16.11.
Table 16.10. In 16.2.3 (More Advanced Concepts), Table 16.10, the names of classes are capitalized in UML. The UML element corresponding to OWL subproperty is property subsetting. N-aries and association classes are not well-supported in OWL, so don't belong in a table of common features (see other issues on n-aries and association classes).
Classes of classes. In 16.2.3 (More Advanced Concepts), seventh paragraph, the second sentence implies classes are not instances in OWL DL, but even in DL, OWL Class is a class of classes, by definition. For example, an ontology of animals might have the class Dog, which is an instance (of OWL Class) and a class (of Fido, Rover, and other individual dogs). Ther third sentence should be moved to be the second, and start with "however"|, because it is an exception to the first sentence. After "declaration" should be replaced wtih "a common superclass".
Table 16.9 and Naries. In 16.2.2 (Class and Property - Basics), Table 16.9 replace the "Parts" header with "Properties". The Reification property isn't necessary, because AssociationClass is both a class and association, there is no separate reification of the association (this is necessary in OWL DL, however, and even in OWL Full, some extension is needed for a subclass of Property and Class to correspond to a UML Association Class). The text below the table uses the term "implements" which doesn't apply (these are platform-dependent models), and introduces the reified association, which doesn't exist in UML.
Multiplicity. Section 16.3.7 (Multiplicity), the translation can also be to OWL FunctionalProperty or InverseFunctionalProperty if the multiplicity is 1.
Names, unique names. In Section 16.5.2 (Names), the first two paragraph implies UML assumes unqiue names. M1 instance specifications in UML can have different names, but refer to the same M0 individual. They can also have the same name and refer to different M0 individuals. The third paragraph implies UML does not have name management (given the title of Section 16.5), which of course it does in namespaces.
Individuals, mapping. Section 16.4.1.1 (Mapping for Individuals), first sentence says the profile (Chapter 14) represents individuals as a singleton class. This is incorrect. The profile models individuals as instance specifications. To give property values to the individual, the profile uses a singleton class. Section 16.4.1.1 incorrectly concludes that individuals should not be mapped, which affects 16.4.1.2 (Mapping for Enumerated Classes) and Section 16.4.13 (Annotation Properties to Comments).
Boolean combination. In Section 16.5.1 (Predicate Definition Language), third sentence, UML supports the equivalent of unionOf.
The second sentence of Annex D.2.2 reads as follows:
A class in OWL is a set of zero or more instances.
An OWL class consists of individuals, not instances. The sentence should be changed to use OWL terminology.
Associations. In 16.2.2 (Class and Property - Basics), in the paragraph below Table 16.7, gives the wrong translation to OWL for UML associations. UML associations have properties at end, and these are often navigable. Binary associations in UML translate to two inverse properties, using these property names, not the association name. See the UML profile for OWL for the translation options for associations, and the third paragraph in 16.2.3.
Distinct associations, restrictions. In 16.2.2 (Class and Property - Basics), in the paragraph above Table 16.7, says the OWL properties "arising" (I assume due to translation) from a UML model are distinct, that OWL restrictions aren't in the translation. UML can redefine properties in subtypes of the classes where the property is introduced, which is equivalent to restriction. The method employed in the chapter is not adequate.
Distinct associations, ownedAttribute associations. In 16.2.2 (Class and Property - Basics), in the paragraph below Table 16.6, there is the sentence " Note that UML ownedAttribute M2 associations are distinct, even if ownedAttributes have the same name associated with different classes." What are "M2 owned attribute associations"? In the case of M1 properties, properties with the same name may be on different classes, but if they inherit from the same base class where a property of that name is introduced, then they are the same property from OWL's point of view. There is usually no no need to translate to unique OWL properties, just restrictions. See next issue.
Associations. In Section 16.2.1 (UML Kernel), the discussion around Tables 16.2 through 16.4 seems to be about relational implementations, rather than UML modeling in the sense that is important to OWL. My suggestion is to replace Tables 16.3 and 16.4 with the tabular forms of the metamodel, as in 16.2. The paragraph above Table 16.3, first sentence, modeling associations does not depend on the implementation of classes (the "implementation" usually refers to how the model is translated to a platform). Same comment on the second sentence, which says Table 16.2 is an implementation, when it is only a tabular form of the metamodel. The second sentence refers to the disjoint union of attributes, but there's nothing like this in UML.
ODM's metamodels are based on UML 2.4.1, which was formalized in August 2011. UML 2.5 was formalized in June 2015. ODM should switch to UML 2.5 as soon is as practical.
The diagram (Figure 9.1) and related text is out of date given the revisions made to the ODM metamodels by the 1.1 RTF.
Representation of Axioms
OWL2 uses Axioms to represent several capabilities, whereas ODM has them either as binary associations or not at all.
In OWL these axioms are represented as a blank node so should have a metamodel element: that is necessary to allow the statement itself to be associated with an ontology/document.
ODM has OWLAllDifferent which inherits from OWLClass which does not make sense.
In the metamodel there should be a top level class representing Axiom with the following subclasses:
Representation of Axioms
OWL2 uses Axioms to represent several capabilities, whereas ODM has them either as binary associations or not at all.
In OWL these axioms are represented as a blank node so should have a metamodel element: that is necessary to allow the statement itself to be associated with an ontology/document.
ODM has OWLAllDifferent which inherits from OWLClass which does not make sense.
In the metamodel there should be a top level class representing Axiom with the following subclasses:
The ODM Metamodel takes a different approach to OWL restrictions from the Profile (and indeed from OWL): the Profile has a single stereotype Restriction whereas the Metamodel has 6 different subclasses depending on the type of restriction: HasValueRestriction, AllValuesFromRestriction, CardinalityRestriction etc. It would be more consistent if the metamodel had only a single class, though this would necessitate constraints on the properties.
The specification is sorely in need of examples showing how to represent common RDF/OWL constructs as instances of the metamodel. That’s especially the case for use of URIs and IDs; and also for anonymous classes as used in Restrictions and Intersections
Summary: Constraints in the OWL Metamodel Chapter (10) should be specified in OCL.
Description: Text based descriptions of constraints provided in chapter 11 with the OWL metamodel should be specified in OCL.
Summary: Constraints in the RDF Metamodel Chapter (10) should be specified in OCL.
Description: Text based descriptions of constraints provided in chapter 10 with the RDF metamodel should be specified in OCL.
OWLOntology::owlUniverse is not documented in fact it’s in 11.7.2 which should be moved
In 10.6.3, RDFSisDefinedBy should be a subproperty of seeAlso
In 10.6.2 the property “resource” does not seem right
In 10.6.3 the constraints should not refer to IRIs but linked objects
On Triple (mis-named RDF Triple in the spec), statement, document are not documented. Actually statement is in 10.4.4 which should be moved.
On RDFSResource, groupingNamespace, RDFSLabel, RDFSComment, are not documented. Actually the latter are in 10.3.2 which should be moved
OWLAllDifferent should specialize ClassExpression not OWLClass
Question section 11.2.3 RDFSLiteral (Augmented)
10.9.8 does not document bNode
In 10.9.7, graphForNG should be just graph
In 10.9.4 the attribute namespacePrefix should be just prefix
In 10.9.1, Document::xmlBase should be deleted (it’s on Source now)
The association between Document and Triple in Figure 10.8 shows multiplicity 0..* for the "triple" role. In Section 10.8.1, the association's multiplicity is 1..*.
The Description in Section 10.2.2 states that ReferenceNode, BlankNode, and Literal form a complete and disjoint covering of Node. That means Node is an abstract class. For consistency with the «node» stereotype (Section 14.1.3.5), Section 10.2.2 should describe it as such.
ODM metamodel needs a Package concept for managing a structure for ontologies, akin to the use of UML Packages in the Profile.
In fact, the use of UML Packages in ontology models is outside the documented profile. There is nothing to say, for example, that the package structure should mirror the URI structure and/or whether it matters whether they differ.
Despite the fact that the RDF/OWL languages do not have Package, they do make use of folders/directories in wither filestore or on the web.
And ontologies like FIBO now have metadata at the package/folder level but neither the metamodel nor the profile provide any place to hang these.
Finally packages provide a much-needed scoping mechanism for applying various operations which become increasingly impractical as the number of leaf-level ontologies has already exceeded 400 for FIBO
Remove sub-packages of OWL metamodel
With OWL 2 no longer making a distinction between OWL DL and OWL Full it does not make sense to have separate ODM packages for these: there should just be one OWL package/metamodel.
Via the resolution to issue 16495, the ODM metamodels and profiles for RDF and OWL were revised to support internationalized URIs (IRIs). Chapter 17, which covers the mapping from Topic Maps to OWL, has not been updated to reflect this modification however. The chapter needs to be updated to be brought in line with these changes.
Currently, the ODM 1.0 specification defines several stereotypes for representing an OWL ontology in UML using the ODM stereotypes for RDF and OWL.
The ODM spec is understandably updated to support OWL2, the current recommendation from the W3C.
It is not entirely clear which OWL2 constructs are supported in the ODM profile a cross-reference table linking the entries of the quick ref. guide would be particularly helpful: http://www.w3.org/TR/owl2-quick-reference/
Also, in practice, it would be useful to have the flexibility of showing come axioms but not others.
For example, if we have (in functional syntax):
Declaration( Class( A ))
Declaration( Class( B ))
Declaration( Class( C ))
SubCassOf( A B )
SubCassOf( B C )
Then, an OWL2 reasoner will infer the following axiom:
SubCassOf( A C )
Using the ODM profile, it should be possible to show selected subsets of an ontology.
For example:
view1:
Declaration( Class( A ))
Declaration( Class( B ))
Declaration( Class( C ))
SubCassOf( A B )
SubCassOf( B C )
view2:
Declaration( Class( A ))
Declaration( Class( B ))
Declaration( Class( C ))
SubCassOf( A B )
SubCassOf( B C )
SubCassOf( A C )
view3:
Declaration( Class( A ))
Declaration( Class( C ))
SubCassOf( A C )
This brings up the question of adding support in the ODM profile to distinguish asserted vs. inferred axioms.
Perhaps there could be a flag e.g.,
isAsserted : Boolean = true // set it to false for an inferred axiom or--
isInferred : Boolean = false // set it to true for an inferred axiom
Finally, additional markup may be useful e.g., showing whether an ontology is consistent or not.
Users creating domain ontologies want their models to be user friendly and this requires phrases with spaces and other special characters. The use of “camel case” and other I.T. conventions are not friendly, however OWL has restrictions on the characters that may be used.
Potential resolution: ODM should specify the algorithm for mapping a user friendly names in the UML profile to an OWL legal name where required. The user friendly name can and should be used in the OWL label and does not require such mapping. The choice of algorithm can be to eliminate the space and enforce camel case or to substitute underscores for all illegal characters. My preference would be to introduce underscores as these are then easier to reverse map from OWL to UML and are visually similar to spaces.
Stereotypes should be shown on diagrams in an abstract syntax section under each profile, not only in text under each stereotype.
From email dated 3/12/2008 from SRI, and as discussed (and documented in the minutes from the ODM FTF2 F2F DC meeting: Section 14.2.6.5 - Simple association with properties at the end is a nice readable notation. However, the "brotherOf" property between the two classes in Figure 14.28 could be duplicated on an association between two other classes on the same diagram, but the would be unrelated in the UML model, whereas in OWL they would be a single property with multiple domains and ranges. (This comment applies also to similar graphical representation shown in other sections). So – this is true. It is managed in UML via the namespace of the relation, which may assume that you're not trying to determine all possible values with each property. The example is not a good one and could lead to inconsistent interpretation. We should get a better example. Also, we need to decide what the interpretation of the role name is, when you have mutiples (when you assume that it is or is not in the same namespace).
Specification: Ontology Definition Metamodel
FormalNumber: ptc/06-10-11
Section: 18
Summary: The mapping from RDFS and OWL to CL should be revised to reflect metamodel changes in CL due to finalization of ISO 24707.
Description: Minor changes were made to the CL language as it was finalized through the ISO process, which are not reflected in the ODM specification. These changes also need to be reflected in the mapping (embedding) description contained in chapter 18.
In the CL metamodel the associations Conjunction and Disjunction clash with class names. This is not strictly speaking an error at MOF 2 but can cause difficulty for some implementations. And these do not make good associations names. I propose: ConjoinedSentence and DisjoinedSentence (which will make them consistent with NegatedSentence).
The current ODM specification is lacking stereotype definitions for containers and collections. The entire section in the profile amounts to one sentence that references an annex. The section should be revised to provide stereotypes for these elements.
The profiles submitted with the RTF report include stereotype definitions that are not in the submitted RTF report itself. These represent work in progress that the RTF felt should be left in the submitted profiles but that are subject to change/reconciliation in the 1.2 RTF.
Via the resolution to issue 16495, the ODM metamodels and profiles for RDF and OWL were revised to support internationalized URIs (IRIs).
Chapter 16, which covers the mapping from UML to OWL, has not been updated to reflect this modification however. The chapter needs to be updated to be brought in line with these changes.
The section numbers refer to the 1.1 convenience document
The set of implementations referenced is out of date and should be revised to discuss current implementations.
n table A-4, the cell in the second column of row 1 contains the stereotype «rdfsContainerMembershipProperty». This name has been changed to «containerMembershipProperty» in version 1.1.
OWLOntologyProperty is obsolete
Constraint [1] of AnnotationProperty still has URIReference and RDFLLiteral
These datatypes were added in OWL 2, and should be supported in the metamodel, profile and related libraries.
The OWL 2 top and bottom object and data properties should be represented in the metamodel and profile (possibly as additions to the libraries in Annex A).
Pairwise disjoint classes and disjoint unions are only partially supported in the ODM 1.1. Representation should be completed for both the OWL metamodel and profile.
Property chains were added as a feature of OWL 2 and need to be supported in the ODM metamodel and profile.
Inverse property expressions were new in OWL 2 and support for them needs to be added to the ODM specification.
In ODM 1.1, partial support for hasSelf property restrictions were added to the metamodel and profile for OWL. This support needs to be fully integrated, and at a minimum, an additional stereotype should be provided in the profile.
This is a bulk report of minor problems I've identified in the specification. The following is a CSV-format list that can be read by a spreadsheet application.
Page,Location,Problem,Fix
38,"Section 10.2.6, Description, paragraph 1","""RFC3986"" should be ""RFC 3986"", consistent with ""RFC 3987"" in the same paragraph.",
38,"Section 10.2.6, Description, paragraph 2","""RFC3986"" should be ""RFC 3986"".",
38,"Section 10.2.5, Constraints, paragraph 1, sentence 2","""However, in any case"" is redundant.","Replace ""However, in any case,"" with ""However,""."
44,"Section 10.5.2, Semantics, paragraph 2",The sentence beginning on the third line is run-in and the second part is incomplete.,"Change the sentence to ""Such features may in the future be provided to support, for example, more elaborate datatype conditions."""
50,"Section 10.8, paragraph 1",Replace hyphen with dash in line 3.,
50,"Section 10.8, paragraph 1",Missing comma.,"Change ""prefixes and URIs"" to ""prefixes and IRIs,""."
51,Last paragraph,Missing period at end of sentence.,
53,"Section 10.8.2, Description, paragraph 1","The article modifying ""IRI"" is incorrect.","Change ""a IRI"" to ""an IRI""."
54,"Section 10.8.2, Constraints",Remove the quotation marks around [XMLNS].,
56,"Section 10.8.8, Associations, bullet 1","Change ""NameSpace"" to ""Namespace"".
Missing period at end of sentence.",
73,"Section 11.3.8.1, Description, First paragraph",Missing period at end of last sentence.,
77,"Section 11.3.8.9, Constraints, paragraph 1",Missing period at end of sentence.,
82,"Section 11.5, title",Replace hyphen with dash.,
83,"Section 11.6, paragraph 2",The first sentence is run-in.,"Change ""data values,"" to ""data values:""."
173,"Section 14.2.5, paragraph 1","On the last line, replace ""classes,"" with ""classes"".",
174,"Section 14.2.5.1, Description, paragraph 2, sentence 1",The use of passive voice reduces specificity.,"Change
owl:Class is defined as a subclass of rdfs:Class.
to
[OWL SS&FS] defines owl:Class as a subclass of rdfs:Class."
199,"Section 14.2.6.3, Description, paragraph 1",The first sentence is missing a comma.,"Change ""in the profile"" to ""in the profile,""."
207,"Section 14.2.7.5, Description, paragraph 1","The use of commas in the first sentence decreases readability: it's not immediately obvious how to read ""OWL properties"".","Change ""OWL properties"" to ""OWL, properties""."
207,"Section 14.2.7.5, Stereotype and Base Class, paragraph 1",The first sentence is run-in.,"Change ""No stereotype,"" to ""No stereotype;""."
Figure 14.19 shows an association labeled "Imports" between packages OWL and RDF. Should it be a dependency stereotyped «import»? That's what the UML specifications describe.
Fig. 14.3 shows the first 3 properties of «statement» named RDFsubject, RDFpredicate, and RDFobject. Section 14.1.3.9 lists properties named subject, predicate, and object. The names need to be consistent.
The ODM Metamodel and Profile should support OWL2 n-ary datatype hook and universal and existential restriction on n-ary data ranges
A number of stereotypes are given in section 14.2.5.3 for dependencies to be used with restrictions are incompletely defined in ODM 1.1.
Line 87 of the OWL profile (http://www.omg.org/ODM/20130801/OWLProfile.xml) has an element named annotationProperty. This is the v1.0 name. In 1.1 the name is owlAnnotation (cf. Section 14.2.3.1).
In the GraphicalRepresentation section of owl:equivalentClass, the text says the representation is a dashed line, but Figure 14.41 shows a solid line.
The "Stereotype and Base Class" section of 14.2.4.3 states that the base class of «owlImports» is UML::PackageImports. The class name is PackageImport (i.e., it doesn't end with "s").
I was working on the FIBO UML files and came across some XMI issues with the ODM XMI[PJR] for RDFLibrary: It has an erroneous import of OWLProfile and it uses .xml instead of .xmi for the RDFProfile.
Proposed resolution:
The lines at 402 of RDFLibrary.xmi are currently:
<uml:Package xmi:id="_16_6_1_15100de_1266442802908_497608_344" name="rdf" URI="http://www.omg.org/spec/ODM/20131101/RDFLibrary.xmi">
<profileApplication xmi:type="uml:ProfileApplication" xmlns:RDFProfile="http://www.magicdraw.com/schemas/RDFProfile.xmi" xmi:id="_RDFProfile-Application" xmlns:OWLProfile="http://www.magicdraw.com/schemas/OWLProfile.xmi">
<appliedProfile href="http://www.omg.org/spec/ODM/20131101/RDFProfile.xml#_12_5_1_137b03ac_1193948135234_354269_2454"/>
And should be as follows:
<uml:Package xmi:id="_16_6_1_15100de_1266442802908_497608_344" name="rdf" URI="http://www.omg.org/spec/ODM/20131101/RDFLibrary.xmi">
<profileApplication xmi:type="uml:ProfileApplication" xmi:id="_RDFProfile-Application">
<appliedProfile href="http://www.omg.org/spec/ODM/20131101/RDFProfile.xmi#_12_5_1_137b03ac_1193948135234_354269_2454"/>
