Would you like UKOER with that?

Yesterday I had a chat with the learning technologist from Innovation North (faculty) about all things repository and, more specifically, UniCycle – he also brought along a faculty colleague who is exploring the best way of disseminating laboratory training videos to students via the VLE.

intraLibrary can’t stream video and I candidly pointed out that if the only requirement was to make these video tutorials available to students through the VLE then the planet eStream server would be by far the simplest solution – just upload the video to eStream and drop the URL into an X-stream module.  Job done.  However, there is no reason we can’t also catalogue the URL in intraLibrary and there are several potential benefits to doing so not least for ukoer – depending on IPR and licencing considerations of course, more on that in a minute.

The only question that gives me slight pause for thought is the wisdom of effectively double-cataloguing the same resource in two systems – when I was initially exploring planet eStream some time ago, it was pointed out that eStream is already a fully searchable resource and there was some resistance to double-cataloguing in this way as being inelegant.  The issues are perhaps similar to the question I raised in a previous post about making ukoer available both via a local repository and JorumOpen. However, as far as I can tell, metadata attached to resources in eStream is extremely limited so why not add standardised ukoer metadata and link out to them from intralibrary – is there any practical reason why this is a bad idea?

Inelegance notwithstanding, other potential benefits of this approach are being able to search for eStream video via the VLE PowerLink and the concommitant advantage that resources catalogued in the repository aren’t restricted to an individual X-stream module.  In theory, of course, there is nothing to stop a tech-savvy tutor linking out to eStream – or YouTube for that matter – to their hearts content, from the VLE, via email or from anywhere else that takes their fancy – in practice, however, they need to be able to search for a wide range of resources from a single, simple interface that is well established in the institutional infrastructure and that clearly identifies ownership and licensing – that isn’t the eStream server, or likely to be (nor is it currently the repository.  Yet.  But I’m working on it!)

I asked my “guest” (hostage?) what limitations, if any, faculty would like to place on access – would they wish to ensure that it was, in fact, only available to students within a specific module of X-stream or would they consider wider dissemination across the institution/sector?  As I rattled on it became clear, and quite understandably, that my hostage hadn’t thought about this in any great depth and indicated that they were questions to be discussed at faculty level…

Would they consider licensing for reuse under Creative Commons?  Er…what’s Creative Commons?

So, apologies to the hapless soul who just wanted to disseminate some video and found himself in my office being harangued about repositories, PowerLinks, OER, IPR and Creative Commons but this is exactly the type of interaction we need to be having with colleagues across the institution who have their own specific requirements for disseminating digital teaching and learning materials and from where we can start building cultural change for ukoer from the ground up.

Musing about metadata for OER

(Disclaimer: I am not a qualified librarian or cataloguer.)

Thus far I’ve only really considered, in detail,  the minutiae of research specific metadata (a consequence of the ongoing project to repurpose an LO repository as an OA archive of research).  However, this morning I uploaded my first learning object to intraLibrary that has been specifically designated as an OER for the Unicycle project.  The resource itself isn’t terribly exciting in that it is just a Word.doc but it makes sense to start with a relatively simple object than a more exotic file type or package.

The metadata template I’m using is taken directly from JORUM without any modification and is consequently (currently at least) based on IEEE LOM though it’s worth restating that we’ve recently learned that JORUM will be using DSpace to serve OER rather than intraLibrary so that service’s template is almost certain to change considerably in the very near future.

Mandatory fields:

Title
Description(s)
Keyword(s)
Contributor(s): Author(s)
Contribution Date
Payment Required (yes/no)
Subject to Copyright (yes/no)
Statement of Copyright and Restriction

Recommended Fields:

Version
Status
IMS LRM Metadata Identifier
Role of Metadata Contributor
Metadata Contributor(s)
Date of Metadata Contribution
Language of Metadata Record
Technical Format
Location of Resource
Language of Intended User
Type of Resource
Intended for Use In
Level of Difficulty

