Preamble
What follows after the preamble is an outline of the Intralibrary v3 Learning Object Metadata (LOM) fields used in the test workflow for adding CLA licence scanned material.
In the initial (pre-v3) Intralibrary software client the metadata fields available to catalogue CLA licensed material was limited. Intralibrary had not yet included the additional “CLA” data fields required in their default LOM application profile at the time Keele wanted to launch their digitisation service.
Throughout the Pathfinder project we simply used the “title”, “description” and “classification” LOM entries to describe CLA material in the “pre-v3” repository. This enabled Keele to launch a digitisation service, using the repository as a store for PDF documents, held securely in a “private” Intralibrary collection. Items digitised and used in Keele’s Virtual Learning Environment (VLE) were “bundled” under classification nodes in the repository “library”, and were tagged in such a way that they cross-referenced with order numbers used by the library digitisation team. A separate record was maintained of all items scanned in the meantime, to ensure reporting to the CLA went to plan in February 2008.
Intralibrary has worked well as a storage solution for these materials, and the “public URLs” provided for academic staff to use in the VLE have worked reliably. Academics and students at Keele have benefited from the service, and more than 70 course modules are accessing over 350 documents from the repository server.
With the release of Intralibrary v3 earlier in April it was now possible to test whether the new CLA application profile could accommodate CLA type data, and also the CLA reporting function being built into the software client by Intrallect (see earlier blog entry).
It’s clear that there is a high degree of flexibility in how metadata managers might want to structure their application profiles within Intralibrary. The choices made by Keele Pathfinder may not provide the definitive answer to where CLA metadata can be located within the LOM template.
What has been tested in v3 in relation to the CLA data recording and reporting requirements does work though, within the existing LOM application profiles provided by Intrallect so far.
The nature of a self-archiving repository is such that there has to be a degree of flexibility in what the user wants to do as regards adding metadata for any items they add. Some sort of balance has to be struck where users follow simple “agreed norms” in adding metadata, and efforts made on the part of system administrators to ensure some degree of consistency in how items are classified and tagged in some way to enable others to simply find it.
However, for CLA reporting requirements, things are clear cut; institutions have to record certain types of data as a condition of holding the licence. Anyone using Intralibrary v3 has to make a decision on how best to use the LOM template provided, and to make sure the report function isolates the metadata fields they have selected to describe such material. The metadata application profile can also be used to record information useful in the management of CLA scanning, but not necessarily essential for the return report (see below).
Given the beta version we’ve had to work with (and the limited time to do the test also!) the following is the metadata fields selected for use in the metadata application profile for our CLA workflow. Our hope is any future user of this repository product will find the following useful.
The Application Profile
(The following fields were set as “mandatory” within the Intralibrary v3 application profile).
| LOM Reference | Label | Notes |
| 1.2 | Title | We allowed for 2 incidences of this field, one for file title based on “order number” and “extract title”. |
| 1.3.1 | Catalogue | ISBN (International Standard Book Number) of source |
| 1.3.2 | LOM Identifier | “ISBN” entered here to “identify” the preceding entry as the ISBN. |
| 1.3.3.1 | Source Publication Type | Selected from a controlled vocabulary set up on Intralibrary (e.g. book chapter, journal article). |
| 1.3.3.2 | Source Title | Title of item extract scanned from. |
| 1.3.3.3 | Journal Volume | An “n/a” had to be entered in the metadata if the item wasn’t a journal! |
| 1.3.3.4 | Journal Issue | As above. |
| 1.3.3.5 | Source Publication Date |
|
| 1.3.3.6 | Start Page | Of the extract. |
| 1.3.3.7 | End Page | As above. |
| 1.5 | Description | Harvard style reference of the extract was added here. |
| 2.4.1 | Module Code | Keele Module Code |
| 2.4.2 | Module Title | Keele Module Title |
| 2.4.3.3.1 | Module Start Date |
|
| 2.4.3.4.1 | Module End Date |
|
| 2.4.3.5.1 | Module Duration | Entered as 1 year for all. |
| 2.4.3.6 | Number of Students |
|
| 2.4.3.7 | Lecturer |
|
| 3.3.1 | Role Of Metadata Contributor | In this workflow, the source “author”. |
| 3.3.2 | Metadata Contributor | The source author name. |
| 4.1 | Technical Format | Entered automatically during item upload. |
| 4.3 | Location Of Resource | The shelf number for the source item scanned. |
| 7.2.3.1 | Catalogue | Used for added author entries (2nd author or editor). |
| 7.2.4.4.1 | CLA Code A | “Source information” for CLA, controlled vocabulary option provided. |
| 7.2.4.2 | CLA Code B | “Reason for Scanning” for CLA, controlled vocabulary option provided. |
| 7.2.4.3 | CLA Code C | “Artistic Work” statement for CLA, controlled vocabulary option provided. |
Keywords: CLA, Intralibrary, Intrallect, Keele, Metadata, Pathfinder, Workflows
No comments:
Post a Comment