Classes and Properties in Owl2java

In contrast to java OWL allows the definition of classes and properties independently. For both multiple language constructs are defined. On this page a short overview of the implications of these constructs for owl2java and the solutions developed are presented.

Pretext

Generating accessor methods for OWL ontologies in java needs to bridge the gap in the semantics of the different languages. Next to Closed-World vs. Open-World and the Unique-Name-Assumption in OWL another issue is the underlying understanding of inheritance in OWL and java.

In java inheritance allows to modify and extend a parent object. E. g. additional attributes or methods are defined; present methods are overwritten and hence changed. In OWL a different approach is chosen. Here, subclasses are assumed to restrict the degrees of freedom of a parent class. Examples:

  • A property with domain ClassA is disbaled in a subclass ClassB via a restriction myProperty max 0.
  • A Class MyClass intersectionOf(ClassA, ClassB) is classified as subclass of ClassA and ClassB by a reasoner. From a java perspective MyClass as intersection should be modelled as parent class of ClassA and ClassB

Therefore, not all concepts from OWL can be applied to native java interfaces.

In the following sections details about the relevant constructs of OWL Lite and OWL DL are presented. The implementation and handling of these constructs in Java is explained. Also, see the excellent paper Automatic Mapping of OWL Ontologies into Java about the generation of interfaces and classes from OWL. This work is mostly based on the solutions presented in the paper.

Classes and Properties

Classes and properties are key elements of any ontology. The list of possible constructs for these elements can be categorized as follows:

  • RDFS schema features
  • Class features and axioms
  • Property characteristics
  • Equality and Inequality
  • Versioning

Basic RDF schema features

Classes: In owl2java for each OWL Class a java interface and the implementing java class is generated. Properties are defined as class attributes with accessor methods following the java bean notation.

As java does not support multiple inheritance (but OWL does) interfaces are used to define the rdfs:subClassOf relationships. E. g. the OWL class definitions Class subClassOf ClassA and Class subClassOf ClassB* are defined via interfaces as follows:

  interface IClass extends IClassA, IClassB {}

The corresponding java class Class then implements the interface IClass hereby inheriting all methods and properties defined in IClassA, IClassB.

Properties: In OWL properties can be defined independently from OWL classes and without any definition of the type of the property. All unbound properties are assumed to have Owl:Thing as domain and a range of Owl:Thing for object properties or XMLLiteral for datatype properties.

In owl2java a base class and interface named Thing / IThing is defined in the base java package where all properties without a domain are defined. All defined classes in an ontology have the IThing interface as parent. For properties without a range the range is set to IThing for object properties or java.lang.String for datatype properties.

If a domain is defined for a property the property is added to the corresponding interface. According to the OWL standard for properties with multiple domains the intersection of the domain classes should be used. In contrast to the technical recommendation a property with multiple domains is added to each interface and class directly. Intersection classes are neither generated nor used as the approach chosen is a better fit with the java semantics.

In owl2java properties without a given domain are added to the root class OwlThing, i. e. the domain of the property is set to OwlThing. If enabled, for all properties without a domain but with existing allValuesFrom restrictions on a class, the domain is set to this class. If multiple classes are present the property is added to all classes.

A range defines the types a property can use have. For object properties the corresponding interface is used. For datatype properties the jena data types or a custom mapping from XSD datatype to java class can be used. For the latter, see the configuration options in XsdUtils.java.

Multiple ranges are handled as intersections for object properties. UnionClasses are generated for them, see comments.

For datatype properties multiple ranges are currently set to java.lang.String. Here, following the XML Schema Datatype Hierarchy it would be possible to find the nearest common datatype for the ranges given. E. g. a range of:

  property knows range xsd:long
  property knows range xsd:nonNegativeInteger

could be merged into the datatype xsd:integer.

Similar to the class hierarchy defined via rdfs:subClassOf a property hierarchy can be defined with rdfs:subPropertyOf definitions. Note that any range definitions on properties in a hierarchy are inherited bottom-up. A complement in java land does not exists.

From an implementation perspective adding a property value for a property and adhering to the property hierarchy would require that this value is also added to all parent properties in the class instance. Reversed, removing a property requires that the value is also removed from all child properties of the class instance. This is currently not implemented therefore use a reasoner to find these entailments.

Class features and axioms

In addition to the simple rdfs:subClassOf construct OWL Lite and especially OWL DL allows more complex constructs to define classes, namely with intersectionOf, unionOf, complementOf, disjointWith, oneOf.

For the first two construct types a new class is generated as the union or intersection of two or more primitive classes. For e. g. if a class MyClass is an intersection of ClassA and ClassB in OWL this is expressed via an internal anonymous class as follows:

  AnonClass intersectionOf(ClassA, ClassB)
  MyClass subClassOf AnonClass

The anonymous class does not have a valid URI and is thus not referenceable directly via a qualified name.

