oreprovider is distributed as a Java web application (a war-file). Once downloaded this should be placed in your Tomcat's webapp/ directory (or any other servlet container you may be using) and renamed oreprovider.war (stripping away the information of the version). This will then be extracted to a directory called 'oreprovider/' (you might have to restart Tomcat to achieve this). The application can now be reached at
At the moment oreprovider only returns Resource Maps serialized as Atom feeds.
There are some settings that can be customized for oreprovider. The settings file can be found in
The settings that can be applied there are:
[Note: if you want to add a type for a disseminator you have to remember to escape any ':' characters in the key correctly. ]
To let oreprovider be able to create Resource Maps for digital objects in Fedora two different modes can be used.
The pros of the first mode is that it is very flexible and precise and you have exact control over what will be included in the Resource Maps. You can also include disseminators and are not restricted to only datastreams. Here you are able to have many different Content Models in the repository and treat all of them different. Another big advantage is that you can create Resource Maps for Aggregations that span several Fedora objects (which for example would be the case for a book with a Fedora object for each image of a page).
On the other hand the second mode is really simple to use and no alterations has to be done to an existing repository. So if there is an one-to-one mapping between all Fedora objects and the Resource Maps you want to create, this is the ideal mode. All you have to do to expose your objects as Resource Maps are to download oreprovider.war to the correct location, then modify the properties to point at your Fedora server and set rem.autocreation to true. And that's it.
This is really simple. Just set
rem.autocreation = true
in the ore.properties file. This will then add all datastreams for a Fedora object with <pid> to the Resource Map, when a call is made to http://localhost:8080/oreprovider/rem/<pid>/ .
[Note: when this mode is enabled all annotations set in the RELS-EXT will be ignored. ]
If you want to have some control over which datastreams should be included you can additionally set rem.autocreation.filter to a whitespace separated list of datastreams that should be included. Any datastreams not in the list will be ignored. If this property is not set, all datastreams will be added (as is the default).
To let oreprovider know that an object in Fedora should be part of a Resource Map you have to say so in the RELS-EXT for the object. This is done by adding the following
should be the identifier that you want to let the Resource Map be known as. (This could very well be the pid of the object in Fedora.)
An example could be:
Besides doing the above you also have to tell oreprovider which datastreams or disseminators that should make up the Aggregated Resources of the Resource Map. This is done by adding the following
to the RELS-EXT, where <DATASTREAM>
should be the datastream or disseminator in the object that should be added as an Aggregated Resource. (It is this name that type.RESOURCE in the configuration file looks for when adding a type to the Aggregated Resource.)
Of course multiple datastreams or disseminators can be added. An example could look like:
<ore:resource xmlns:ore="http://www.kb.se/dl/xml/ore#">DC></ore:resource> <ore:resource xmlns:ore="http://www.kb.se/dl/xml/ore#">MODS</ore:resource> <ore:resource xmlns:ore="http://www.kb.se/dl/xml/ore#">bdef:images/getWebImage</ore:resource>
Sometimes you might have a digital object that is built from multiple Fedora objects. This could be the case if you have scanned a book and have one image per page. Then the digital object would consist of the Fedora object for the book as a whole (where you might keep bibliographic metadata), plus all the Fedora objects for the individual pages.
To create a Resource Map for such a digital object you would have to modify the RELS-EXT for the book as a whole, as well as the RELS-EXT for each individual page. The only difference from simple case is that all the RELS-EXTs should have an <ore:resourceMap> with the same identifier. (This could preferably be the pid of the Fedora object for the book as a whole.) Then each RELS-EXT would also list the datastsreams and disseminators that should be included from that specific Fedora object.
Listed below is an example of the RELS-EXT for a Fedora object consisting of three datastreams, DC, MODS and PDF. It also has a disseminator that will give you the text of the PDF as plain text, called bdef:text/getText .
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ore="http://www.kb.se/dl/xml/ore#"> <rdf:Description rdf:about="info:fedora/kb:1628"> <ore:resourceMap>ore:kb:1628</ore:resourceMap> <ore:resource>DC></ore:resource> <ore:resource>MODS</ore:resource> <ore:resource>PDF</ore:resource> <ore:resource>bdef:text/getText</ore:resource> </rdf:Description> </rdf:RDF>
This Resource Map could now be retrieved from http://localhost:8080/oreprovider/rem/ore:kb:1628/ and would have Aggregate Resources for all of the above.
If you want the Aggregated Resources for the DC and MODS to say that there types are descriptive metadata you should add the following to the configuration file:
type.DC = info:eu-repo/semantics/descriptiveMetadata type.MODS = info:eu-repo/semantics/descriptiveMetadata