DSpace OAI profiles

By default in DSpace, OAI-PMH will share all of your public accessible Items in DSpace through OAI. In case you wanted to restrict or modify the set of results that get shared, you would have to customize the ouput, luckily recent versions of DSpace have an easily modifiable configuration, that essentially gives you "profiles" in OAI.

The default profile is called "request", it doesn't filter the results, and it allows harvesting in many different metadata formats. Note: only publicly accessible items/objects can be disseminatable through OAI.

The other profiles in DSpace are OpenAIRE (Open Access Infrastructure for Research in Europe) and DRIVER (Digital Repository Infrastructure Vision for European Research). By default your repository won't disseminate any objects in OpenAIRE or DRIVER format because the filters in place require some specific metadata to be collected for those profiles/guidelines.

https://github.com/DSpace/DSpace/blob/dspace-4_x/dspace/config/crosswalks/oai/xoai.xml#L33

The DRIVER profile declares a number of filters, which restrict the items that disseminate under that profile, to match the requirements of DRIVER. In this case the filters will require: that there is a title (dc.title), that there is an author (dc.contributor.author), that the document type (dc.type) is one of article, thesis, book, etc,  also that dc.rights is equal to "open access", and lastly that there is a publicly accessible bitstream, hopefully that means that the full text is available.



So, in case you wanted to customize your default "request" profile to restrict the output to all items in the repository that also had full-text available, you would customize:

 <context baseurl="request">  
 To add:  
 <filter refid="bitstreamaccessFilter"/>  

In addition to this information about DSpace OAI profiles, I did run into some bugs or potential issues in the DSpace XOAI code base. For one, there are two modes to run DSpace XOAI in. There is either database mode, where the database responds to all OAI queries, or a performance optimized version, where SOLR indexes your repository. One of the bugs was that the solr mode had a slightly different interpretation of "bitstreamaccessFilter", i.e. database required that there was an original bundle bitstream, the solr version only required that the item was public. To correct this I've patched our code at Longsight, and have contacted the XOAI author to confirm and test the issue.

Improving DSpace Presentation: Video Player and Document Viewer / BookReader

One of the fun goals for DSpace that we have at Longsight, is to make using DSpace a great experience. We've got some more ground to cover, but today we have a BookReader and a Video Player to demonstrate.


The BookReader for DSpace uses the Internet Archive BookReader player to present scanned pages of a book in a format that looks like a book. Put the image of the left page on the left side, and the right page on the right side, and when you turn the page, they change both pages. Simple idea, and when executed properly, it makes the content look much nicer.

An example of this BookReader can be found at: https://trydspace.longsight.com/handle/123456789/77#page/1/mode/2up



The Video Player for DSpace uses flash, and plays the video right in your browser. It is not a true streaming solution, but rather, makes use of progressive download, so you can play what has been downloaded, but you won't be able to skip ahead in the video beyond what has been downloaded.

You can view an example of the video player at: https://trydspace.longsight.com/handle/123456789/68



Longsight provides Hosting, Support, and custom development solutions for DSpace, the Digital Repository / Digital Asset Management system for libraries and institutions.

DSpace Development at Longsight

I've been a DSpace Developer at Ohio State University for about 5 years, and recently I have changed jobs to work at Longsight, a Registered Service Provider for DSpace. They also have a few other stacks that they support, such as Sakai LMS, and LAMP, such as Drupal and Wordpress. Basically it revolves around solving problems for higher ed, using open source software. They provide hosting, training, consultation, and custom development. So far I've been on a few consultation-setup-hosting-training-development adventures in my time with Longsight, and its fun.

Peter Dietz

+

DSpace

=

Longsight