The java implementation creates new classes and interfaces, marked as anonymous, to represent anonymous classes and uses these interfaces as parents. For the naming schema used see NamingUtils.java. Identical anonymous class definitions in multiple OWL constructs are merged into a single java class / interface representation. E. g. the following OWL definition:

  A1 unionOf(ClassA, ClassB)
  MyClass subClassOf A1
  A2 unionOf(ClassA, ClassB)
  MyClass2 subClassOf A2

is defined in Java as:

  interface A1 extends ClassA, ClassB
  interface MyClass extends A1
  interface MyClass2 extends A1

Note though, that the concept of intersection classes is difficult to transfer to java. See the introduction above on this page.

A class defined as unionOf of two or more parent classes inherits all properties from all parent classes. Using an anonymous class for an owl construct MyClass unionOf(ClassA, ClassB) in java this is defined as follows:

  interface AnonClass extends ClassA, ClassB
  interface MyClass extends AnonClass

In contrast to the unionOf construct an intersectionOf defines a subclass that inherits only the properties and characteristics that are present in both parent classes or their instances. Using an anonymous class for an owl construct MyClass intersectionOf(ClassA, ClassB) in java this is defined as follows:

  interface AnonClass
  interface ClassA extends AnonClass
  interface ClassB extends AnonClass
  interface MyClass extends AnonClass

with the domain of all common properties changed to AnonClass.

For class constructs with complementOf and disjointWith no equivalent java constructs are available. These are ignored.

An enumerated class defined with a oneOf construct restricts the instances allowed to certain individual. In owl2java it would be possible to test upon creating an instance to a class if the instance is part of the oneOf construct. Currently, this is not supported as I do not see much benefit from such a solution.

Note: With OWL DL the set operators unionOf and intersectionOf can operate on arbitrary complex definitions. E. g. the following definition is valid OWL DL:

  WhiteWhine intersectionOf(Whine, Restriction(hasColor = #White))

For java this would require 1) the creation of an additional anonymous class / interface with the restriction on hasColor set and 2) registering the class WhiteWhine as subclass of the new anonymous class. With arbitrary complex constructs allowed the usability of the interface as well as the generation process can become arbitrarily complex.

Property characteristics

A property can either be an ObjectProperty or a DatatypeProperty. Object properties reference class instances while datatype properties contain values of a type according to XML Schema, see above.

Functional properties are properties that allow only a single instance of this property for a class instance, i.e. for an instance Peter the property knows can only have a single Item. In owl2java for functional properties as accessor methods only get/set/removed are generated. Any list-type accessor methods are removed hence restricting the property instance count to one.

Inverse functional properties can be seen as the logical opposite of functional properties. Here, any property triple can only be referenced by a single class instance. E. g. Peter knows Paul is valid iff no other person also knows Paul. The following is invalid:

   Peter knows Paul
   Henry knows Paul

Adding tests if a property value is used also from a second instance would require the implementation of property change listeners etc. Very complex and probably poor from a performance POV.

Transitive properties are often used to define part-whole dependencies. E. g. from a transitive property partOf and the following constructs Germany partOf Europe and Rostock partOf Germany it can be deduced that Rostock partOf Europe.
Support for
transitive properties* requires reasoning over all class instances in the model. Poor performance.

A symmetric property is a property where domain and range are equal and that is the instance of itself. They are treated as primitive properties with range and domain set accordingly. Also, it is guaranteed that for each modification to a property instance the inverse property is modified, too. E. g. if a construct Peter knows Paul is added to the model, the construct Paul knows Peter is added simultaneously by the generated java code.

inverseOf object properties define “links” in the opposite direction of the property they reference. E. g. for the construct Peter parentOf Paul the inverse property is Paul childOf Peter. To keep the ontology consistent in owl2java upon adding, changing or removing a property value the corresponding values of inverse properties are changed accordingly.

Equality and Inequality

With OWL proposition about equality and inequality are possible on the class, property and instance level. With the scope of owl2javav in mind statements about individuals as done via the sameAs and differentFrom statement are ignored. As java does not adhere to the open world assumption but treats each individual as instance as unique the construct AllDifferent can also be ignored.

The equivalentClass and equivalentProperty constructs are used to define necessary and sufficient conditions for a class or property i. e. to state an axiom about an item.

For primitive definitions like ClassA equivalentClass ClassB equivalent classes and properties are handled. Creation of an instance of ClassA leads to the creation of an instance of ClassB and vica versa.

For more complex definitions currently no support is available. Any distinction between necessary (rdfs:subClassOf) and necessary and sufficient (owl:equivalentClass) declarations as stated by OWL is ignored. See the explanations regarding unionOf above.

Versioning

Under the aspect of versioning meta-data about properties and classes can be defined. As these only add sugar to the cake aka ontology they are ignored.

In the long run it would be possible to evaluate the DeprecatedClass and DeprecatedProperty definitions and mark the classes or accessor methods with @Deprecated java annotations.