• Created by Unknown User (maurice), last modified by Unknown User (lisanne) on Wed 28 Jan 2009

Why use the DRIVER Guidelines?

The "DRIVER Guidelines for Content Providers: Exposing textual resources with OAI-PMH" will provide orientation for managers of new repositories to define their local data-management policies, for managers of existing repositories to take steps towards improved services and for developers of repository platforms to add supportive functionalities in future versions.

How to comply with the DRIVER Guidelines? (validation)

DRIVER offers to local repositories in the near future means to check the degree of conformance with the guidelines via web-interfaces. For the Validation of the 1.0 guidelines see: http://validator.driver.research-infrastructures.eu/ DRIVER also offers web-support (see below "Is there support?"). If the mandatory characteristics of the DRIVER Guidelines are met, a repository receives the status of being a validated DRIVER provider. If recommended characteristics are met, a repository receives the status of a future-proof DRIVER provider. Validated DRIVER repositories can re-use DRIVER data for the development of local services. They become part of the DRIVER network of content providers.

What if I don't comply?

Not conforming to all mandatory or recommended characteristics of the DRIVER Guidelines does not necessarily mean that contents of a repository will not be harvested or aggregated by DRIVER. But, depending on the specific services offered through the DRIVER infrastructure, contents of these repositories might simply not be retrievable. A search service, for example, that promises to list only records that provide a full-text link cannot process all contents of a repository that offers metadata-only records or obscures full-texts by authorization procedures. The DRIVER Guidelines shall help to differentiate between those records. The DRIVER Guidelines will, of course, not prescribe which records should be held in a local repository.

Is there support?

DRIVER offers support to local repositories to implement the DRIVER Guidelines on an individual basis. Support can be delivered through the internet DRIVER Support website: http://www.driver-support.eu or can be personal See document "Advice for implementation of the DRIVER guidelines",
www.driver-support.eu/documents/Advice_for_implementation_of_the_DRIVER_guidelines.pdf. DRIVER is committed to any possible solution that can be realised by central data-processing. But the sustainable, transparent and scalable road to improved services goes through the local repositories.

Scope of the DRIVER Guidelines

Are the DRIVER Guidelines a standard?

No. Although the use of standards like OAI-PMH certainly does provide a solid base to build a network like DRIVER, there is a need for additional DRIVER Guidelines. The main reason is that the standards still leave room for local interpretation and local implementation. Without that, a standard could not exist. But this openness becomes a hurdle to achieve high quality services when different implementations are combined.

Are the DRIVER Guidelines the same as cataloguing rules?

No. The guidelines are an instrument to map (or translate) the metadata used in the repository to the Dublin Core metadata as harvested by DRIVER. They are not meant to be used as data entry instructions for metadata input in your repository system.

Do the DRIVER Guidelines contain scientific quality level instructions?

No. The guidelines do not tell you what resources have the required quality level for the scientific content and which ones do not. We assume that this distinction has already been made at the repository's institutional level. In other words, we assume that the quality of the resources exposed through harvesting is good enough.

What are the main components of the DRIVER Guidelines?

The DRIVER Guidelines basically focus on five issues: collections, metadata, implementation of OAI-PMH, best practices and vocabularies and semantics.

  • With respect to collections within the repository the use of "sets" that define collections of open full-text is mandatory. If all resources in the repository are textual, include not only metadata but also full-text and all resources are accessible without authorization, the use of sets is optional.
  • With respect to the OAI-PMH protocol some mandatory and some recommended characteristics have been defined in order to rule out problems arising from the different implementations in the local repository.
  • With respect to metadata some mandatory and some recommended characteristics have been defined in order to rule out semantic shortcomings arising from heterogeneous interpretations of DUBLIN CORE.

Who stands behind the DRIVER Guidelines?

The DRIVER Guidelines have been compiled by people who have years of experience with the construction and maintenance of similar networks of interlinked repositories such as HAL in France, DARE in the Netherlands, DINI in Germany, SHERPA in the UK and they involve expertise from experienced service providers such as BASE and community organizations such as the OAI Best-Practice group.

What do you mean with textual resources?

In this phase of DRIVER we focus on textual resources. As working definitions we use the following:

  • A textual resource: scientific articles, doctoral theses, working papers, e-books and similar output of scientific research activities
  • Open Access: access without any form of payment, licensing, access control with password etc, technical access control with IP etc

Many repositories are used to depositing different types of resources, for example, articles, e-books, photographs, video, datasets and learning materials. These resources have metadata records that describe them. Usually the resources are in a digital form (but not always) and these digital files are usually stored within a database that is part of the repository system (but not always). Access to the resources is usually open (but not always).Within DRIVER we focus on a subset of the vast domain of resources in European repositories: we focus on textual resources in digital form that are open access.

