Degree and qualification types in Australian universities/ed sector

For those of us looking for an authoritative list of degree and other educational qualification types in Australia there is The Australian Qualifications Framework Implementation Handbook (from the AQF site). See the handbook for detailed descriptions of the following and for any questions arising out of the following list which is taken from that handbook.

For best practice — uniformity and comprehensiveness of degree and qualification types across the Australian sector and confidence in the widespread recognition and “authority” of those names — I propose adopting the following list:

I still do like MODS

My recent post titled Criticisms of Mods was a response to encountering some pretty heavy criticisms of it at a recent conference. The criticism did take me by surprise, but there was at the same time a certain disconnect with a number of conference presentations that demonstrated that use of MODS was more widespread than I had realized. (I have discussed previously the Texas Digital Library’s use of MODS for its Thesis and Dissertation collection, and on another blog my own reasons for recommending its use where possible in repositories.)

I have since tried to find support for the specific criticisms without success. The technical issues seemed more strengths than weaknesses, as Jenn Riley has also helpfully explained re the name options in MODS.

My comments on the wide range of dates was meant not as a criticism but as another plus for MODS in the context of digital resources in repositories.

The Minerva project also recommends MODS (note especially slide #43) for a collection of digital resources. A Minerva MODS record for a web site can be seen here.

In support of the benefits of MODS already alluded to above, MODS elements seem particularly suited for the sorts of digital repositories I’ve been working with:

Reviewing non-text and literary resource types in the FRBR context

Updated 17th Sept 8:30 am AEST

I’m using this space to “think aloud” about the FRBR-based EPrints Application Profile in the context of reviewing the wide range of vocabularies used for the resource types across different repositories. The Eprints Type Vocabulary for the FRBR Work entity of Scholarly Text looks useful. But I’m using this space to think aloud about issues arising in thinking about vocabularies for resource types beyond the Scholarly Text.

(I’m sure others have done work on this and I’d greatly appreciate anyone who knows of this work to get in touch.)

FRBR and metadata decisions for repository users

At the recent DC-2007 conference I was introduced to the potential relevance of FRBR to the future of repositories.

Repositories 101 — Part 2 (For Users)

Since repository collections are generally run by librarians the librarian philosophy of “service for clients” rules.

Librarians take care in decisions about the decor of their reading rooms, how their shelves and computers are arranged, building signage and portal customizations, client service skills, policies for different types of users and different types of resources, how their materials are described and classified, vendor choices and workflows, etc etc — all for the purpose of improving service to clients.

It is the same with repositories. Librarians adapt their user-first philosophy to the different types of resources and different ways of handling resources in repositories.

Repositories 101– Part 1

Having been involved with a number of different repositories primarily for university scholarly works for a couple of years now I notice myself beginning to slip too easily into a foreign technical language, so decided it’s time I took a step back and share what I have come to understand about the basics of what such repositories are about and how they compare with traditional libraries.

This series of posts will be primarily for the benefit of those who have a background in academic libraries and who may be hearing about repositories and wondering how they may affect the practices and services they have become used to. It’s also intended to give librarians a tool to understand some of the “foreign technical language” repository managers and metadata people tend to slip into. (As I go through this series comments for clarification, correction, questions will be welcome.)

some criticisms of MODS

Although MODS has been widely adopted in metadata application profiles and as a schema in its own right as both a companion and alternative to MARC, MODS has had its critics. Some of these were raised in informal discussions at the recent DC-2007 Conference in Singapore; and some were repeated in ad lib comments on a metadata seminar from the podium. Some of these criticisms (with a few of my comments tossed in) are:

repository display, oai harvesters — omitting the document link from the oai-dc?

When checking out the potential clashes in cases where a repository portal display configuration is tied to the oai-dc datastream, one question that came to mind was the possibility of omitting the http link to an offsite document entirely from the oai-dc. That way, the oai-dc data provider could offer the repository’s metadata page as the dc.identifier without any messy entanglements with assigning a different dc value for a document according to its location (archived in the repository or offsite).

But that option also has significant drawbacks. We have to assume that Service Providers will be able to index and search records from the data provided in the oai-dc. This must inform any Data Provider’s (repository’s) decision about what to include in the oai-dc. And some SPs expect to be able to search full text — which means they will need to know the link to the document itself, whether that is in the dc.identifier or some other value such as the dc.relation.

how repository display configurations can clash with oai harvesters

The basic metadata supporting OAI harvesting is Simple Dublin Core. A data provider (repository) that intends to be compliant with the requirements of OAI harvesting will produce an unqualified DC datastream as a minimum requirement.

At least one repository solution, VTLS’s VITAL, is designed to use the simple DC data as the basis for the repository’s metadata splash page that contains the repository institution’s branding and is used to direct the user to the archived document that the user is requesting. (As far as I know at this point this is not an issue with open source repositories such as Eprints and Dspace.)

This means the repository is attempting to use a single datastream for two different purposes. That becomes a problem if the oai-dc data is constructed in a way that meets one purpose (e.g. the oai harvester), but that particular dc construct is not what we want for the other function (e.g. the portal display of the metadata page). That metadata display page with the link to the deposited document would be better linked to some other datastream — such as a MARC or MODS or VRA or anything OTHER than the OAI-DC data configuration.

This means that a repository manager must be very clear about exactly what it wants a service provider (SP) to display from its repository. For example, does one want the service provider to display the repository’s metadata splash page for each document, so that public users will be first directed to their metadata details for a particular record, where institutional branding also is prominent, and from there link to the full article or document? Or does one want to cut out one’s repository branding and descriptive metadata page and allow the SP to take a user directly to the article. What the SP will do will depend on how certain data is entered into the oai-dc datastream.

When an SP receives a request for a particular article in your repository, it will rely on the oai-dc record to “identify” that particular article. It thus looks for a dc.identifier value with a resolvable URI link.

This means that:

1. If the URI value in a dc.identifier is the link to the repository’s metadata page, complete with the full descriptive metadata record of the article, institution’s branding, and link to the full text of the document, then the SP will direct users to this repository page.
2. If, however, the URI value in the dc.identifier is the link directly to the article itself, possibly offline at, say, a publisher’s site, then the SP will bypass the repository metadata page and direct users directly to the article wherever it is located.
3. If there are dc.identifier values that are non-resolvable text strings such as an ISSN the SP will ignore these for this purpose.

Normally a repository can and will be configured so that documents deposited into it will generate in the oai-dc a dc.identifier value that is a handle or link to the repository metadata page first. 

But if the repository contains only a link to an offsite copy of the document, and if this is also entered into a dc.identifier field, the SP will direct users away from the repository to the off-site document. No problem, perhaps, for the self-effacing repository manager who wishes to serve the user more than the reputation of the institution supporting the repository, but not politically savvy if one of the very arguments presented to fund the repository in the first place was that it would increase the institution’s exposure to the world. That mediating branding page is normally pretty important.

There are two or three ways around this but each has drawbacks.

One can enter an offsite link to dc.relation instead of dc.identifier. This reserves the dc.identifier field for the repository default metadata page link — normally machine generated by the repository itself.

Another solution is to enter the offsite link into the dc.format so that it would look like this:

<dc.format>PDF http://www.offsitelink.com/name.pdf </dc.format>

Either of these solutions will cause a problem for the manager whose repository is dependent on mapping its portal display options from that same oai-dc record.

It will mean that a portal display link to a deposited record within the repository itself will be mapped from dc.identifier, while a portal display link to an offsite record will be mapped from dc.relation or dc.format.

So the consistency issue arises if one’s repository depends on mapping its display from the same data that is used for oai harvesting.

 An offsite link will have to be treated the same way for display purposes (same portal display label terms) as all other values entered in other dc.relation or dc.format fields.

That can cause headaches. One wants to show an onsite link and an offsite link to an article in a similar way for users. What is important to them is that they can see at a glance a constant way to get to the article regardless of where it is stored. One does not want to present an offsite link in a way that looks like it is not a link to the article described, but to some “relation” of it, for example. One can rename “relation” for the portal display, but it means that whatever display name is chosen for the display must be constant for all other display names mapped from that same dc.relation in the oai-dc field.

And whatever solution is decided upon will need to consider preservation and sustainability questions. One day the records will be migrated to some other software — what will happen to any such solutions then? What systems will ensure consistency over time within a repository, and what issues will arise in the broader world of databases needing to be able to talk to each other in the future?

Repository designs need to allow for record and metadata displays to be configured independently of the data used for oai harvesting.