A Owl lite ontology for Fedora 3.0 based on the CMA

Fedora rdf relations

Digital objects in Fedora can have rdf relations. The fedora system provides a triple store, enabling queries about these relations. Fedora does not allow for the full rdf specification, rather it uses a blob like the one below.

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:doms="http://doms.statsbiblioteket.dk/relations/default/0/1/#"
         xmlns:fedora-model="info:fedora/fedora-system:def/model#">
  <rdf:Description rdf:about="info:fedora/doms:ContentModel_DOMS">
    <fedora-model:hasModel rdf:resource="info:fedora/fedora-system:ContentModel-3.0"/>
    <doms:isPartOfCollection rdf:resource="info:fedora/doms:DOMS_Base_Collection"/>
    <doms:hasLicense rdf:resource="info:fedora/doms:Open_License" />
  </rdf:Description>
</rdf:RDF>

You begin with a RDF tag. The only allowed tag inside is the Description tag, which must be rdf:about the object itself. Inside the Description tag the relations from this object is defined, as tags with a rdf:resource attribute to designate the target. A relation is implicitly defined, by making an object have said relation to another object.

As you can see, this is a far cry from the full rdf standard. But it is sufficient to express the interrelations between objects. What Fedora really lacks is a way to express an ontology for these interrelated digital objects.

An OWL ontology

Describing an ontology for the entire repository of objects is only possible in OWL full. The reason is, the content models represents the class'es of objects, but they are at the same time objects themselves. This duality of existence is only possible in OWL full.

To keep the ontology expressable in OWL lite, we have decided on a fundamental restriction: The ontology only describes the data objects. In doing so, we do not need to regard the content models as objects.

Each data object contains the RELS-EXT datastream, containing the description of the data object. Each content model likewise contain such a description. In addition it contain an OWL datastream. The OWL datastream is a subset of true OWL lite, from the following rules.

• There must be a <owl:Class> element, rdf:about the content model itself. This is the only <owl:Class> element allowed

• The <owl:Class> element can contain property restrictions. The allowed restrictions are:

  • minCardinality (0-1)
  • maxCardinality (0-1)
  • cardinality (0-1)
  • someValuesFrom
  • allValuesFrom

• The allowed relations from the object should be defined as <owl:ObjectProperty>. No attributes, such as range or domain should be specified. Domain is always the objects of the current content model. Range is specified by the "allValuesFrom" restriction.

Such a datastream could look like this.

<owl:Class rdf:about="info:fedora/doms:CM_B">
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="http://www.statsbiblioteket.dk/doms-relations/#hasA"/>
      <owl:allValuesFrom rdf:resource="info:fedora:/doms:CM_A"/>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:about="http://www.statsbiblioteket.dk/doms-relations/#hasA"/>

Implications

Having an ontology for the data objects have one sudden implication. All relations become invalid, unless defined in the ontology. As the ontology for a specific data object reside in the attached content model(s), the relation must be defined in these.

Explicitly forbidding range and domain on a property has some odd implications for the ontology. Not having range means that the relation can point to whatever object in the repository, unless the class imposes some restrictions on it. But these restrictions are only on the relation in that class. Another class could use the same relation, with some other restrictions. Trusting the range of the relation mean that another bit of the ontology could add another range for the same relation, and thereby make something that should have been invalid somewhere else, valid. For domain the problem is different. As all relations allowed on a data object should be defined in it's content model, the domain is implicit, ie. objects of the content model's class.