DAML+OIL (March 2001) version (revision 4.1): Ian Horrocks, Frank van Harmelen and Peter Patel-Schneider, editors.
The idea behind DAML+OIL (March 2001) is to extend DAML+OIL (December 2000) with arbitrary datatypes from the XML Schema type system (http://www.w3.org/TR/xmlschema-2/#typesystem), while still retaining the desirable properties of the ontology language, in particular its (relative) simplicity and its well defined semantics. This is achieved by maintaining a clear separation between instances of "object" classes (those defined using our ontology language) and instances of datatypes (defined using the XML Schema type system). In particular, it is assumed that the domain of interpretation of object classes is disjoint from the domain of interpretation of datatypes, so that an instance of an object class (e.g., Leo the Lion) can never have the same interpretation as a value of a datatype (e.g., the integer 5), and that the set of object properties (which map individuals to individuals) is disjoint from the set of datatype properties (which map individuals to datatype values).
The disjointness of object and datatype domains is motivated by both philosophical and pragmatic considerations:
The proposal is to add new classes "daml:Class" and "daml:Datatype"; instances of the former are object classes while instances of the latter are datatypes. Similarly, we have the classes "daml:ObjectProperty" and "DatatypeProperty", instances of which are object and datatype properties respectively.
From a theoretical point of view, this means that the ontology language can specify the existence of a value that is an instance of one or more datatypes. However, as data values can never be instances of object classes, they cannot apply additional constraints to objects in the object domain: we cannot, for example, assert that all objects associated with the integer value 5 via the hasAge property (the inverse of the age property) must be instances of the class Giraffe. This facilitates extensibility, allowing the type system to be extended without having any impact on the object class (ontology) language, and vice versa. Similarly, reasoning components can be independently developed and trivially combined to give a hybrid reasoner whose properties are determined by those of the two components; in particular, the combined reasoner will be sound and complete if both components are sound and complete.
From a practical point of view, daml+oil implementations can choose to support some or all of the XML Schema datatypes. For supported data types, they can either implement their own type checker/validater or rely on some external component. Non-supported data types can either be trapped as an error or ignored.
The job of a type checker/validater is to take zero or more data values and one or more datatypes, and determine if there exists any data value that is equal to every one of the specified data values and is an instance of every one of the specified data types.
$Revision: 1.3 $ of $Date: 2001/03/28 00:45:00 $.