VuFind UConnect SSO
VuFind is the library catalogue system and UConnect is USQ’s custom SSO system that was developed. I’ve gone through and built an integration between the two which looks like the following:

I talk a bit more about VuFind, SSO and authentication in an earlier blog post.

Book Finder
This is primarily the work of Ken MacAlpine who is working on mobile technologies at USQ. Ken developed an SVG powered map of the top floor of the library to aide in the location of books. He put together a database of roughly where the catalogue numbers stop and start for each shelf on each side. It has been integrated into the catalogue and shows up as a “Show on Map” link for Toowoomba Main Collection items.

At some point in the future we will work to expand it to all campuses and collections. When it is clicked it appears in a new window like this:

It is aimed to be the same size as an iPhone display so that it fits neatly there. It also works in all browsers that support SVG. Fallback support is provided for IE since it doesn’t support SVG yet.

ePrints, RPCS and data conversion!
As an interesting exercise I also spent some time converting data from an internal reporting system, RPCS, into our open access repository – ePrints. This was a fun project which required connecting to RPCS’ MSSQL database and outputting an XML file for ePrints to eat. To do this I figured I’d pull out Web Matrix, Microsoft’s cut down editor for web developers. It feels on par with Geany though it has a built in web server, request tracking and a database explorer. It also integrates with the Web Platform Installer product which means I can easily install other applications. I used Web Matrix to kick start the Joomla! install for the Access All Databases research project as well.

The RPCS data is loaded into our ePrints system along side the Author ID project that existed there. We’re also pulling across the data from their system which is going to result in duplicate authors until we merge them down to uniques however doing so in an automated manner isn’t easily possible. There is a whole heap of work to get things together but all in all we’re doing well.

EQUELLA Moodle module
Last but not least I’ve been playing with the EQUELLA Moodle module. It adds an extra option to the Moodle resource drop down and enables access to select items from the EQUELLA repository software.

I’ve used Web Matrix here to deploy out a quick Moodle site utilising the same Web Platform Installer technology and managed to get up and running quickly with everything. The deployment of the module to our main Moodle environment would enable lecturers to directly select course readings to embed in relevant modules on their Moodle course pages – exciting!

Once you’ve got ePrints set up with a new repository, check out the /archives/repositoryname/cfg/cfg.d directory and look for a “datasets.pl” file. This is the first step in the process and documents two samples: one using a set of fields and a second with a class that you can derive from. In practice neither example works properly which is a bit disappointing. Fortunately the second solution with the class works with one minor modification: you need to implement the “get_dataset_id” function for it to work properly. This is relatively trivial to complete and you’re off on your way. A copy of the datasets.pl is included in a ZIP package linked at the end of this blog post.

Once we’ve got our datasets we’re going to need to update the repository structure to add them to the database. ePrints makes this relatively trivial with the following command:

That will automatically connect to the relevant database, create tables and add fields where necessary. Very funky.

The next stop on the list is to create a workflow for it. If you’re not familiar with how ePrints workflows behave then check out the ePrints wiki on the Workflow Format for more details. The basics are that it describes how fields should work on a screen and some limited scripting capability. To begin with we need to head to our /archives/repositoryname/cfg/workflows directory and create a new one. My dataset was called “service” so I created a new “service” directory. Because I’m lazy, I copied the user/default.xml file into service/default.xml and edited it to meet my needs. Mostly deleted the items and added the fields that I cared about. Again, if in doubt check out the documentation on workflows.

Now ePrints also has citation support and you guessed it we need to provide a citation. The Citation Format is documented in the wiki as well though a bit simpler than the citation format. To create this we jump to /archives/repositoryname/cfg/citations, create a new directory for the dataset (“service” again) and then because I’m lazy copy the user/default.xml file to service/default.xml and customise to what you need. The format is again pretty simple so follow your nose from what is on offer and again if in doubt check out the wiki.

At this point if you restart your ePrints instance to ensure the configuration is fully reloaded you need to grant your users some roles before you can see the dataset. If you jump into your favourite user and administer their account you will need to add some roles. There are a few different actions that appear to make sense:

• view – required to see the dataset
• create – add a new item to the dataset
• edit – edit existing items in the dataset
• destroy – remove an item from the dataset
• details – display a details screen for an item in the dataset

Each of these can be turned into a role by adding “+datasetname/action” into the roles box in the administrate user screen. In my particular case I did “+service/view”, “+service/create”, etc for those roles. Once you give yourself all of these roles you will be able to see under the “Manage Records” option (to the right of “Manage deposits”).

At this point you’re looking at it and it looks ugly because the strings aren’t translated properly. ePrints makes this easy, just click on the “Edit page phrases” button. It’ll list the phrases displayed on the screen and give you the option to add new phrases for the ones you’re missing whilst highlighting it. Fill in the blanks as you go and once you’ve added phrases for everything you’re ready to deploy out your data set!