Research shows that in doing this we will cover more than 80% of all available resources. For this reason the first mandatory guideline of Part A states: "the repository contains digital textual resources". This doesn't mean that your repository might not include other materials and non-digital items also. The statement is an expression of the DRIVER focus on textual resources. A complete list of the textual resources is presented in element dc:type in the metadata guidelines in chapter "Use of Vocabularies and Semantics" section "Publication type". For the implementation in dc:type see chapter "Use of Metadata OAI_DC" section "Type". Or to map with currently known type mappings see section "DRIVER-TYPE Mappings" in the chapter "Use of Best Practices for OAI_DC".

What do you mean by "sets"?
Sets are a standard component of the OAI-PMH protocol and they are used to focus (filter) specific parts of a repository. When your repository contains also non-textual items, or non-digital items, or toll gate access items or metadata only items, you can use the "set" mechanism to filter out these items when offering your content to DRIVER.

Further Resources

What else should I consider?

Existing resources have been used as input for these DRIVER Guidelines and much care has been taken to avoid special solutions. In this way, one could say that the DRIVER Guidelines utilize practical experience and worldwide existing guidelines.

  • DRIVER is modelled after established and operational, distributed networks of content providers, particularly DARE in the Netherlands. The guidelines for DARE serve as a model for DRIVER. Rather than providing multiple references to guidelines scattered worldwide, DRIVER has initially made use of the DARE Guidelines and enhanced these guidelines by adopting best practises from repository managers and experts all over the European continent. The following documents have been an especially important starting point of, and essential to, the DRIVER Guidelines:
    • The document "USING SIMPLE DUBLIN CORE TO DESCRIBE EPRINTS", by Andy Powell, Michael Day and Peter Cliff of UKOLN, University of Bath (Version 1.2), which has been adapted for specific requirements by the DARE programme historically known as "DRIVER Use of Dublin Core" (Version 2, November 2006), has been extended in the DRIVER Guidelines 2.0 with the aid from repository managers - see chapter "Use of Metadata OAI_DC"
    • The Open Archives Initiative Protocol for Metadata Harvesting, Protocol version 2.0, which also has been adapted by DARE for specific requirements and is available as the "DRIVER use of OAI-PMH guidelines" (Version 2, December 2006) has been extended in the DRIVER Guidelines 2.0 with the aid from repository managers - see chapter "Use of OAI-PMH"
    • The DINI-Certificate "Document and Publication Services 2007" (Version 2, September 2006) http://www.dini.de/documents/dini-zertifikat2007-en.pdf provides a solid basis for what to consider when operating a repository. Since DRIVER looks at repositories from the perspective of an aggregator, the DRIVER Guidelines do not cover the aspects described in the DINI-Certificate that is designed for guiding the overall local operation of a repository. Instead, the DRIVER Guidelines are based on the assumption that the criteria of the DINI certificate are considered in the operation of a repository.
    • The document "Use of MODS for institutional repositories" https://www.surfgroepen.nl/sites/oai/metadata/Shared%20Documents/Use%20of%20MODS%20for%20institutional%20repositories-version%201.doc was created by the Metadata expert group of the SURFshare programme and used by the Dutch repositories. These guidelines provide a practical list of Publication types that ensures greater interoperability. The Publication types are based on the dc:type Publication list from the "DARE use of DC" document, combined with e-prints types and Publication types used in METIS in the wide spread Dutch Current Research Information System (CRIS).
    • The Version Identification Framework http://www.lse.ac.uk/library/vif/Framework/Essential/taxonomies.html delivered a simple and practical Version taxonomy http://www.lse.ac.uk/library/versions/ for journal articles and more. This formed an addition to describe the Publication types even better in the scholarly workflow.

Is there a working solution that solves many problems at once?

Yes, see chapter "Use of MPEG-21 DIDL (xml-container) - Compound object wrapping". Within the SURF DARE programme it has proven useful to implement an "XML-Container" for each resource that allows resource harvesting within OAI-PMH, provides an unambiguous link to the resource (not via a jump off page), supports full text indexing and enables the representation of complex documents consisting of several PDF files. The XML-Container is based on the Digital Item Declaration Language (MPEG21-DIDL) http://xml.coverpages.org/mpeg21-didl.html. Other solutions based on DIDL have also been developed (e.g. aDORe http://african.lanl.gov/aDORe/projects/adoreArchive/ , METS profiles http://www.loc.gov/standards/mets/mets-profiles.html ) and further to be published in the future (e.g. OAI-ORE http://www.openarchives.org/ore/ ).

  • No labels