Visit from intraLibrary

I spent most of today with Nick and Peter from Interlect resolving some of the issues with the repository. The discussion revolved around getting intraLibrary to do what we want in terms of learning objects (LOs). I haven’t had a great deal of time previously to play with the system and it was a good opportunity to sort out some of the complexities surrounding collections and application profiles and their relations to various elements with in the system.

There was some initial discussion with Wendy and Jill about the difference between LOs and research papers. While it is the aim of the repository project to develop an open access platform and community for research papers this is not necessarily the case with LOs. There is concern among staff about making LOs public. This has been highlighted by Nick and other repository developments . For now the general consensus is to proved access only within LeedMet and via a different interface to that used by the research outputs. Ideally we would like to link up to the research interface and at the very least allow access to LOs metadata. This will then enable interested parties to contact staff in to arrange access to objects on a one to one base.

Further to Nick’s post about the components and structure of intraLibrary I came up with the following diagram as an idea to understanding these relationships.

IntraLibrary concepts

As Peter noted in our discussions it is the group that is essential to the process and defining an individual’s role and permissions within that group. I suspect a will amend my view of these elements as I continue to organise the repository and my understanding grows.

Another thing we discussed at great length was IP and LOM Right section. As a mentioned earlier I have included Rights in the mandatory minimal set of metadata for LOs in the repository. Peter suggested this what not a good thing. He suggested that this should be added later by a cataloger. I thought it would be very hard for anyone to trace Rights on a LO that has minimal information, hence leaving it up to the depositor. Peter then suggested using a Usage agreement that depositors need to agree to and a take down policy. This puts the onus on the depositor to check their content and then a standard Rights policy can be applied. Special cases will have to go through a more manual process.

Other Issues:

• Authentication is still a big issue and realistically Peter suspected it could take up till March to resolve. This left us with the decision to manually setup user accounts for LO depositors.
• There are still some CSS issues in Internet Explore particularly in the upload process and personal preferences. A more recent IntraLibrary build should sort this out and we have been promised to have this done by the end of next weekish!
• IMS packages produced by the replica project have problems with viewing and metadata extraction. Hopefully peter has solved this one via a setting in the admin section. Unfortunately what ever we did crashed Interlibrary for a couple of our so we didn’t get round to testing it at the time. Job for first thing on Monday I suspect.
• As mention previously I am currently unable to upload a single XML metadata file to associate it with content in the repository. This is essential for use with the generator we have devised.

Linking to intraLibrary

Today I started looking at the repository in more detail. There are several jobs that need to be done in order to ensure that metadata produced by the automatic generator prototype will be successful integrated. The first of these is to define the subset of LOM that is to be applied to all LOs. Having come from eCat the auto-generator currently implements a sub set of the LOM standard. Discussions with Ben when we were looking at adapting eCat suggested that the subset it was using was well researched and was most practical to users.

From general discussion around the university there are small pockets of individuals producing LOs in a packaged format. Some of these maybe produced using compendle which is SCORM IMS compliant and contains all the necessary metadata. Others may be using wimba create (formally course genie) which I have been told produces little or no metadata, (although this is contradictory to the information on their web site, this maybe a version issue). Some may also be using the eCat plug-in for word, which we promoted last year. For most, leaning content will be produced using more familiar tools such as power point and word documents and possibly some web pages for the more adventurous. This type of content is the main focus for the auto-generator. But these different generation process produce different metadata and some none at all.

From the perspective of the repository just about any type of content can be submitted or referenced. So this isn’t a problem. The problem lies in what metadata (application profile form Interlibrary view) should be required. In order to account for those applications that produce and package LOs all possible fields should be made available. However for those having no metadata with their content and possibly no means of producing any, a very minimal set should be presented to get some basic information off the depositor.

So bearing these two extremes in mind I opted to set all metadata fields as optional and thus accounting for all possible subsets of LOM, but then presented the user with only a minimal mandatory set, viewable by the depositor. These included, the LO’s title, description, keywords, authors detail (for content only), contribution date and Rights details.

The second job I need to do was test how the process of upload works with already packed objects. For this I used those LOs produced the by the replica project. These are IMS content packages most seam to be dated as 2005. IntraLibrary should detect this and extract the embedded metadata to populate its own metadata records. This does not appear to be working for most of the objects uploaded. IntraLibrary also has a preview function which should work with most of the file types it can store. Again this function only worked properly with some of the LOs. Downloading and unpacking these LOs was fine and the content was the same as the originals. This might suggest that either IntraLibrary is not backwards compatible with previous standards or the packages uploaded are not well-formed.

The final job I had to do was to check the upload of external XML LOM files for attachment to content already uploaded. This was one of the features I most liked about IntraLibrary and also enable me to develop a standalone auto-generator with no packaging functionalities. Again I was to be disappointed. Nothing happens when I use this facility on IntraLibrary. I’ve double checked the XML format and it all seams correct so at the moment I have no idea why this is happening.

Nick is arranging for a meet with IntraLibrary within the next couple of weeks. Hopeful we should be able to resolve these problems then.

InrtaLibray training day

The first training/design session with IntraLibrary was held today. The morning was a general overview the system and an opportunity to play around with the new version. The afternoon was spent in discussion with Nick and his team on what was need to get this all up and running.

Their new version 3.0 (Beta) has had a complete interface re-vamp and I wasn’t overly impressed. In my repository report I mentioned that the icons and interface for IntraLibrary was one of the things that I felt made it stand out from the rest. The general ideas have been retained in the new version but the icons are less prominent as they have opted for much softer graphics. One thing they have removed, which I suggested they put back, was the inline help from the question mark icon. For a none-novice user this is very handy, at least I thought so, as it assisted in clarify what you suspected certain areas and functions were for. Much faster than having to go through the full help list. They have also made the help icon almost invisible. I asked a fellow participant if they could find it and it took them over half a minuet which is not good.

The afternoon session was with Nick’s development team, Jill and myself. During this we discussed the types of workflow required for both learning objects (LOs) and research outputs; security and authentication; taxonomy creation and how this related to LOs and research. One of the main issues to come out of this was the need for an external (available on the public web) search and result pages. These need to be developed in house. Another university (I forget which) has already developed and released (open source) a solution to this problem. We also discussed the possible integration with Sword, a client side depositing application which is currently being developed.

All in all it was an interesting day and while I’m sad to loose the old interface IntraLibrary’s functionality is still more adaptable than the rest. There will be another two training/development days which I hope to attend and Peter (chap from IntraLibrary) said he would get the API’s to me ASAP so we can start looking at integrating the ideas developed in Streamline.