A quick look at JorumOpen

As anyone with even a passing intererest in UKOER will know, JorumOpen went live earlier this week and I, for one, was dying to see just what the good folk at Mimas and Edina have come up with with their customised DSpace installation (and possibly “borrow” one or two ideas for Leeds Met Open Search!).

JorumOpen Home is at http://open.jorum.ac.uk/xmlui/ and allows the user to browse OER by FE or HE subject; alternatively there are links to browse by Communities & collections/Issue date/Authors/Titles and Keyword.  There is also a simple search box and a link to an Advanced search form:

The results page comprises different functionality depending on the search – for example, browsing by subject heading displays “Recent Deposits” and allows the user a simple/advanced search, or browse by Titles/Authors/Dates within that subject heading (I like this hierarchical search functionality); also includes an RSS button to subscribe to updates within the collection.

Results themselves comprise a hyperlinked title, author/author affiliation and date of deposit as well as a thumbnail graphic where available:

The record page is worth looking at in detail (this item – http://open.jorum.ac.uk/xmlui/handle/123456789/567):

Show full item record (link) - Full Dublin Core metadata record

Share (AddThis button) – third part social network service allowing record to be emailed to a friend or posted to various social networking sites.

The simple record comprises:

Title/Author/Description/Keywords/Persistent Link/Date

Then there are three buttons:

“Export resource” that requires a valid email address “As some resources are quite large in size it can take some time to prepare them for download. Due to this we required you to supply a valid email address so that you can be notified when your download is ready.”  Then follows an email from support@jorum.ac.uk that informs that “The item export you requested from the repository is now ready for download.” and includes a link to download the compressed file which comprises all files associated with the resource.*

“Preview content package” which allows the user to quickly view the different files and components of the resource in their browser without downloading (though it doesn’t work for .zip files)

“Download original content package” does exactly what it says on the tin and downloads a compressed file of all files associated with the resource.*

* I’m not entirely sure what the difference is between “export” and “download” – though the exported zip is bigger and contains more files (dublin_core.xml as well as imsmanifest.xml for example) – may be someone can enlighted me?

CC Licence Note – briefly explains implications of CC and links to relevant anchor later in the record.

Files in this item - allows the user to expand a list of files and download them individually (this particular item comprises 16 .zip and 2 .docx)

Creative Commons Licence – Link to relevant CC licence (opens in a nifty little window.)

Terms of service – Link to Jorum terms of service (also opens in a nifty little window)

This item appears in the following collections – linked to appropriate search terms in browse tree

Show full item record (repeated link from top of page) - Full Dublin Core metadata record

This item has been viewed x times – presumably counts visits to the record page

All in all, first impressions are pretty favourable and there are certainly some ideas that I would like to explore for Leeds Met Open Search – I’ve already included the AddThis button on the development server and plan to go live with it as soon as it has been approved by the powers that be (there are one or two issues with user tracking by this third party service – Mike has disabled Flash tracking that the widget injects into the page by default but it will still track each click-through.)

I’m also keen to explore how we may manage packaged content in a similar way to JorumOpen (preview content and download options for individual files) – currently we have very little packaged content in the repository but the default download link is currently just for an individual file – I do know that intraLibrary is able to manage content packages, however, and that a package download link is exposed by SRU so I think we should be able to achieve this.

Browse by date (of deposit) should also be achievable I think but browse by author is a little more problematic by SRU (both for research and OER) as there is no authority file for authors.

I’m not sure about recording page visits – will need to speak to Mike.

Now I just need to figure out the most efficient way of getting our UniCycle resources into JorumOpen – I will look at the deposit process in a later post (depositors can log in from JorumOpen Home via UK Federation) and I think Jorum are still exploring harvesting RSS feeds from ukoer projects though, as discussed in a recent post, our feed is not currrently suitable for this.

End of a pipe dream?

I’ve been enjoying exploring Yahoo Pipes and have now managed to generate a feed for OER that also incorporates the author vCard; I’m sure it must also be possible to extract other data including rights information (though I’m not quite sure how!):

http://pipes.yahoo.com/mrnick/build_rss_from_xml

(vCard not visible in the Pipe but is displayed if the Pipe is rendered as RSS)

It also occurred to me that it may be possible to use a similar method to extract the abstract for research RSS feeds (which is in the second description field) and I’ve been grappling with Pipes to this end but am struggling at the moment – tantalisingly I am able to construct a “Path to item list” that returns an individual abstract but for the life of me, can’t figure out how to return abstracts for all records – SRW:records.SRW:record.1.SRW:recordData.lom:lom.lom:general.lom:description.1.lom:string.
content

I’ll certainly continue to use Pipes as it’s a very powerful tool, especially for a non-programmer like me, however, for the time being this mini-project is postponed. Nothing is ever wasted though and I’m sure what I’ve learned will come in useful somewhere down the line….

Pipe dream

This afternoon I’ve been grappling with Yahoo Pipes, trying to generate a feed that incorporates metadata from an SRU query.  I’ve made a modicum of progress and, as I’m now a bit stuck, this is just a quick post to document that modicum before it all leaks away over the weekend.

The Pipe module that seems most appropriate is “Fetch Data”: “This module retrieves any XML, JSON, iCal or KML file and tries to extract a list of elements using the provided path parameter.”

I input an appropriate URL to query “ukoer” which will return all OERs uploaded as part of UniCycle:

http://repository-intralibrary.leedsmet.ac.uk/IntraLibrary-SRU?recordSchema=lom&maximumRecords=50&operation=searchRetrieve&version=1.1&query=ukoer&SearchSubmit.x=18&SearchSubmit.y=24&x-info-2-auth1.0-authenticationToken=oer

And read the instructions here which describe how to use the “Path to item list” field in order to extract just a portion of the data by listing the nested XML elements, separating each with a dot (“.”)

After a bit of trial and error I was able to zero in on the “Description” field for the first record by entering SRW:records.SRW:record.0.SRW:recordData.lom:lom.lom:general.lom:description.lom:string.content into “path to item list”

However, when I attempt to run the pipe, nothing is returned  – though the correct field IS displayed correctly in the debugger panel:

Also, what I would like to do of course, is to return the “Description” field for ALL records but I have no idea how to achieve this…I’ll have another look when I’m nice and fresh on Monday morning!

Really (not so) Simple Syndication

In theory RSS is simple, Really Simple, but the way that the technology is implemented by our underlying repository software (intraLibrary) and issues around how we have needed to integrate that software within our repository infrastructure in order to ensure appropriate Open Access has meant that, in reality, it has been anything but.

Broadly speaking, the issues are two fold:

• The fields exposed by the intralibrary RSS feed are limited to “Title” and “Description”.

• The URL exposed by the feed points to the public URL generated by intraLibrary (which would simply be the resource itself, either a file or URL i.e. without the context of the metadata record) whereas I need it to point to the Open Search metadata page.

I have been aware of these issues for some time but finding a resolution has been elevated in priority recently due to two separate, though similar, use-cases being explored by JorumOpen and the Xpert project at Nottingham University, that effectively seek to extend RSS from simply being a notification system to potentially also being used to harvest repository content (some are of the view that this not an appropriate use of the technology and that there are established technologies more suitable, specifically OAI-PMH and SWORD – see Intrallects’s Charles Duncan’s contribution to the discussion on Lorna Cambell’s blog).  The full discussion on Lorna’s post is certainly worth reading and also includes several contributions from Xpert’s Julian Tenney and Pat Lockley.

By now I have had an extended correspondence with Pat, initially prompted when I submitted the generic intraLibrary feed to be harvested by Xpert.  Preliminary feedback was that when Xpert tried to harvest our feed, it appeared that a randomly generated “key” was added to the URL, meaning they were seeing these urls as new resources, whereas they were actually duplicates (this was a consequence of the manner in which intraLibrary generates a publicURL each time a record is returned with a new machine generated “key” each time.)

As I described in a recent post, a little bit of Twitter serendipity and specifically input from Owen Stevens, subsequently led me to use Yahoo Pipes to redirect to the Open Search metadata page instead of the publicURL; Yahoo pipes also allows a pipe to be rendered as RSS and it occurred to me that this new feed could be resubmitted to Xpert for harvest.  Sure enough Pat confirmed that this new feed rendered from the pipe could indeed be harvested and that each URL was definitely unique (generated, of course, from resource unique IDs by http://repository.leedsmet.ac.uk/main/index.php – see http://repositorynews.wordpress.com/2009/11/09/leeds-met-repository-open-search-version-2-0/ for more info).  However, Pat also emphasised that it would be nice to find a generic way of harvesting without the pipe but for the time being I’m not sure we are in a position to implement such a solution; the work that we have done at Leeds Met on the Open Search interface and my personal obsession with redirecting RSS feeds is quite distinct from Intrallect’s primary commercial interest and so unlikely to be *officially* supported by the company (Note: As always Intrallect have been very supportive to me and certainly have proactively supported the development of our infrastructure throughout, it’s just that this isn’t a priority for them in the same way.)

As Owen has pointed out, all the Pipe does is take the ID which is part of the item’s GUID in the original RSS, and constructs a link to the metadata page which is put back into the RSS feed. You could obviously do this programatically (which might be a solution to Pat’s requirement of harvesting without the Pipe?) – it was just easier to throw together something quickly using Pipes and we simply don’t have the resources to explore another (programmatic) solution in detail.

Owen has also suggested that, as intraLibrary supports OAI-PMH, this would be the ’supported’ mechanism for harvesting which really brings us full circle back to Charles’ argument referred to earlier in this post.

Note: On Lorna’s blog, Julian argues back at Charles that “OAI-PMH/SWORD etc are big technical barriers for many people who have resources to expose and that anyone can make a feed”; though in a subsequent comment, Pat does acknowledge that “it might be logical that if we are making a second RSS for harvesting we might use some other technology instead.”

All of which doesn’t get me very much further with my other RSS issue which is  the limited metadata with just <title> and <description> exposed by RSS and it was this that seemed to be more of an issue for harvest by JorumOpen with feedback from Gareth Waller confirming that the feed from intraLibrary “does not represent the metadata for the individual items (or the top level feed) in DC format (except of course date)” and in order for our feed to be processed with the code Gareth has implemented in JorumOpen , the feed would “need to contain DC metadata for each of the items and, more importantly, licence information”.  The feed from the Pipe, of course, still comprises just <title> and <description> and so would not be suitable for registering our OER content in JorumOpen.  (N.B. The limited metadata, of course, will surely also affect the quality of metadata harvested and searchable via Xpert?)

What would really make my life easier I think is for JorumOpen and Xpert to harvest my metadata using OAI-PMH (go on , you know you want to!) but for the time being I am just happy to have found a method to generate RSS feed that point to my static URLs at http://repository.leedsmet.ac.uk/main/index.php!

Return all records via Open Search

This primarily for my reference – in order to return all records from a given collection enter cql.allRecords=1 into the standard search at http://repository.leedsmet.ac.uk/main/index.php and select which token you wish to use (Research/Open Educational Resources)

Using Yahoo Pipes to redirect to Open Search metadata page instead of intraLibrary public URL (and the power of Twitter)

First of all, a big thank you to Owen Stephens – @ostephens – who responded to my musing tweets on RSS by assembling a Pipe that “Rewrites Intralibrary RSS feed to use ‘link’ to metadata rather than object”; a great example of the power of Twitter for anyone who still thinks it’s an exercise in pointless self-revelation, full of trivial noise.  As Amber Thomas -@ambrouk – put it recently and as I also to tend towards, Owen exemplifies “whole person Tweeting” not restricting our interraction on Twitter to our professional sphere but filling it with more personal and sociable “noise” – the closest thing to a virtual office you will find.  I’ve never met Owen in real life but I shall certainly buy him a pint if our paths ever do cross!

As anyone who has passed by these parts before will know, we have been wrestling with intraLibrary for about two years now to develop a blended repository of Leeds Met’s research output (both Open Access full text and citation only) and Teaching & Learning material (both Open Educational Resources/material for federated access only) and we have spent a lot of time developing the IRISS SRU interface as a front end to provide appropriately differentiated Open Access to the different types of resources.

One of the simplest ways for a repository to alert users to new content is via RSS and it is very easy to generate a feed for pretty much any criteria in intraLibrary; I have generated several feeds for both research collections (by faculty) and for OER.  There are, however, two main issues with these feeds:

• The first problem is associated with the metadata template I have implemented for research and the lack of flexibility to customise which fields are exposed via RSS – I haven’t yet got a solution to this issue.
• the second problem, however, arises because the URL exposed by the feed points to the public URL generated by intraLibrary whereas I need it to point to the Open Search metadata page and this is where Yahoo Pipes can come in.

I don’t have much experience with Pipes but it is billed by Yahoo as “a free online service that lets you remix popular feed types and create data mashups using a visual editor. You can use Pipes to run your own web projects, or publish and share your own web services without ever having to write a line of code.”

Owen’s pipe has three components:

• “Fetch feed” which is simply the intraLibrary generated RSS feed
• “Regex” which applies a regular expression to an item attribute.  In this case it takes the components of the public URL in item.guid.content - oai:com\.intralibrary\.leedsmet:(.*) – and replaces it with the components to build the URL of the Open Search metadata page – http://repository.leedsmet.ac.uk/main/view_record.php?identifier=$1&SearchGroup=Open+Educational+Resources
• “Rename” which does what it says on the tin and simply renames or copies item atributes – in this case item.link becomes objectlink and item.guid.content becomes link

The Pipe Output can be subscribed to as RSS which gives us a feed that does indeed link to the Open Search metadata page rather than the intraLibrary public URL:

http://pipes.yahoo.com/pipes/pipe.run?_id=5c085e83cb144f9a1796558fa7d6d253&_render=rss

Simple when you know how!

N.B.  Some of these links actually DON’T work and I haven’t yet been able to figure out quite why.  As far as I can tell the affected resources were all uploaded as part of the Reproduce project and the links are to none-existent unique identifiers e.g.  http://repository.leedsmet.ac.uk/main/view_record.php?identifier=1432&SearchGroup=Open+Educational+Resources .  I think it may be because some of these records seem to have been ascribed 2 unique identifiers – this is an automatic process in intraLibrary and configured as uneditable so I’m not sure how it has happened.  However, they were originally uploaded by another user before the user profiles and metadata template for ukoer were fully configured and I may need to delete and re-upload as I have done already with http://repository.leedsmet.ac.uk/main/view_record.php?identifier=1673&SearchGroup=Open+Educational+Resources – I’m not sure how/when this will be updated in the feed and currently it’s still linking to the none-existent UID; it may take a little time to update.

Anyway, I’ve copied @ostephens Pipe – hope you don’t mind Owen, I couldn’t find any rights information(!) – and replaced the feed with one of my research feeds – Carnegie Faculty of Sport and Education – and modified the “Regex” module to redirect appropriately by replacing oai:com\.intralibrary\.leedsmet:(.*) with http://repository.leedsmet.ac.uk/main/view_record.php?identifier=$1&&SearchGroup=research.

N.B. As mentioned, there is an additional problem associated with the research metadata template and the lack of flexibility to customise which fields are exposed via RSS – the only way I have been able to accommodate all of the information required for research (using EPrints software as a template) with the intraLibrary metadata schema (UK LOM) is by using multiple description fields as extensions; ideally I would like the abstract to be exposed via RSS but this is in second description field whereas it is the bottommost description field that is exposed via RSS which generally contains whether the resource is refereed or not – this is not terribly relevant so I’ve added a Mapping to the “Rename” module to remove it which means the feed now exposes just the title which does indeed link to the Open Search metadata page:

http://pipes.yahoo.com/pipes/pipe.run?_id=286bbb1d8d30f65b54173b3b752fa4d9&_render=rss

A better beta – Open Search Version 2.0

After mounting pressure from the University, we have now added live links to http://repository.leedsmet.ac.uk/main/index.php from Library Online and the research web-pages but it is important that folk are aware that it is still very much a beta implementation – I have tried to summarise ongoing development requirements below (both for research material and Open Educational Resources) and I am very keen to receive user feedback to inform ongoing development; I also plan on doing some formal user evaluation in the New Year.

The two main issues we have faced throughout the development process is that intraLibrary is designed as a Learning Object repository requiring user authentication. This means we have needed to develop an appropriate metadata template for research material (mapping UK LOM onto Dublin Core) and develop an external, openly accessible search interface to query that metadata (via SRU) and display results appropriately.  Though there has been consultation throughout development I am still conscious that, *potentially*, there are issues outstanding that need to be more widely considered, especially as we move to establish a workflow involving more staff to populate the repository; obviously any changes to the metadata template will carry a more significant overhead the greater the number of records there are.

For research material, the workflow is currently configured in two stages and the approach we are currently considering would require me/designated administrator to complete the metadata in Table 1 and for trained cataloguers to complete the cataloguing information in Table 2:

---

Table 1 (primary metadata entry)

Metadata element	Comments
Faculty	6 Leeds Met faculties (& Thesis/dissertation)
Title	Article title
LOM identifier	Unique identifier applied automatically by intraLibrary
Digital Object Identifier	(if available) Utilising additional (editable) instance of LOM identifier field
Bibliographic metadata: Source title Journal volume Journal issue Source publication date Start page End page	It may not be necessary to complete all of these field depending on the “Type of resource”; they will all be required for a peer reviewed journal article but a book, for example, might only require “Source publication date” to be completed while a book chapter might require “Source title”; “Source publication date”; “Start page”; “End page” N.B.  A related issue that needs to be considered at this stage is that for records entered so far I have been inputting year only to the “Source publication date” field – however, we will need to differentiate records by census period; this perhaps could be achieved with a more specific date in the “Source pub date” field or we could explore using an additional field to record this information.
ISSN/ISBN*	Description field 1/4 – can’t really be differentiated from other description fields for search by SRU
Abstract*	Description field 2/4 – can’t really be differentiated from other description fields for search by SRU
Published/Not published*	Description field 3/4 – can’t really be differentiated from other description fields for search by SRU
Refereed/not refereed*	Description field 4/4 – can’t really be differentiated from other description fields for search by SRU
Author	System bug meant this could not be independently queried by SRU until recently – issue should now be resolved but not yet integrated with interface
Publisher	System bug meant this could not be independently queried by SRU until recently – issue should now be resolved but not yet integrated with interface
Contribution date	Automatically completed
Technical format	Always PDF for research
Type of resource	Scholarly text/ Book/ Book chapter/ Edited book/ Book review/ Miscellaneous conference item/ Conference contribution/ Journal item/ Electronic journal/ Electronic newspaper article/ Report/ Confidential report/ Submitted journal article/ Thesis or dissertation/ Working or discussion paper/ Lecture transcript NB. It is relatively straightforward to add terms/modify existing terms though there may be work involved modifying records. For example, it has been suggested that the vocabulary term “Journal item” should be changed to “Journal article” and while this is relatively straightforward, there is no way of making a global change without reviewing each record individually – currently 218 items.
Statement of Copyright and Restriction	Where a record is citation only (i.e. no full text available) I am using this field to record information from SHERPA/RoMEO to indicate whether I should pursue the full text (for my reference only – i.e. not displayed in Open Search interface).  When there is a full text available this field will generally record that it has been uploaded in line with the publishers’ terms and conditions and IS displayed in Open Search e.g. http://repository.leedsmet.ac.uk/main/view_record.php?identifier=696&SearchGroup=research)

---

*The only way I have been able to accommodate all of the information required for research (using EPrints software as a template) with the intraLibrary metadata schema (UK LOM) is by using multiple description fields as extensions – though these can be differentiated for display purposes, utilising a template to ensure consistent entry – e.g. http://repository.leedsmet.ac.uk/main/view_record.php?identifier=696&SearchGroup=research, they cannot easily be differentiated for search purposes.

---

Table 2 (cataloguing information to be completed by trained cataloguers)

Metadata element	Comments
Keyword	Controlled vocabulary utilising Library of Congress Authorities
Classification	Against (top two levels) of LCC

---

How metadata is related to the functionality of the Open Search interface

The current functionality of http://repository.leedsmet.ac.uk/main/index.php is as follows:

Function/field	Comments
Standard search	Comprises a simple search box that will search the entire metadata record – can manage simple Boolean operators (AND/OR) and perform a search to “Match exact text” (Boolean functionality needs reviewing)

---

Function/field	Comments
Advanced search (under development)	Comprises several metadata fields that can be cross referenced using simple Boolean logic (AND/OR – OR by default)
- Standard search	Should be self explanatory though early feedback from users suggests that it may not be!
- Title	Searches the “Title” metadata field only.
- ISBN/ISSN	In theory searches ISBN/ISSN – in practice searches all four description fields (see metadata Table 1 above)
- Author	In theory searches only the “Author” metadata (not yet implemented due to system bug – currently performing a standard search)
- Subject	Searches the “Subject” metadata field only.  NB.  Only one field – need to search multiple “Subject” fields.
- Type	Drop down list of vocab terms “Type of resource” (see metadata Table 1 above)
- Description/Abstract	In practice searches all four description fields (see metadata Table 1 above)
- DOI	Searches the “DOI” metadata field only
- Publisher	In theory searches only the “Publisher” metadata (not yet implemented due to system bug – currently performing a standard search)
- Format	Drop down list of all MIME types – in practice this will always be PDF for research – may be more appropriate for OER (see below)

---

Function	Comments
Browse	Currently two options to browse repository contents (research only)
Browse by Library of Congress category Browse by Leeds Met Faculty	Currently no way of knowing how many resources are available at a given level – requires further technical development to display “number of resources”

---

Open Educational Resources

I have so far been considering just research material but this, of course, is just one of the two main “types” of content that we need to manage with the Leeds Met repository.

Though infrastructure does not come within the remit of the UniCycle project, which is more focussed on the process around reuse of OER, an adequate search interface is something of a prerequisite; we have begun to integrate search functionality specific to OER into http://repository.leedsmet.ac.uk/main/index.php and are now able to differentiate between research and Open Educational Resources, for example, (using collection tokens), however, the metadata template for OER is quite different from research so ideally we will need a separate search form to reflect this.  Metadata for OER is currently based on the “old” Jorum template (i.e. not JorumOpen) and comprises the fields in Table 1a below:

Table 1a

Metadata element	Comments
Title	OER title
Description	Single instance only
Keyword	Uncontrolled/author produced keywords in line with ukoer guidelines (must include ukoer as keyword)
Contributor (Author)	System bug meant this could not be independently queried by SRU until recently – issue should now be resolved but not yet integrated with interface.
Contribution date	Automatically completed
Technical format	MIME media type – Comprising 70 technical formats – almost certainly don’t need them all for OER – are currently all exposed as list on advanced search form
Type of resource*	Terms from LOMv1.0: Diagram/ Exam/ Exercise/ Experiment/ Figure/ Graph/ Index/ Narrative Text/ Problem Statement/ Questionnaire/ Self Assessment/ Simulation/ Slide/ Table; Terms we have added to the vocabulary: Podcast/ Not Applicable/ Presentation/ Photograph/ Quiz/ Spreadsheet/ Tutorial/ Video/ Lecture/ Game/ Animation/ Assessment/ Audio/ Case Study/ Database/ Workbook N.B. As with research vocabulary, it is relatively straightforward to add new terms/modify existing terms though there may be work involved modifying records
Statement of Copyright and Restriction	As we are using Creative Commons licensing for OER we can probably dispense with this field – I will need to contact Intrallect to remove it from the template
Categorisation	OER are currently categorised against JACS (Joint Academic Coding System)

---

*The advanced search form currently only lists the research vocabulary in “Type” – this is an example of why we may need a separate form for advanced search of OER that displays the relevant vocabulary.

---

Display of OER

We also need to think about how OER records are displayed – currently this is a bit rough and ready, adapted from research results.  For example full text/external resource may not be as relevant for OER and  we may wish to display “Type of resource” here instead:

http://repository.leedsmet.ac.uk/main/search.php?q=ukoer&SearchSubmit.x=70&SearchSubmit.y=17&SearchSubmit=Search&SearchGroup[]=Open+Educational+Resources

---

Browse for OER?

In order to facilitate browse by subject heading (JACS) in the Open Search interface it will be necessary to integrate this functionality into http://repository.leedsmet.ac.uk/main/index.php in a similar way as has been implemented for research (same caveat applies in that further technical development is required to show numbers of resources in the browse tree.)

Leeds Met Repository Open Search Version 2.0

This is a bit of a trailer for our shiny new interface that I hope will go live in the next week or so and a run down of some of the new features.

It’s far from perfect and should still be seen as a beta – we very much need real users to start using it and I’m feeling a little nervous about how it will be received as I know how much work Mike, in particular, has put into it.

The interface has evolved from an SRU client developed for by IRISS – http://www.iriss.org.uk/learnx – which is available under GNU General Public Licence v.3 at http://code.google.com/p/sruopensearch/ (N.B.  We still intend to release our modified code under a similar licence.)  Learning Exchange Open Search is a great front end for searching intraLibrary but with just a simple search box lacked advanced search functionality that was essential for us.  We also wanted to use intraLibrary to manage resources for teaching & learning aswell as facilitating Open Access to our research collection in accordance with the EPrints model.

The tabbed interface incorporates an “Advanced search” form that allows users to cross reference multiple fields specifying AND/OR and they are also able to search for either “Research” or “Open Educational Resources” which uses authentication tokens to return results from the appropriate collections in intraLibrary:

There are also big changes in the way that results are returned; Mike has been able to use a unique identifier to build individual pages for each record so that a search will return a set of results that indicates whether or not each individual record has the full text available:

These titles then link through to a static HTML page comprising all of the metadata associated with that record including a published URL and, where the full text is available, a link to the PDF in intraLibrary:

This static page should be indexed more effectively than was the case before though there is one small fly left in the ointment in that the public URL generated by intraLibrary that is used to download the full text is dynamic which means it cannot be indexed by Google; I’m not sure if it will be possible for Intrallect to do anything about this though they are aware of the need for full text indexing and are looking into the problem.

Article on Open Educational Resources in Times Higher Education

Get it out in the open by Rebecca Attwood (24th September 2009)

Testing the VLE PowerLink

To be honest, PowerLink is probably overstating it a bit but it is a link that allows us to search intraLibrary from the VLE and it does work. Sort of. But it’s not very powerful.

The main issue is the very basic nature of the search facility – just a simple search box with no way to perform a more advanced search:

So it’s not a great deal of use unless you know what you’re looking for.

The search functionality does support Boolean operators; the term ukoer, for example, will return the 13 items that I currently have identified with that tag in the keyword field:

Whereas ukoer AND decision will return the single record “Decision Making” (ukoer OR decision of course, will still return all 13 records) – there is no automatic Boolean however and ukoer decision will return no results at all rather than, say, doing an OR search by default.

Search is also a little crude in that it will find adjacent words in the metadata but only if they are entered in quotation marks. So decision making without quotes will not return any results though “decision making” does return the expected result:

An additional issue is that, as we are using intralibrary to manage research material as well as learning and teaching material, at the very least we will want to differentiate between these two categories. It is possible to configure the PowerLink to filter by collection and we are currently filtering on Open Educational Resources (and Learning Objects though that collection is not currently searchable externally until we have further developed Leeds Met Open search and configured that interface to differentiate between research & learning and teaching material). It will be useful, however, to also search for full text research papers that may not be available elsewhere but without an advanced search the only way to do this would be to switch off all filtering and allow the PowerLink to return everything….unless we can install two separate instances of the PowerLink in Blackboard and configure them to search different collections. This would be a quick and dirty solution and a bit clunky but, failing technical development of the PowerLink itself, might be the only option – of course, the two instances would need to be clearly named to identify the respective content they would return. We don’t even know if it’s possible yet though and my colleagues in the VLE team are looking in to it as we speak.

So not perhaps a full solution, not as sophisticated as MrCute for Moodle, for example, which, as well as more advanced search functionality also supports searching multiple repositories and depositing from the VLE back into a repository (it was supposed to include Jorum though was disabled last I heard and not sure what the status quo is with ongoing development to JorumOpen).  Limitations notwithstanding, I’ll certainly be testing with teaching staff as is, as something is better than nothing and experience has shown that I’d be ill advised to wait for the perfect solution!

If any of the Keele crowd should pass by these parts I’d be very interested to know if they have done any work refining/extending the functionality of the PowerLink or plan to do so – like us Keele are running intraLibrary 3.0 and Blackboard Vista. I’d also be keen to learn of anybody adapting MrCute for Blackboard.