Optional Fields:

Description of Contribution Date
Module Code
Module Title
IMS LRM Metadata Identifier
Catalogue
Description of Metadata Contribution Date
Format of Metadata Record
Size Resource in Bytes
Type of Delivery System
Name of Delivery System
Minimum Version of Delivery System
Maximum Version of Delivery System
How to Install This Resource
Special Requirements for Use
Duration of Media Resource: Playing Time
Type of Interactivity
Educational Purpose Description
Language of Intended User
Level of Interactivity
Semantic Density
Intended for Use By
Completion Time
CLA Reporting Data

In addition, the resource is classified against JACS (Joint Academic Coding System) – again emulating the current (intraLibrary) JORUM configuration and can be ascribed one of the six Creative Commons attribution licences.

So off I went.

Title is straightforward, and Description – though this field does require some thought to make it useful – but what about Keyword(s)? My first thought is that we need some sort of controlled vocabulary – for research material I am using Library of Congress Authorities which is well established practice for this type of material but perhaps less appropriate for learning objects; one could rely on author produced keywords but these are perhaps not easily generated as formal metadata and will tend to lack consistency (social tagging is perhaps a slightly different issue and intraLibrary does have a facility for ascribing user-generated tags after the resource has been published.)

I posted my idle musings to Twitter and was immediately called to account by @philbarker and @LornaMCampbell who both asked what specific aspects of the learning object the controlled vocab would need to describe. @ambrouk acknowledged it was a big question and suggested two separate criteria: a) subject classification b) everything else author might tell you about / user says they want?

Input also came from @lynncorrigan and @KavuBob who pointed me to the HILT (High Level Thesaurus) project at Strathclyde – http://hilt.cdlr.strath.ac.uk/hilt4/demonstrators.html

I haven’t yet looked closely at this project but from the Twitter response it’s clearly an area that needs further research so this is a quick post to further the discussion…I’ll come back when I’ve explored the issue in more detail and all perspectives in the meantime gratefully received.

Some final unstructured thoughts at this stage:

• The need for a lightweight metadata template – which I guess the mandatory subset is though even this requires Keyword(s) AND classification against JACS…AND social tags can also be applied.  To what extent the recommended/optional fields need to be completed depends to some extent on the type of resource though I suspect that some of these fields will actually need to be mandatory for certain resource types – Duration of Media Resource: Playing time for example
• How the metadata relates to resource discovery on the modern web – metadata is ultimately to aid resource discovery (and nail down copyright and licencing).  Where will our OERs be primarily discovered from?  A Leeds Met interface/a JORUM interface/Google/All of the above/somewhere else?
• Workflows – who uploads resources and applies metadata?  The creator/repository administrator?  Does there perhaps need to be a multiple stage workflow utilising something like the recently released JORUM quick deposit tool (ideally based on SWORD) whereby metadata is subsequently enriched by trained staff?

Using the search interface (or interfaces) to search the repository for different types of content.

The search interface – http://repository.leedsmet.ac.uk/main/index.php – is now returning results in a manner appropriate to published, peer reviewed research papers which is fine as far as it goes but what about other types of content that we may want to expose externally?  I was already dimly aware of the issue with respect to conference papers, for example, which will require slightly different metadata within intraLibrary and which will then need to be formatted appropriately when returned by the search interface.  However, the issue was thrown into relief at a preliminary meeting yesterday to discuss using the repository for heritage photographs and other digitised content from the library archives and special collections which will require entirely different metadata.

After the meeting I promptly defined a new collection and uploaded a photo with minimal metadata – just title and description, not even bothering with classification at this stage, I’ve also exposed the collection to external search so it is being returned by the search interface which is obviously trying to format according to Mike’s research metadata template which is frankly gobbledegook.

