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.

Tagging repository items in del.icio.us — a test

After reading Everything is Miscellaneous I asked Peter Sefton if repository items could be tagged to del.icio.us etc and here is his testing out of the idea.

Thesis-specific metadata

Part of the SURF report (compare 6.5.1 on p. 47 with 6.2.3.2 on p. 40) recommends using thesis specific metadata schema — not as discrete schema themselves — but as guides to populating a more generic but highly granular metadata datastream.

The thesis specific metadata that we see used in these different schema are:

Recommended Australian digital thesis metadata

Since the ETD-2007 conference I have followed up several discussions with stakeholders in repositories and electronic theses in Asia, Europe and North America attempting to assess best practice for Australian repositories within the international context. Scholars are going to want to know what has been produced globally. The trick has been trying to assess how the balance between national requirements and future proofing for international interoperability can be best achieved.To date I have advised that the best we can do at the moment is to stick with a granular scheme like the MARCXML or MODS until the some clarity begins to emerge from the cloud of different ETD metadata schemas and current harvesting options and various consortia, national and international efforts to impose some order on the various types of theses emerges.

I’ve since read the report conducted by UK’s JISC, the National Library of Sweden and the SURFfoundation in the Netherlands. The report is of a pilot project that attempted to harvest repositories across 5 nations to evaluate issues of interoperability. So the following recommendations are the best I think that can be made for any Australian repository to save itself a lot of hassles in the future regarding the best exposure of their digital theses — they are made with the global picture in mind and with a view to what to reasonably expect in the short term.

Many of these recommendations are from literature cited within the report and not specified directly in the report itself:

A rationale for a standard national terms for resource types in repositories

Following are where my thoughts are currently at in attempting to understand a rationale for a national resource type vocabulary. Have all but given up looking for a Use Case rationale in the “out there” Harvesting/Googling environment, and have found something I think of more value down our institutional feet level. — Thanks to ongoing efforts and brain-picking this is what I’ve found. It’s about interoperability.

Migration between repositories can be a lot less of a hassle if the values for the resource types are in sync across the repositories.

This rationale opens up a different set of questions and guidelines for determining what a standard thesaurus should look like. If one is looking at migration issues between repositories in deciding on a standard thesaurus then the focus falls back, in part, on what is useful for the purposes of each institutional repository and how these can be carried across repository solutions. This question is not the central concern if one is looking at a standard for harvest/search needs – for which I have still to find a justifiable use case.

With the former case being the primary focus, one is probably interested in a longer (more granular) list than the latter. The former case also makes something like the RQF resource output types look more practical than with the latter. It also possibly means having a closer look at what is currently being used to ensure future interoperability.

There are also consequences for finding data entry “templates” for each resource type that can be carried across relatively seamlessly.

The migration issue also points to the value of a standard applying at the Australian national level.

Is there a Use Case for national resource type standard terminology in scholarly repositories?

The title is not rhetorical. I really would like to know. (I can’t think of a use case, but I don’t know if that is just me.)

A scholarly repository is not as diverse as a library collection. Libraries without question required standard “resource type” or GMD (general material designation) terms from the beginning. And when the technology embraced and declared obsolete the card catalogue, it built itself around that library standard (AACR).

The situation re scholarly repositories is different. They do not contain the diversity of types and definitions and potential confusion that libraries had to cater for. Scholarly community is a comparatively narrow one, it is a specialist area where stakeholders readily understand each other. It is not difficult an “article” in one repository to be understood as the equivalent of a “journal article” in another repository.

When Dublin Core fields are not repeatable (revised 15/7/07)

A standard rule of Dublin Core is that all its elements are repeatable and optional. (Also they can be in any order.)

But there are at least two instances in (Australian) repositories where this is not the case in practice:

Some Open Archive basics

This is a bare bones selection of points from the OAI tutorial. All dot and numbered points are taken from this tutorial.

Collections or Sets in repositories?

Some repositories are designed so that documents deposited must be assigned to a collection; some allow an editor to re-structure records in a repository into collections. Both pose some difficulties when one day the time comes to migrate the data into another repository. Migration may be very slow, batching one collection at a time; or migration might even cause critical metadata and collection relationships to be lost altogether.

Sets, however, can allow for the grouping or harvesting of defined selections of the repository (e.g. a particular subject, author, resource type, etc.) in a way that avoids the problem of Collections.