One thing I really enjoy at Longsight is that there are always problems to solve, and it becomes my job to come up with a creative way to solve the problem. Also, I feel like I score bonus points when the solution that works for a client, can also be contributed upstream into the next release DSpace, to be benefit everyone. Additionally, I get to meet with clients, sometimes over the phone, other times in person, and there is also meeting people at conferences. This year, I'll be in Helsinki Finland for Open Repositories 2014, come say hi. I'll be presenting on the REST API for DSpace. I'm also taking a bit of a traveling/working/holiday across parts of Scandinavia, you can be "at work", anywhere with internet.


Anyways, I have a number of development projects that I've been working on.

• better Request-Restricted-Item workflow, adding a helpdesk workflow, with buttons to contact the requester, and author of the work.
• Mime-Type-Icons for content without thumbnails
• Document Viewer 
• Displaying Thumbnails of Restricted Content, instead of showing a broken-image 
  
• Statistics converter between SOLR to ElasticSearch
• Customizing, and extending Mirage2 XMLUI theme, and making custom-branded derivative themes, to match each clients design palette.

Not to sound like a sales pitch, but, if you need DSpace Hosting, or DSpace custom development, keep Longsight in mind, we do good work, have fair prices, and we love contributing our work back upstream to improve the DSpace community. Plus, it will give me some fun work to do.

Using Restlet to build a Java API

I'm working on building a Restful Web Services API for a Java Application that I'm active on. My initial direction for getting started was to look into JAX-RS (Java's API for building restful web services), and then noticing that JAX-RS 1.0 has been out for quite some time, and then noticing that JAX-RS 2.0 was getting approved right before my eyes. Assuming that JAX-RS2 is the successor to JAX-RS1, one might as well stay on the latest edge. JAX-RS 2.0 is now approved by the Java Community Process, so, assuming there are implementations worth using, you can get going now!

Well, I'm stumbling through this "decision matrix" of which implementation to choose, and Stack Overflow only gets you so far. So, for now, I'm doing a technology "Spike", and am working through researching RESTlet to be my horse to build an API upon.

Tangent

I've recently picked up some Rails development, and I'll note that documentation and getting started started guides are rampant throughout that ecosystem. So, Rails is a nice platform that provides as little friction as possible to someone getting started.

Getting Started with Restlet

I found some Maven settings to add to a new project pom.xml, which allowed me to get started quickly. (Note: I had used this originally, while the Restlet version was pegged at 2.0.0)

Add to your pom.xml to add Restlet 2.1.2 to your maven project.

I then started reading the book "Restlet in Action", and hit a stumbling block with the following code:

public class AccountServerResource extends ServerResource implements AccountResource {
    private int accountId;

    @Override
    protected void doInit() {
        this.accountId = Integer.parseInt(getRequestAttributes().getAttribute("accountId"));
    }

This .getAttribute("accountId") does not exist in Restlet 2.0.0, so I did a bit of panic, and tried to re-write the code to something analogous I guess, like: 

@Override
    protected void doInit() {
        this.accountId = Integer.parseInt(getRequestAttributes().get("accountId").toString());
    }


Not as pretty, but if it works.. But then I'm stuck with not being able to follow along with the book. And I'm assuming that the book was reviewed. So, I take a different approach, maybe I'm using the wrong version of Restlet? I jumped to the Restlet maven repo, and found that the latest stable version, and the version that matches the book is 2.1. So, I changed my pom to use version 2.1.2, previously I was using Restlet 2.0.0.


Thus far, Restlet is so-far-so-good. But, its a lot of learning, when I really just want to get to "done" faster. I'm not sure what getting-started route I would recommend for another developer that I would on-board to this project. i.e. I layed this groundwork, build on top of that, and read some getting started guides, as opposed to starting from scratch with the book.

The application that I'm actively working on is DSpace, the institutional repository, asset management system.

I've managed to run out of memory with 16GB!

I've been upgraded to a MacBook Pro with 16GB of memory, not 4GB, not 8GB, but 16GB.

And.. Thats somehow not enough, since I've been able to (through normal work) run out of memory. I don't blame Java. (Kidding...)

[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Java heap space
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)

Maven skip license check

I recently ran mvn install on a big Java project that I work on, but it kept failing due to some files not having the proper license headers. Well, thats not my concern right now, how do I skip that?

To skip the maven license check, add:

-Dlicense.skip=true

So, my full command (which also skips running the unit tests) is:
mvn clean install -DskipTests=true -Dlicense.skip=true

I suppose you should add yourself a future task of eventually making all of your files have the proper license headers, but you can continue on what you meant to do for now.

Debugging an SLF4J error, mvn dependency:tree to the rescue

As a Java developer, I frequently add additional dependencies to maven as new features are being built.  Sometimes you don't know what will break your build, but here's my "stack trace", as I worked through solving an error from:

 peterdietz:dspace-3.0-SNAPSHOT-build peterdietz$ /dspace/bin/dspace dsrun  
 Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V  
      at org.apache.commons.logging.impl.SLF4JLocationAwareLog.info(SLF4JLocationAwareLog.java:159)  
      at org.springframework.context.support.AbstractApplicationContext.prepareRefresh(AbstractApplicationContext.java:456)  
      at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:394)  
      at org.dspace.servicemanager.spring.SpringServiceManager.startup(SpringServiceManager.java:207)  
      at org.dspace.servicemanager.DSpaceServiceManager.startup(DSpaceServiceManager.java:205)  
      at org.dspace.servicemanager.DSpaceKernelImpl.start(DSpaceKernelImpl.java:150)  
      at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:51)  