So…I need to establish whether we can identify different types of content (probably by collection or by an appropriate metadata field) such that, say, the search interface ONLY returns research papers, then if photos are in their own collection can we filter out that collection so that it will not be returned by http://repository.leedsmet.ac.uk/main/index.php at all i.e they won’t be returned by any keywords in the metadata etc? Then we could, say, implement a second interface configured to search the ‘Heritage photos’ collection only and return results in an appropriate format i.e it would not return any research results as those collections would be filtered out?

OR might we want to search the whole repository from a single interface and could we perhaps apply different templates to different types of resource from a common interface? (My initial reaction is that separate interfaces would be better.)

So I’m hoping Mike will tell me this is dead easy and not impossible!

Organisational structure, metadata and resource discovery

In terms of the organisational structure and metadata for our repository we must consider that:

• Resources must be discoverable both internally (i.e. within intraLibrary itself) and, where appropriate, by external systems e.g. search engines

• Visitors to the repository must be able to browse repository content in an intuitive manner.

These requirements are related and can be fully realised by integrating a number of features of the software:

1. Groups/Processes
2. Collections
3. Application profiles (Metadata schema)
4. Taxonomy (or taxonomies)

Groups/Processes

intraLibrary uses IEEE LOM (Learning Object Metadata); the administrator can define multiple application profiles (metadata schema) and templates which can incorporate subsets of LOM that may be differentially applied to groups and collections based on content type.

We currently have two groups/processes defined (we may well need more):

• ‘Default – Upload and Catalogue’ is for research materials and uses an appropriate application profile  that is based on Dublin Core – though strictly speaking it is a subset of LOM mapped as closely as possible to unqualified DC (plus some bibliographical citation info that Intrallect have included in v3.0) (see below for further info).

• ‘Learning Object Contributors – Upload’ uses a different application profile appropriate to the respective types of resource.

Collections

Collections in intraLibrary serve several purposes:

• It is the means by which the administrator defines whether or not resources are discoverable by external systems or whether they can only be discovered by an authenticated user of the Leeds Met Repository.  The first scenario will be necessary for Open Access research material; the second scenario is likely to be necessary for some Learning Objects (though we may also want some LOs to be searchable and discoverable externally.)

• It was agreed at the last consultancy group meeting that the main organisational structure should not be based on Leeds Met faculties; however, it is still useful to be able to group (and browse) content in this way which can be achieved by the use of collections which can easily be renamed in the event of faculty name change. Moreover, resources can be stored in multiple collections and easily be moved between collections.

A user decides which group/process and which collection (or collections) they want to upload to as part of the workflow:

Collections are currently configured so that resources in the “Learning Object” collection will not be searchable by external systems whereas resources in the faculty collections will (to facilitate Open Acccess)

Metadata for Research material

Based on current practice, the most appropriate metadata schema for Open Access research material is Dublin Core which can be mapped with IEEE LOM.

Dublin Core	IEEE LOM equivalent
Title	Title
Description	Description
Subject	Keyword/Classification
Creator	Contributor
Contributor	Contributor
Publisher	Contributor
Format	Technical Format
Identifier	LOM Identifier/Location of Resource
Type	Type of Resource
Rights	Statement of Copyright and Restrictions
Coverage	Geographic / Time Period Coverage
Relation	Related Resource Description
Date	Date of Contribution
Language	Language of Resource

IEEE LOM permits several fields to be duplicated; this is necessary, for example, to accommodate the Dublin Core fields ‘contributor’; ’publisher’; ’format’ in multiple instances of the LOM field ‘contributor’.

intraLibrary V3.0 also incorporates Bibliographic citation metadata:

Metadata Field

bibliographicCitation

genre

title

volume

issue

date

spage

epage

NB. No field for ISSN – can be accommodated in a duplicate ‘description’ field.

Metadata and the search interface

The search interface is currently configured to return results according to a default template and returns only a subset of available metadata: Title; Description; Creator; Contributor; Publisher; Type; Subject; Copyright:

The metadata that is returned can be extended and we will wish to modify the way in which the information is presented and formatted, as standard Harvard style references for example. Mike T is currently working on this and there are one or two issues with respect to standardising the meta-data template and identifying and formatting the correct fields from the returned XML – as I understand it the SRU is currently configured to pick up dc and Mike is investigating whether it could pick up the lom instead which is more detailed – more on this soon!

NB.  Bib cite metadata is not yet searchable by SRU – Intrallect aim to incorporate this, though not before Summer 2009.

Organisational structure

The organisational structure, of course, is in many ways auxiliary to more powerful methods of resource discovery which utilise the full metadata record. Nevertheless it is still important to establish an intuitive system that enables users to browse and that can be used to easily present repository content for demonstration and promotional purposes.

• Review of other repositories of research content suggests that Library of Congress Classification (LCC) might be appropriate for our needs. The full system is complex with many more levels of specificity than we require and it is proposed that we use the top two levels of the classification only; we will also have the flexibility to extend the classification if necessary.

• The Joint Academic Coding System (JACS) subject hierarchy is generally used by UK institutions to identify the subject matter of programmes and modules which potentially makes it more suitable for Learning Objects – it is the system used by the national Learning Object repository JORUM for example.

• Resources in intraLibrary may be categorised against multiple classifications and we may wish to add other classification systems in the future e.g. Medical Subject Headings (MESH)

Incorporating browse functionality into the search interface

Users will not generally browse the research collection from within intraLibrary itself but from the external search interface. We will want to incorporate browse functionality into the interface to browse by subject or by faculty (the use of faculty ‘collections’ as discussed above easily facilitates this).

This functionality is partially integrated but will require further technical development:

I’ve got the post festival, metadata schema, taxonomical blues

I have to say that I really enjoyed the Staff Development Festival.  It got me away from my PC, interracting with folk from all over the University face to face and I can catagorically say that the current generation of social networking tools don’t even come close to this more traditional form of interraction!  The permenant stand in the marquee gave us a presence throughout the fortnight and I’ve had the opportunity to speak with a wide range of people from different faculties.  There was, however, variable interest from day to day with the Research Day, as one might expect, being the busiest but I was a little disappointed with a comparative lack of interest on the Carnegie Research Institute Day.

I’ve been given some full text papers to deposit and will follow up on contacts made to secure more still; a lot of interest also in a repository of Learning Objects and we should be able to get some good quality LO content over the next few weeks.

It was very useful also to get to know colleagues from the University Research Office in a less formal setting – previous contact has mainly been in meetings or via email.  Our stands were adjacent (for synergy!) and Babita has agreed to join me in advocacy presentations to faculty staff over the coming months which I think will be extremely useful in helping to get our message accross – and B is, no doubt, more familiar than I with the bureaucratic idiosyncrasies of the Leeds Met research community.

It’s now of pressing importance that metadata schema and taxonomical structure are stable so that we can start uploading content without undue fear of it being dislodged.  Unsurprisingly the academic in the street has not expressed a particularly strong view and this comes very much under a librarian’s remit – Wendy and I will sit down next week with two colleagues and I’m fairly sure we’ll be looking at Library of Congress Subject Headings as the main organisational structure; I’ve already added a skeleton taxonomy based on the top level of LoCSH which is now sitting alongside JACS and Leeds Met faculties (N.B. one of the features of the node based classification in intraLibrary is that an object can be classified under multiple taxonomies)

There are also work flow issues to consider and you would, perhaps, want a professional librarian/cataloguer to ensure consistency of classification, especially under the LoCSH so may be we’d ask an academic to classify just under faculty and then send the object to a librarian’s workflow for more accurate classification under LoCSH before it is published to the library.

