...
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: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>
|
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 |
|---|
<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"/>
|
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#Class (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:Description rdf:about="info:Fedora/demo:Object_B1">
<fedora-model:hasModel rdf:resource="info:fedora/demo:CM_B"/>
</rdf:Description>
|
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 |
|---|
<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"/>
|
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#Class. No cardinality restriction is defined, so B1 does not need to have the relation, and in fact, it does not have it.