In May 2006, the Joint Information Systems Committee (JISC)  approached UKOLN  and the Eduserv Foundation  to collaborate on the development of a metadata specification for describing eprints (alternatively referred to as scholarly works, research papers or scholarly research texts) . A Dublin Core (DC)  application profile was chosen as the basis of the specification given the widespread use of DC in existing repositories, the flexibility and extensibility of the DCMI Abstract Model  and its compatibility with the Semantic Web . The main driver for this work was the establishment of a three-year project to aggregate content from repositories and offer cross-searching and other added-value services . Drawing on the conclusions of the ePrints-UK Project  and the findings of the ongoing PerX Project , JISC was quick to identify that the quality and consistency of metadata would be a critical success factor for this project.
The work was carried out over a three-month period from May to July 2006, before moving in early August into what we have termed our community acceptance period. A working group of invited experts was assembled to contribute to the development of the application profile both in person and through an active email discussion list and the project deliverables were developed in the open, collaborative arena of the UKOLN Repositories Research Team wiki . The core deliverables were a functional requirements specification, the application model, application profile and usage guidelines, eprints XML schema and 'dumb-down' guidelines. The ensuing article offers a whistle-stop tour of the development process that led to the production of these deliverables and the application profile as a whole.
Identifying the functionality that we need to support is an important first step if the profile is going to be fit for its primary purpose. Current practice for repositories is to expose simple DC records over OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting)  as mandated by that protocol. However, it is widely agreed that simple DC has limitations that pose problems for repository developers and aggregator services. Issues relating to normalised names, use of controlled subject vocabularies or other authority lists, dates and identifiers are common and many were identified in the course of our functional requirements gathering.
From the work specification supplied by JISC, we defined our primary use case in developing an application profile for scholarly works as: supporting the Intute repository search project to aggregate richer, more consistent, metadata from repositories. Through liaison with that project, a review of existing standards and previous project findings, plus consultation with our working group, we established a set of scenarios from which we derived an extensive list of functional requirements . Principal amongst these were the following:
Note that by 'open access' we mean "free availability on the public internet, permitting any users to read, download, copy, distribute, print, search, or link to the full texts of these articles, crawl them for indexing, pass them as data to software, or use them for any other lawful purpose, without financial, legal, or technical barriers other than those inseparable from gaining access to the internet itself." 
In order to build up a DC application profile for scholarly publications we first need to develop an application model. This model shows the entities that we want to describe in DC and the key relationships between those entities. It is critical to undertake this modelling step in the development of any application profile. Without it, users of the application profile may become confused about which entity is being described by any given metadata property.
As a simple example, imagine developing an application profile to describe a personal audio CD collection. One might choose to model the following set of entities: the collection and its owner, each CD, the recording artist and the record label. Each of these entities could then be described separately, using a specific set of properties for each entity. We refer to such a model as the application model.
The application model for scholarly publications presented here  is based on the Functional Requirements for Bibliographic Records (FRBR) [17. FRBR is an entity-relationship model developed by the library community for the entities that bibliographic records are intended to describe. FRBR models the bibliographic world using four key entities: work, expression, manifestation and item. This article does not attempt to summarise the FRBR model in any detail. Readers that are not familiar with it are encouraged to consult the FRBR documentation .
In the context of this model an eprint is defined to be a scientific or scholarlyresearch text (as defined by the Budapest Open Access Initiative ), for example a peer-reviewed journal article, a preprint, a working paper, a thesis, a book chapter, a report, etc.
Although FRBR is used as the basis of the model, some of the entity and relationship labels used in FRBR have been modified for this model, in order to make them more intuitive to those dealing with eprints and to align them with the terminology used in DC:
|isExpressedAs relationship||'is realized through'|
|isManifestedAs relationship||'is embodied in'|
|isAvailableAs relationship||'is exemplified by'|
|isCreatedBy relationship||'is created by'|
|isPublishedBy relationship||'publisher' attribute of a Manifestation|
A ScholarlyWork is a distinct intellectual or artistic scholarly creation.
The isExpressedAs, isManifestedAs and isAvailableAs relationships can be thought of as 'vertical' relations between the ScholarlyWork and its Expressions, between an Expression and its Manifestation and between a Manifestation and its Copies. There are also 'horizontal' relationships between different Expressions of the same ScholarlyWork (e.g. the 'has a translation' relationship in FRBR), different Manifestations of the same Expression (e.g. the 'has an alternative' relationship in FRBR) and so on. These 'horizontal' relationships have not been included in this model. Software applications may be able to infer some of these 'horizontal' relationships by navigating up and down the 'vertical' relationships.
In natural language, what the above model says is:
A ScholarlyWork may be expressed as one or more Expressions. Each Expression may be manifested as one or more Manifestations. Each Manifestation may be made available as one or more Copies. Each ScholarlyWork may have one or more creators, funders and supervisors. Each Expression may be have one or more editors. Each Manifestation may have one or more publishers.
The most common forms of Expression of an eprint are the various 'revisions' that it goes through (draft, pre-print, ..., final published version, etc.) and its different translations. Therefore, the most important Expression to Expression relationships required are isVersionOf/hasVersion and isTranslationOf/hasTranslation.
A critical part of developing the application model is to identify the key attributes that will be used to describe each entity in the model. Initially, this can be done in a fairly generic way, noting for example that we want to capture the 'title' of the ScholarlyWork but not worrying about whether we are going to use DC Title or some other kind of title. The key attributes for each of the entities in our application profile are listed below.
Attributes of a ScholarlyWork
Attributes of an Expression
Attributes of a Manifestation
Attributes of a Copy
Attributes of an Agent
Many of the above relationships and attributes can be implemented fairly easily using metadata terms already defined by the Dublin Core Metadata Initiative (DCMI) . DC metadata is sometimes only considered capable of describing flat, single-entity, constructs - a Web page, a document, an image, etc. However, the DCMI Abstract Model  introduces the notion of a description set, a group of related descriptions, which allows it to be used to capture metadata about more complex sets of entities, using application models like the one described here.
DCMI is currently developing a revised set of encoding guidelines for XML and RDF/XML, which will allow these more complex, multi-description, description set constructs to be encoded and shared between software applications.
The application profile provides a way of describing the attributes and relationships of each of the five entities as part of a description set. The profile also identifies mandatory elements, provides usage guidelines and offers illustrative examples. Note that for this application profile, we have made very few elements mandatory. Indeed, all that a minimal description set must include is either:
All other aspects of the application profile are optional.
It is not the intention of this article to offer a full analysis of the different metadata properties and readers should refer to the documentation for further information . Briefly, the profile makes use of properties from a number of schemes: the DC Metadata Element Set (simple DC) , DC Metadata Terms (includes qualified DC terms)  and the MARC relator codes  all provide terms. Properties from the Friends of a Friend (FOAF) Scheme  introduce some semantic web flavour and only five new properties have been created from scratch: grant number, affiliated institution, status, version and copyright holder.
Where existing dc:relation qualifiers have been used, the relationships being documented have been clearly defined alongside five new properties:
To aid fulfilment of several of the functional requirements further, four vocabularies have been defined for:
Figure 2 shows the resource type vocabulary as an extension of the value 'Text' in the DCMI Type scheme .
At the time of writing (January 2007), the DCMI does not define an XML format to support the serialisation of DC description sets as described by the DCMI Abstract Model (DCAM). The existing DCMI recommendation Guidelines for implementing Dublin Core in XML  pre-dated the development of the DCAM and is based on two simpler 'abstract models' for DC metadata which are described in that specification itself. The DCMI Architecture Community  is currently considering a working draft  that describes a new XML format which is based on the DCAM, with the intention of producing a new DCMI recommendation, probably in early/mid-2007.
Since the Eprints application profile makes use of the full range of features of the DCAM, the serialisation of description sets based on that application profile requires a format which supports those features, so the working group has defined an XML format known as Eprints DC XML . The format is based very closely on the latest drafts being considered by the DCMI Architecture Community, although it does make use of different XML Namespace Names from those used in the DCMI drafts.
Figure three shows an example instance of the Eprints DC XML format:
A W3C XML Schema and a RELAX NG  Schema for Eprints DC XML are available.
One of the requirements of the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) specification  is that, for each "item" in a repository, the repository must support the dissemination of metadata records in the "oai_dc" "metadata format". "oai_dc" is a format defined by the OAI-PMH specification to serialise "Simple DC" description sets. Simple DC is an application profile in which:
The Simple DC profile is used by many systems as a 'lowest common denominator' for basic interoperability, and the process of transforming description sets based on some richer application profile into description sets based on the Simple DC profile is sometimes referred to as 'dumb-down', reflecting the fact that such a transformation involves a loss of information content. The working group provided a mapping from the Eprints application profile to the Simple DC application profile . Because a description set based on the Eprints application profile typically contains multiple descriptions, each of a single resource, the mapping generates multiple Simple DC description sets from a single Eprints application profile description set.
In the proposed mapping, the resulting Simple DC description sets describe the eprint only at the ScholarlyWork and Copy levels. The Simple DC description set for the ScholarlyWork complies with the guidelines specified by the ePrints-UK Project . This is not the only possible approach to mapping the Eprints application profile to Simple DC. For example, it would also be possible to map to a group of Simple DC description sets, one for each entity in the model or to a single Simple DC description set only about the ScholarlyWork. However, the working group felt that the chosen mapping offered the most useful set of simple DC descriptions with minimal loss of information.
This application profile represents a relatively innovative approach to metadata, taking as it does the FRBR model and applying it to scholarly works. By making use of the benefits afforded by the DCMI Abstract Model, the profile is able to group descriptions of multiple entities into a single description set. Overall this approach is guided by the functional requirements identified above and the primary use case of richer, more functional, metadata. It also makes it easier to rationalise 'traditional' citations between 'expressions' and 'modern' hypertext links between 'copies', as well as supporting navigation between different versions and the identification of appropriate, and, we hope, open access, full-text copies. In practice, this seemingly complex model may be manifest in relatively simple metadata and/or end-user interfaces. Furthermore, it is likely that many repositories already capture the metadata properties identified in the profile, but are prevented from usefully exposing this metadata to other services by the limitations imposed by simple DC.
Yet the application profile alone cannot bring about interoperability or provide Intute and other aggregators with the metadata necessary to offer rich functionality. For this we need community uptake by repositories and repository software developers, agreement on common approaches and most of all, Eprints DC XML metadata being generated and exposed. There are growing signs that our community acceptance and dissemination activities to date are generating momentum, with support built into the newly released GNU Eprints version 3, alongside statements of support from DSpace and Fedora  developers, interest from European colleagues and lively discussions at the recent DC - 2006 and Open Scholarship 2006 conferences in Mexico and Glasgow.