Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

In the following these shorthands will refer to the following namespaces

...

So, with this property, we separated the content model objects, from the classes they represent. The content model (ie. the content model identifier) represents the digital object. Classes are identified as "info:fedora/{contentmodelPID}#Class#class".

An ontology with implicit rules, properties or classes, could lead to some potential problems. When part of the ontology is derived from the whole ontology, the effects of changes to the ontology can become difficult to predict. Especially the removal or introduction of a class could affect the nature of other classes. In effect, this means that someone wanting to use the ontology must know the entire ontology, in order to extrapolate anything implicit, which is in conflict with property 1. To make this explicit, the third property is introduced:

...

Instead of "rdf:range", one should use the "allValuesFrom" restriction. This restriction defines a range for the property, but only in the context of the given class. As such, the restriction will have no global effect. "rdf:domain" is just not nessesary. The property 3 implies that the ONTOLOGY in a Content Model should describe the local area, i.e. the objects subscribing to that content model. The result of this is that the domain, so to speak, of a property will always be the Content Model in which it was defined. But again, this restriction will have no global effect, the property defined somewhere else will have some other Content Model as its domain.

Ontologies in practice

This is an example of a simple setup, with a very simple ontology.

The content of RELS-EXT from object "demo:Object_A1"

Code Block

<rdf:RDF>
    <rdf:Description rdf:about="info:fedora/demo:Object_A1">
        <fedora-model:hasModel rdf:resource="info:fedora/demo:CM_A"/>
        <demo-relations:hasB rdf:resource="info:fedora/demo:Object_B1"/>
    </rdf:Description>
</rdf:RDF>

Since the object assert the relation "<fedora-model:hasModel rdf:resource="info:fedora/demo:CM_A"/>", it has the implicit relation <rdf:type rdf:resource="info:fedora/demo:CM_A#class"/>

The content of the ONTOLOGY datastream in content model "demo:CM_A"

Code Block

<rdf:RDF>
    <owl:Class rdf:about="info:fedora/demo:CM_A#class">
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty
                        rdf:resource="http://www.statsbiblioteket.dk/demo-relations/#hasB"/>
                <owl:cardinality
                        rdf:datatype=
                                "http://www.w3.org/2001/XMLSchema#integer">
                    1
                </owl:cardinality>
            </owl:Restriction>
        </rdfs:subClassOf>
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty
                        rdf:resource="http://www.statsbiblioteket.dk/demo-relations/#hasB"/>
                <owl:allValuesFrom rdf:resource="info:fedora:/demo:CM_B#class"/>
            </owl:Restriction>
        </rdfs:subClassOf>
    </owl:Class>
    <owl:ObjectProperty
            rdf:about="http://www.statsbiblioteket.dk/demo-relations/#hasB"/>
</rdf:RDF>

The content model CM_A is defined. There is one defined relation for objects subscribing to this content model, the #hasB relation. Two restrictions are placed on this relation. There must be one, and just one such relation in subscribing objectss, and it must refer to an object of class demo:CM_B# (so, the "target" objects should subscribe to the content model demo:CM_B).

In fact, Object A1 has one such relation, and it refers to the object B1, which follows below.

RELS-EXT from "demo:Object_B1"

Code Block

<rdf:RDF>
    <rdf:Description rdf:about="info:fedora/demo:Object_B1">
        <fedora-model:hasModel rdf:resource="info:fedora/demo:CM_B"/>
    </rdf:Description>
</rdf:RDF>

So, Object B1 has the content model CM_B. That make the relation from A1 valid, see above. Lets look at the ontology from content model CM_B.

ONTOLOGY from "demo:CM_B"

Code Block

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

CM_B define on relation, the #hasA relation. There is just one restriction on this relation, that it must refer to something of class demo:CM_A#. No cardinality restriction is defined, so B1 does not need to have the relation, and in fact, it does not have it.

Ontologies for datastreams

A Fedora object consists of a number of datastreams. One datastream, RELS-INT has been reserved for the rdf statements "about" the datastreams. Datastreams do not have content models themselves. Rather, datastreams are part of fedora objects, and are thus described by the objects' content models. We expand object B1 from above

Object B1's RELS-EXT datastream. This contain the relations for the object itself.

Code Block

<rdf:RDF>
    <rdf:Description rdf:about="info:fedora/demo:Object_A1">
        <fedora-model:hasModel rdf:resource="info:fedora/demo:CM_A"/>
        <demo-relations:hasB rdf:resource="info:fedora/demo:Object_B1"/>
    </rdf:Description>
</rdf:RDF>

]

Object B1's RELS-INT datastream. This contains the relations for the datastreams in the object.

Code Block

<rdf:RDF>
    <rdf:Description rdf:about="info:fedora/demo:Object_A1/DC">
        <demo-relations:dsRelation1 rdf:resource="info:fedora/demo:Object_A1/DC"/>
        <demo-relations:dsRelation2 rdf:resource="info:fedora/demo:Object_A1"/>
    </rdf:Description>
    <rdf:Description rdf:about="info:fedora/demo:Object_A1/RELS-EXT"/>
</rdf:RDF>

]

Even through the RDF statements in the object is separated into these two datastreams, the content models have just one ONTOLOGY datastream, but with multiple class declarations. The class definition for a datastream should have the following syntax "info:fedora/{cmpid}#datastreams/{dsID}/class"

Code Block

<rdf:RDF>
    <owl:Class rdf:about="info:fedora/demo:CM_A#class">
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty
                        rdf:resource="http://www.statsbiblioteket.dk/demo-relations/#hasA"/>
                <owl:allValuesFrom rdf:resource="info:fedora:/demo:CM_A#class"/>
            </owl:Restriction>
        </rdfs:subClassOf>
    </owl:Class>
    <owl:Class rdf:about="info:fedora/demo:CM_A#datastreams/DC/class">
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty
                        rdf:resource="http://www.statsbiblioteket.dk/demo-relations/#dsRelation1"/>
                <owl:allValuesFrom rdf:resource="info:fedora:/demo:CM_A#datastreams/DC/class"/>
            </owl:Restriction>
        </rdfs:subClassOf>
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty
                        rdf:resource="http://www.statsbiblioteket.dk/demo-relations/#dsRelation2"/>
                <owl:allValuesFrom rdf:resource="info:fedora:/demo:CM_A#class"/>
            </owl:Restriction>
        </rdfs:subClassOf>
    </owl:Class>
    <owl:Class rdf:about="info:fedora/demo:CM_A#datastreams/RELS-EXT/class"/>
    <owl:ObjectProperty
            rdf:about="http://www.statsbiblioteket.dk/demo-relations/#hasA"/>
    <owl:ObjectProperty
            rdf:about="http://www.statsbiblioteket.dk/demo-relations/#dsRelation1"/>
    <owl:ObjectProperty
            rdf:about="http://www.statsbiblioteket.dk/demo-relations/#dsRelation2"/>
</rdf:RDF>

Three classes are defined, one for the object, one for the DC datastream, and one for the RELS-EXT datastream. Three object relations are also defined. The class for the object contain the restrictions defined above. The class for the RELS-EXT datastream contain no restrictions, and the class for the DC datastream contain the restrictions on #dsRelation1 and #dsRelations2.