Issues for Mailing list of the Ontology Definition Metamodel (ODM) 1.1 Revision Task Force

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

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

Issue 13074: Section: 10.2.2
Issue 13075: Section: 10.9.3
Issue 13937: Section: Appendix A, Section A.3
Issue 13938: NamespaceDefinition is defined as a metaclass, without a stereotype
Issue 13940: Section: 14.2.8.1
Issue 13977: rdfsDomain/Range should be based on dependency.
Issue 13978: Section: UML Profile for OWL and RDF
Issue 13979: Figure 14.10 missing property subsetting
Issue 13980: owlValue and allValuesFrom
Issue 13981: Figure 14.19 is property subsetting
Issue 13982: owlValue and allValuesFrom 2
Issue 13983: RDFGlobalProperty shouldn't apply to classes
Issue 13984: rdfsDomain/Range should be based on dependency 2
Issue 13985: rdfsDomain/Range should be based on dependency 3
Issue 13986: RDFProperty, RDFObjectProperty, and RDFDatatypeProperty shouldn't apply to classes
Issue 14425: rdfs:Literal

Issue 13074: Section: 10.2.2 (odm-rtf)

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!

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

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

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.

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

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. 

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. 

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

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? 

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. 

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. 

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. 

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

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

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

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.