Hi
Steve Bayliss have just finished adding the RELS-INT datastream to
Fedora, as announced on this list. I have been in some discussion with
him, as also shown on this list. This discussion have granted me a
chance to fully understand the conceptual change that RELS-INT brings.
In the semantic web paradigm, everything with an URI is a thing, which
can have properties and so on. But in Fedora, so far only Objects could
have properties (relations)
This all changed with the introduction of RELS-INT. Steve Bayliss have
made a system for, in a fedora object, specifying object properties with
a datastream id as subject. No more, no less.
So datastreams are now objects, so to speak. They have a URI, and they
can have properties themselves. Formerly, there was the Fedora Object,
which had datastreams (blobs of data) and properties. Now there is the
Datastream, which has ONE blob of data, and properties. Fedora objects
now has a list of Datastreams, and properties for the object itself.
So we have two levels of objects. This is the way the Fedora paradigm is
broken.
Big deal? Yes. Because if the datastreams can have relations, they can
have the hasModel/rdf:type relation. So, suddently we have a framework
for talking about the classes of datastreams. Now, like the content
models, there is the possibility to specify restrictions and demands on
the datastream, both it's relations and it's content.
Some might remember the old problem with the DS-COMPOSITE-MODEL
datastream. There is no way to specify datastreams that might be there,
only datastreams that have to be there, and there is no way to specify
cardinality for datastreams.
With the use of RELS-INT and enhanced content models, we can now specify
something close to a solution to this problem.
Enhanced Content Models give the ability to define an ontology for
subscribing objects. This could include relations from the object to the
objects datastreams. On such relations, Enhanced COntent Models give the
ability to make cardinality demands, and specify the class/content model
of range.
So, in the RELS-EXT for an object you could make this blob
<rdf:Description rdf:about="info:fedora/demo:object1">
<fedora-system:hasModel rdf:resource="info:fedora/demo:cm1"/>
<demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC1"/>
<demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC2"/>
<demo:hasDCdatastream rdf:resource="info:fedora/demo:object1/DC3"/>
</rdf:Description>
Then in the ontology we would specify something like
<owl:Class rdf:about="info:fedora/doms:ContentModel_DOMS">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasDCdatastream"/>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#integer";>3</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasDCdatastream"/>
<owl:allValuesFrom
rdf:resource="info:fedora/demo:DCdatastreamcontentModel"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
This basically says that demo:object1 must have at least three
hasDCdatastream relations to things of the type
demo:DCdatastreamcontentModel
This in the RELS-INT in demo:object1
<rdf:Description rdf:about="info:fedora/demo:object1/DC1">
<fedora-system:hasModel
rdf:resource="info:fedora/demo:DCdatastramcontentModel"/>
</rdf:Description>
<rdf:Description rdf:about="info:fedora/demo:object1/DC2">
<fedora-system:hasModel
rdf:resource="info:fedora/demo:DCdatastramcontentModel"/>
</rdf:Description>
<rdf:Description rdf:about="info:fedora/demo:object1/DC3">
<fedora-system:hasModel
rdf:resource="info:fedora/demo:DCdatastramcontentModel"/>
</rdf:Description>
And voila, you have specified that objects of demo:cm1 must have at
least three datastreams, which all have a specific content model.
I have not fully thought everything above through, but I hope you get
the gist of it. I would like to hear other peoples thoughts on this.
Think of this as a preliminary on how RELS-INT can be used in enhanced
content models
Regards
Asger
Enhanced content models to be found on ecm.sourceforge.net
------------------------------------------------------------------------------
_______________________________________________
Fedora-commons-developers mailing list
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
