Release Notes for CIDOC CRM in OWL, V. 3.4.9

Gereral Considerations

This is a first attempt at capturing the essence of the CIDOC CRM in the Web Ontology Language (OWL). It builds upon earlier RDFS encodings produced by the team of Martin Doerr at ICS FORTH, and an encoding in DAML released by the author early in 2003.

The CIDOC CRM reference document addresses human implementors rather than machines, deliberately being non-prescriptive in certain areas where requirements can vary between intended uses. Translating the model into a language designed for machine processing can blur the distinction between model and implementation. The approach taken here intends to maintain a balance between preserving the generality of the model on the one hand, and utilising some of the expressiveness of OWL on the other. Most definition elements characterized as implementation-dependent have therefore been left out, in particular property quantifiers (a.k.a. cardinality restrictions) and some distinctions between properties such as necessary and dependent. Scope notes and examples have also been left out, since these texts are intended for the human reader alone.

What has been included

Class definitions. These just carry the subclassOf relationship (if any) and a label property with a prettier spelling (without the underscore) of the class name.

Property definitions. A property definition carries the usual domain, range and, if applicable, subPropertyOf definitions plus a label element. In addition, the following distinctions and declarations are provided:

InverseOf. This provides the link between the definitions for the domain-to-range (e.g. P58F) and the inverse (e.g. P58B) direction of an asymmetric property.

Property types. All properties with different domain and range classes are assumed to be intransitive and asymmetric. This is expressed by declaring them as ObjectProperty without further type statements. Properties with identical domain and range are either declared as TransitiveProperty (if we can safely assume transitivity from the description in the scope note) or as ObjectProperty (if we have to assume intransitivity). Symmetric properties are declared by adding a corresponding type statement. Note that the case-by-case distinction between transitive and intransitive properties differs from the rule given in the reference document which states that properties with identical domain and range are either symmetric or transitive.

What about datatype properties?

The absence of datatype properties may raise the question of where to put one's data values when a class is instantiated. The answer is simple: define your own. Some properties have as range a subclass of E59.Primitive_Value. By defining a subproperty for one of these and declaring it as DatataypeProperty, the range definition can be replaced with a datatype, e.g. by selecting a type name from the XML schema type vocabulary:

<owl:DatatypeProperty rdf:ID="P57F.has_number_of_parts_1">
    <rdfs:domain rdf:resource="crm:E19.Physical_Object"/>
    <rdfs:range rdf:resource="xsd:nonNegativeInteger"/>
    <rdfs:subPropertyOf rdf:resource="crm:P57F.has_number_of_parts"/>
</owl:DatatypeProperty>

The idea here is to leave the original property definition untouched. Classes E60 to E62 are there to give an implementor some guidance as to what kind of datatype (numeric, temporal or text) may be appropriate in a given context.

Namespace

    http://cidoc.ics.forth.gr/OWL/crm3.4.9

05-Jan-2005 Detlev Balzer