So whilst we’re done and we can edit it, we probably want to grant it to our users to have a look at these as well. Adding these roles individually to our users isn’t fun, however if we edit the /archives/repositoryname/cfg/cfg.d/user_roles.pl file and add the roles to the existing user role we gain what we need. In addition to the existing roles we added previously (e.g. service/view), a generic user account will need the “datasets” role to be able to see the datasets tab. This makes the user_roles.pl section for user relatively simple:

Pretty easy. At this point our users can now add, edit and view records in the service dataset. Mission accomplished? The next step is to clean up everything, add a brief citation file in addition to the default citation and for me work out how to have per user items so that users can only edit their own items. But I think that is enough for today. Hopefully I’ll be able to work out how to limit items to just their own users but I might need to build my own screens. I’ve done this before with USQ’s Author ID project so I know how to do it, I’d just rather not.

Here at USQ we have cases where we have departmental staff in faculties or research centres that deposit papers on the behalf of academics. These might be secretararies or research assistants who handle the initial entry of data into the system, attaching the paper and the other tasks that are required. At the end of this process the library wanted to change the depositor from this user and reassign it to the primary author of the paper. So they needed a way to reassign the depositor. They didn’t want this to occur immediately and wanted to have some control over the reassignment. Initially I built it with a user picker for the depositor to select the new user however the Library requested a generic text field instead that the depositor could use to type the details of the person to which they wished the depositor reassigned.

So the first step in all of this drama is to add a few fields. We ended up with three fields: the first was a field for the depositors to enter the name of the user who the item should be reassigned to, the second was an ItemRef field which linked to the user table to have a representation of the user and the last was a checkbox which controlled if the user of the item is reassigned. The first field is visible to any one in the repository who has an account whilst the last two are visible only to repository staff (e.g. editors or administrators).
So to do this, we need to navigate to /opt/eprints3/archives/[archivename]/cfg/cfg.d/eprints_fields.pl and add the following:

Once we’ve done this, you need to run “/opt/eprints3/bin/epadmin update_database_structure [archivename]” to add the new fields to the database.

The next task we need to do is add this to the eprint workflow so that the fields turn up on the screen. This can be achieve by going to “/opt/eprints3/archives/[archivename]/cfg/workflows/eprint/default.xml” and adding it into one of the stages. I picked the “Notes” stage or tab to put it in, eventually it looked like this:

If you don’t have a “notes” stage already, you will need to add a new one to the flow at the top, if you’re using a standard ePrints configuration, it will look similar to this:

Pretty easy! The next step is to add some translations in “/opt/eprints3/archives/[archivename]/cfg/lang/en/phrases/eprint_fields.xml”. Add these lines before the final </epp:phrases> line:

So there is are two phrases for each field, the name and the help text that goes with it. Most of it is pretty self explanatory. The final step in this trip is to alter “/opt/eprints3/archives/usqep3/cfg/cfg.d/eprint_fields_automatic.pl” to set it so that it will change the depositor of the item once the tick box is checked.

