Page History
Panel | ||||||
---|---|---|---|---|---|---|
Contents
|
...
Policy Storage Prototype
This page describes the Policy Repository that was created for
the PLEDGE Project, an add-on-style
extension to DSpace 1.5.
Introduction
What do we mean by Policy?
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
...
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.
A Policy Repository
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.
...
class from the History system
is easily subclassed to serve as a policy store as well.
Implementation Details
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.
Binding of Policies to DSpace Objects
The
Code Block |
---|
PolicyRepository |
...
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.
Installation
Prerequisites
- Latest DSpace 1.5 development source
- Install History System Prototype, which requires, in order:
- Install the Event System prototype
- Install the AIP prototype patch
- Install History System Prototype
Download and Install
- Download sources to add and <tt>unzip</tt> it in your DSpace install (source) directory.
- Download diffs to the dspace.cfg file and apply to <tt>dspace/config/dspace.cfg</tt> with the <tt>patch</tt> utility. Note that you must update the config file used by the running DSpace instance.
...
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.
Usage
These examples assume the following contents in the archive, so substitute
equivalent objects in your archive:
...
Panel |
---|
dsrun edu.mit.pledge.PolicyRepository --help |
Adding Policies to Objects
- Add Deposit Agreement policy to Item 123456789/8
<tt>dsrun edu.mit.pledge.PolicyRepository -s 123456789/8 cu0006rei.xml</tt> - Add Replication policy to Collection 123456789/7
<tt>dsrun edu.mit.pledge.PolicyRepository -s 123456789/7 tu0011rei.xml</tt> - Add Public Availability policy to Community 123456789/3
<tt>dsrun edu.mit.pledge.PolicyRepository -s 123456789/3 cu0008rei.xml</tt> - Add required-metadata policy to the Site (123456789/0)
<tt>dsrun edu.mit.pledge.PolicyRepository -s 123456789/0 pp0004rei.xml</tt>
Examining Policies
This command will "disseminate" all of the policies associated with
an object identified by Handle, in this case the Site:
...
Panel |
---|
dsrun edu.mit.pledge.PolicyRepository -f n3 -d 123456789/0 |
Make an AIP that includes Policies
Be sure your DSpace Configuration includes a line like this:
...
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.
Future Work
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.
Next Steps
- Deploy and use this prototype to test it.
- Consider whether there is a need to modify a policy's statements as they are added to the repository, e.g. inserting the identifiers of specific objects and concrete values to replace variables or placeholders in the RDF.
- Editing or removing policies is not implemented. The History System's RDF repository is only concerned with adding statements, and has no mechanism to group the statements belonging to a policy (i.e. a subset of the statements bound to an object) so they can be removed or replaced as a group. (Perhaps use RDF reification to implement grouping.)
...