DORA Regulatory Work Part 2b : Embargo changes

Part 1 is over here. Part 2a is over here.

Embargo in DSpace

To us it seems that the embargo code in DSpace is still being thought about.  It has changed between its first introduction in 1.6.x to 3.1.  We think we understand it and are using it in ‘Simple’ mode.  In ‘Simple’ mode, during the submission, we can add an embargo to a bitstream.  This actually assigns the rights to for an Anonymous/guest to be able to read a bitstream after a start date with no end.

Conversation on the dspace-tech mailing list discusses what embargo metadata should and should not be exposed to programmers because if exposed it would also be available to BadPeople.

Once we got the embargo functions working we discovered that a guest user must click to view a bitstream before they find out that it is restricted.  The message reads:

The file you are attempting to access is a restricted file and requires credentials to view. Please login below to access the file.

We wanted to tell the user that the file is embargoed and that the embargo will be lifted on a certain date before they click on viewI thought that the outcome of that would be that the guest to the website might not come back ala ‘this website is under construction’.  I wanted to add the possibility to create a calendar ICS file on the fly so that the guest can have a reminder of the embargo being lifted.

So, how to do that?  I discovered that the DRI /metadata/handle/xxxx/ZZZZ/mets.xml?rightsMDTypes=METSRIGHTS does not include the start date of the rights restriction.  Also, the code xsl:call-template name=”display-rights” in item-view.xsl does not handle guest views in a way that would convey the embargo to them.  To fix this, for DMU, I added this code:

--- a/dspace-api/src/main/java/org/dspace/content/crosswalk/
+++ b/dspace-api/src/main/java/org/dspace/content/crosswalk/
@@ -248,7 +248,11 @@ public class METSRightsCrosswalk
            //Translate the DSpace ResourcePolicy into a <Permissions> element
            Element rightsPerm = translatePermissions(policy);
+           Element datesMD = new Element("Dates", METSRights_NS);
+           datesMD.setAttribute("START_DATE", String.valueOf(policy.getStartDate()));
+           datesMD.setAttribute("END_DATE", String.valueOf(policy.getEndDate()));
+           rightsContext.addContent(datesMD);
         }//end for each policy

thus exposing rights:Dates/@START_DATE.  I was able to then display an embargo message based on the start date and user group from the metadata above.  I only display the embargo for this situation.  For any other situation the original display-rights code is run.

Now I have the message and a start date I could work on creating a utility to generate an ICS file containing the handle of the item, the date and an alarm.  Working out how to do this was tricky.  This is how I did it…

Modify the sitemap.xmap for our theme:

--- a/dspace/modules/xmlui/src/main/webapp/themes/dmu2011/sitemap.xmap
+++ b/dspace/modules/xmlui/src/main/webapp/themes/dmu2011/sitemap.xmap
@@ -15,7 +15,6 @@
                        Define global theme variables that are used later in this
                        sitemap. Two variables are typically defined here, the theme's
@@ -29,14 +28,28 @@
-        </map:component-configurations>
+                </map:component-configurations>
+                <!-- Owen -->
+                <!-- ICS Calendar -->
+                <map:pipeline>
+                  <map:match pattern="utils/handle/*/*/calendar.ics">
+                    <map:generate src="xml/utils/ICSCalendar.xml">
+                    </map:generate>
+                    <map:transform src="lib/xsl/utils/ICSCalendar.xsl">
+                      <!-- map:parameter name="use-request-parameters" value="true"/ -->
+                      <map:parameter name="startDate" value="{request-param:startDate}"/>
+                      <map:parameter name="handle"    value="{1}/{2}"/>
+                    </map:transform>
+                    <map:serialize type="text" mime-type="text/calendar"/>
+                  </map:match>
+                </map:pipeline>
+                <!-- /Owen -->
                        <!-- Allow the browser to cache static content for an hour -->
                        <map:parameter name="expires" value="access plus 1 hours"/>
             <!-- handle static js and css -->
             <map:match pattern="themes/*/**.js">
                     <map:read type="ConcatenationReader" src="{2}.js">

This creates a pipeline that generates a text file with the correct mime-type ‘text/calendar‘ when URLS similar to:


following the VCALENDAR v2.0 specification.

The dmu2011/lib/xsl/utils/ICSCalendar.xsl code looks like this:

<xsl:stylesheet xmlns:i18n=""
        xmlns:xsl="" version="1.0"
        exclude-result-prefixes="util exdate i18n xsl confman jstring">

  <xsl:param name="startDate" select="$startDate"/>
  <xsl:param name="handle"    select="$handle"/>

  <!-- xsl:value-of select="exdate:date-time()"/ -->

  <xsl:variable name="isoDateStart" select="concat(jstring:replaceAll($startDate, '-', ''), 'T100000')"/>
  <xsl:variable name="isoDateEnd"   select="concat(jstring:replaceAll($startDate, '-', ''), 'T103000')"/>

  <xsl:template match="*">BEGIN:VCALENDAR
UID:<xsl:value-of select="$handle"/>
DTSTART;TZID=Europe/London:<xsl:value-of select="$isoDateStart"/>
DTEND;TZID=Europe/London:<xsl:value-of select="$isoDateEnd"/>
DESCRIPTION:<xsl:value-of select="$handle"/>
DTSTAMP:<xsl:value-of select="$isoDateStart"/>
SUMMARY:De Montfort University Research Archive
DESCRIPTION:Embargo has expired


There are two things to note about this.  The simple one is that it includes an alarm.  That is a design decision that may change.  The second is that I have deliberately left out what the item is.  The guest will have to visit the website to be reminded.  It is likely that this will change.  At the moment the code works.  Titles and descriptions can be long and might contain characters that might break the VCALENDAR format.

As per usual I need to tidy up the code adding the correct internationalisation.  Messages will change to when we have settled on what we thing is the correct language.

About c3iq

Opensource, Linux, Unix, Fish, Family
This entry was posted in DORA, DSpace, Library and tagged , . Bookmark the permalink.