# Depositor Reassignment
if( $eprint->get_value( “new_depositor_update” ) eq “TRUE” && $eprint->get_value( “new_depositor_assignment” ) != 0 )
{
$eprint->set_value( “userid”, $eprint->get_value( “new_depositor_assignment” ) );
$eprint->set_value( “new_depositor_assignment”, “” );
$eprint->set_value( “new_depositor_name”, “” );
$eprint->set_value( “new_depositor_update”, “FALSE” );
}
# End Depositor Reassignment
my $type = $eprint->get_value( “type” );
if( $type eq “monograph” || $type eq “thesis” )
{
These nine lines surrounded by Depositor Reassignment is inserted where it is and at this point we’re done. We’ll need to restart the server before we get too far just to ensure that everything takes properly and then we can test it all out.

The workflow at this point is that a user of the system marks down the person they wish to reassign as the depositor. We have an overnight report which runs to email one of our repository editors to notify them of items that are being requested to be transferred. They then view these items and enter the user ID of the user in question into the new depositor field (they can use lookup to validate it) and at this point they need to check the box to actually update the assignment. In ticking the box the the depositor is set to the value of the new depositor field, the reassignment field is blanked, the new depositor field is blanked and the check is cleared.

The most unfriendly aspect of this is finding the user in question. To do so you need to traverse the user search, find the user and then grab their user ID and put it in the field. This is a bit much. We also wanted to have the option to send an ameila but the editors need to be able to customise the email before it is sent and wanted control.

Fortunately the solution to the first problem was to utilise the Itemref custom InputForm Component that I created for the Author ID project. The second was to create a new one that primitively created a “mailto” link with a lot of the details pre-populated. For the latter I might have been able to do it within the workflow language but I felt it was easier to build in Perl.
Before we begin, we’re going to need a few files:

• The “Itemref.pm” file needs to be put in the “/opt/eprints3/perl_lib/EPrints/Plugin/InputForm/Component” directory.
• The “USQ_DepositorEmail.pm” file needs to be put in the “/opt/eprints3/perl_lib/EPrints/Plugin/InputForm” directory.
• The “user” file needs to be put in the “/opt/eprints3/cgi/users/popup/user” directory. The “popup” directory might not exist in your installation and will probably have to be added first.

Once you’ve got these files in place we’re ready to do some more modifications. In the “/opt/eprints3/archives/[archivename]/cfg/workflows/eprint/default.xml” file where we had the following:

We’re going to change that to the following:

This then tells the system to add a new “Find Entry” button which will popup with the user search window. The user search is limited to repository users so anyone who isn’t authorised will receive a login request form. It also tells ePrints to use the new Itemref InputForm Component to handle this field as well, which is what puts the Find Entry button and handles the other logic.
To add the email option, we add a single line after the above mentioned on to load it up:

Pretty simple changes here so far – this then puts some text with a link up if we need it. The last change we need to make is to include this into our language files. There are a few strings, we’ll just put them into the “/opt/eprints3/archives/[archivename]/cfg/lang/en/phrases/eprint_fields.xml” file we used previously:

All pretty simple, again these lines should be inserted before the </epp:phrases> line in the file. Once you’ve done this, restart the server again to pick up all of the changes and you should see a user picker interface and a little bit of text you can click to make a quick email message. You can customise the email message by altering the language strings to change what you want to display.

Currently ePrints lists authors by using the creator field of an ePrint. This is usually entered as the cited name of the author. If you have a small number of authors with different names this works reasonably well as the system can differentiate between people without much issues. The problem comes in when people are cited differently or have very similar names but are distinct people. Then it becomes bad.

One way of solving the problem is really quite ugly: you go through and change the cited author to make it look “neater”. In fact one of our library staff decided that they would do that greatly damaging the value of the data stored with in the system, tainting it horribly and creating more work for themselves. The cynic in me wonders that they’re just creating more work for themselves later to go back through and fix it all up. So there is a solution, non technical and pretty ordinary.

So our solution was to turn authors into a first class data set within ePrints. They’re not some unidentifiable free text field with no great purpose (there was a creator ID field but email address was suggested to be used for it) but in fact they are now their own entity which is cool.

We’ve done some different stuff with the author ID project at USQ that I’d like to share:

So an author has a name, they can be linked back to a user ID, they have an email address (both primary email address which should be used for contact and alternate addresses for aiding search), a biography and external identifiers. A cool feature of the primary email address is that when it is updated it automatically gets copied to the alternate email address list,  so you can easily update an email address and still retain the old one (you can still remove them from the alternate email address easily). The external identifiers section provides the ability to list useful identifiers for the author that mean something outside of ePrints. This could be stuff like a staff or student number that you record against the author to help with recognising your users. This is also a new field type developed called ‘Name-Value’ to represent name value pairs of data and provide an editing interface.

But the problem with authors is that they don’t stay the same: they’re dynamic. So they might move around an organisation, shift faculties, join a research centre or even leave the organisation. Recording this in the author record is more than possible but it starts to get messy – we start talking about ‘versions’ of the author but versions imply the wrong concept. A researcher might be working on papers in two different faculties, each paying for his time and each deserving of recognition. In our case we also need to use that information for reporting so that we can properly allocate funds based on research outcomes as well – for us it is important to know who paid for the research.

So to solve this problem I created a system called “author instances”. Author instances provide a subrecord of the authors that permits instances of specific data to be created and associated with the author. Then when an author creates a paper a link is created to this instance and not directly to the author. This allows the author record to contain information that is relatively static and data that might periodically change (such as department or even which institution someone is at) is then located in the author instance. As this isn’t ‘versioning’ per se it also works well for when a researcher is concurrently producing papers for different parts of the institution (or even for bodies external to the institution).

This screen depicts the edit view for an author instance.

The author instance is very light by default, it only contains the author that it is linked to, its display name and a preferred flag. The preferred flag is mutually exclusive within author instances – if one instance for an author sets the flag then it is cleared for all other authors. In the screen shot you will notice an untranslated field called “deptid”. This is another new metafield that has been developed called “Externalitemref” which is similar to the built in ItemRef field however it works on tables managed outside of ePrints. ExternalItemRef takes the params of a table name, a key field and a name field to operate in a similar manner to the ItemRef and link data back in.

The observant will notice that both the ExternalItemRef and the built-in ItemRef field also have a find entry button. This button has also been added to the ePrint item editing screen as well and triggers a popup window which allows easy searching for the particular item (user, author, author instance) that you are interested in.

The standard ePrints creator fields have a "Find Entry" button as well.

So as we can see there is now a “Find Entry” button that pops up with a new window allowing us to select an author instance for this author easily and not have to worry that we’re going to mistype their email address or similar.

This is just a quick introduction into some of the changes that the Author ID system which USQ has developed provides. Ideally we’d love to feed this back to the ePrints core so that everyone can use this, or a similar system, in a great way. If you want to read more you can check out the “Author ID Notes” document on my knowledge base download site.