Contents |
This page describes the Policy Repository that was created for
the PLEDGE Project, an add-on-style
extension to DSpace 1.5.
In this context, Policy refers to the general definition of the
word rather than the specific meaning it has acquired in the authorization
area of the DSpace data model (e.g. around the ResourcePolicy
and PolicySet classes).
On this page, a policy is typically either a rule describing (or prescribing) the
interactions of actions that take place within the archive, or a constraint
determining when and by whom an action may be taken.
For example, a policy could demand that every Item being submitted include
an approved deposit license. Another policy might demand that every
Bitstream in the asset store be checked for content integrity
(i.e. checksum recomputed and compared with the checksum on record) at
least once in every six moths.
Since one of the goals of the PLEDGE project was to develop a
machine-readable encoding of policies, we needed a place to put them.
Policies may be associated with all types of data model objects: Items,
Collections, Communities, etc. It would have required database changes
to manage this within the existing object model.
However, the data we have to store is in RDF, and
History System Prototype includes an
RDF triple-store that can associate RDF statements with instances of DSpace
objects, all outside of the DSpace data model.
The
RDFRepository |
class from the History system
is easily subclassed to serve as a policy store as well.
Policies are written in the Rei language,
which is based on RDF and OWL. A policy is thus a collection of
RDF statements. See the Rei examples in these
samples of policy expressions.
The
PolicyRepository |
class lets you store RDF statements
keyed to a DSpace object, so they can be retrieved later in the context
of the object. An object thus accumulates policies bound to it.
The policy information model assumes that the policies of an object
also apply (when relevant) to objects below it in the "ownership" hierarchy.
For example, a policy dictating replication terms at the Community level
would also apply to each Collection and Subcommunity under that Community,
and to the Items, etc, belonging to them.
In practice, this "inheritance" behavior would be implemented by a policy
enforcement engine, but that has not even been designed yet. It is sufficient
for the policy repository to retrieve the policies related to one DSpace
object; a policy engine or other application can use the data model API
to find other related objects (e.g. ancestors) and retrieve their policies.
As an example, the class
PolicyStackStreamDisseminationCrosswalk |
exports all of the policies belonging to an object and to its "stack"
of owner/ancestors – its owner, its owner's owner, etc. on up to the Site.
This was done so that all possibly-relevant policies can be put into
a Dissemination Information Package (DIP) which is sent to a policy-aware
storage repository such as the SDSC's iRODS.
1. To install, rebuild and install <tt>dspace.jar</tt> with the command: (There is no need to rebuild the WARs since the UIs never call the policy repository.)
ant install_code |
2. Also, be sure the configuration changes are installed in the DSpace
configuration file: <tt>dspace/config/dspace.cfg</tt> .
3. Finally, create the directory mentioned in the configuration
as the value of <tt>policy.dir</tt>, e.g. <tt>dspace/policy</tt> .
Be sure it is writable by the user who runs DSpace.
These examples assume the following contents in the archive, so substitute
equivalent objects in your archive:
Run the <tt>PolicyRepository</tt> command-line application with <tt>--help</tt>
to learn about all of its options. It is the same as the
<tt>HistoryRepository</tt> application in the History System Prototype.
dsrun edu.mit.pledge.PolicyRepository --help |
This command will "disseminate" all of the policies associated with
an object identified by Handle, in this case the Site:
dsrun edu.mit.pledge.PolicyRepository -d 123456789/0 |
Add the <tt>-f</tt> option to change the output format to e.g. N3:
dsrun edu.mit.pledge.PolicyRepository -f n3 -d 123456789/0 |
Be sure your DSpace Configuration includes a line like this:
aip.disseminate.techMD = PREMIS, AllPolicies:POLICY_STACK, ObjectPolicies:POLICY |
The following command creates an AIP of the Item 123456789/8
org.dspace.app.packager.Packager -d -t AIP -i 123456789/8 -e ADMIN-USER policy-aip.zip |
You can download the sample AIP here Policy-aip.zip
Note that the <tt>mets.xml</tt> manifest includes the element:
<techMD ID="techMD_7"> |
This identifies <tt>metadata_69</tt> as the whole "stack" of policies that
applies to the Item. Another file in the AIP, <tt>metadata_67</tt>,
contains just the policies that are actually bound to the Item itself.
This is only an experimental prototype. The
<tt>PolicyRepository</tt> implementation is crude, but it is
adequate to get policy metadata in the archive and into AIPs for
experimenting with other, policy-aware, repositories.
</html>