Basically the error above means that you've got two different (incompatible versions of slf4j present 1.6 and 1.5). If your build output has a lib/ directory, check that for jars that have slf4j in their name. If you've got two different versions, thats your problem. Your quick fix would be to delete one of the versions (most likely 1.6).

However, to actually fix your problem, you've got to stop Maven from including two different versions of SLF4J. You can "Find in Path" from your IDE to see if you are manually including two different versions of SLF4J, but thats likely not the case, you'll need to look at Maven's dependency tree to see what has snuck both versions into your build.

mvn dependency:tree

Maven Dependency Tree will process all of your imports, all dependency entries in your pom.xml files, and recursively give you a tree output that will show which parent project includes which sub-project, which includes some feature, which includes which JAR. In my case, I was hunting down jcl-over-slf4j-1.6.1.jar. And looking through the output of mvn dependency:tree, I found it.

[INFO] +- org.dspace:dspace-stats:jar:3.0-SNAPSHOT:compile

[INFO] |  +- org.apache.solr:solr-solrj:jar:3.5.0:compile

[INFO] |  |  +- org.codehaus.woodstox:wstx-asl:jar:3.2.7:runtime

[INFO] |  |  \- org.slf4j:jcl-over-slf4j:jar:1.6.1:compile

To solve it, I found my pom.xml for the dspace-stats project. And specifically, the import for solr-solrj

 <dependency>  
   <groupId>org.apache.solr</groupId>  
   <artifactId>solr-solrj</artifactId>  
   <version>${lucene.version}</version>  
 </dependency>  

This will include solr-solrj, and all of its neccessary dependencies, and according to the dependency:tree, this is where slf4j has snuck through. So, we need to exclude slf4j from coming through, luckily maven lets us do exactly that. So, add the <exclusions> block below to this <dependency>, and you should be able to rebuild, and be all set. 

 <dependency>  
   <groupId>org.apache.solr</groupId>  
   <artifactId>solr-solrj</artifactId>  
   <version>${lucene.version}</version>  
   <exclusions>  
     <exclusion>  
       <groupId>org.slf4j</groupId>  
       <artifactId>slf4j-api</artifactId>  
     </exclusion>  
     <exclusion>  
       <groupId>org.slf4j</groupId>  
       <artifactId>jcl-over-slf4j</artifactId>  
     </exclusion>  
   </exclusions>  
 </dependency>  

Good Luck!