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.