And then there is the manner in which I am currently using intraLibrary’s collections for content by faculty – I originally adopted this approach as Mike T suggested it would be the easiest way facilitate a demo browse tree in his modification of the search interface but we now need to decide whether it would be more appropriate for faculty to go in a metadata field – probably not; it’s not a simple DC field that would be much use for external system searching and using collections in this way probably means we could lose the faculty classification hierarchy altogether and facilitate a more transparent workflow (using collections) to ensure objects are easily identifiable by faculty which is only really useful to us in any case.

In outline then, MIGHT it look like this:

The only taxonomy in intraLibrary is LoCSH; collections stay as they are now, one for each faculty and one for ALL Learning Objects (i.e. they go in one collection and are not distinguishable by faculty)

When an academic uploads a research paper (a challenge all in itself!) they need to specify a collection (i.e. a faculty) as part of the workflow, enter very basic metadata (title, author[s]) and upload; they DON’T classify – it is then passed to a librarian who augments metadata appropriately and classifies it under LoCSH before publishing it to the library.  (N.B. what if faculty names change and these collections are set in stone?)

When someone uploads a Learning Object they need to specify the Learning Object collection as part of the workflow, enter very basic metadata (title, author[s]) and upload; they DON’T classify – it is then passed to a librarian who augments metadata appropriately and classifies it under LoCSH before publishing it to the library.

…all of this for the meeting next week.

Which repository: Learning Objects vs Open Access research

As previously referred to, there has been an amount of cross-project work with Streamline through which it has become apparent that the requirements of a Learning Object repository are potentially very different from those of a repository dedicated to Open Access to research (primarily due to the way in which the respective types of repository are searched) and that the software that has been reviewed (both Open Source and proprietary) tends to be specialised to one specific type of content (although the respective software developers themselves may disagree).

The issue (heavily informed by the work being undertaken by the Streamline team) has necessarily delayed the choice of software that will be used and the ideal is to choose the platform that is best suited to both projects as well as being extensible to an ever wider range of digital objects in the future.

I’m sure my colleagues from Streamline will correct me if necessary – bear with me, I’m still getting to grips with that project and am able to follow more of the discussion at each subsequent meeting (!) – but my understanding is that two of the aims of Streamline are to:

• develop a tool that will auto-generate standard metadata based on the documentation associated with multi-media LOs
• develop a repository search-interface that then uses that auto-generated metadata in a controlled way to provide targeted resource-discovery but that will also facilitate serendipitous discovery of resources in a way analogous to spotting an adjacent book on a library shelf.

The consensus from the Streamline team seems to be that the majority of the software we have looked at does not make adequate use of metadata (often painstakingly entered) using it only as a filter to refine a search after a brute-force Google type trawl through repository content and perhaps the metadata side of repositories dedicated to OA has been neglected as (as noted in a previous post) traffic tends to come in via the mighty Google (or similar) anyway; this is obviously not conducive to an LO repository that will be searched in a very different way – often from within an individual institution or small subset of institutions.

Which brings us to Google itself. I confess to not knowing a great deal about how Google actually works but it is my understanding that it does not pay much heed to metadata and just indexes everything – how this is then ranked is something of a mystery to me and I have heard it suggested that the success of the interface is actually based on it’s perceived efficacy at discovering pertinent resources in the top 10 or 20 hits rather than its actual ability to identify the most relevant resource all (or even some) of the time.

NB. I assume the OAI-PMH (Open Access Initiative on Metadata Harvesting) with which all OA archives are compliant has some beneficial effects on hit ranking than would be achieved through brute indexing of repository content in the normal course of things (note to self: must look again at the OAI-PMH tutorial.)

I am a very long way from being a metadata expert but I believe there are those who think that metadata as we traditionally understand it has had its day and that Web 2.0 technologies (social bookmarking, tagging et al) coupled with Google’s bulldozer approach will usher in a brave new world of resource discovery – there may indeed be some truth in that though the librarian in me, and a little historical perspective, suggest that they will rather complement the existing models.

And anyway, at this stage, the burning issue is STILL “Which repository?” – IR day (as I call it) is now scheduled for April 16th!