Frequently Asked Questions about the DRIVER Guidelines
My institution's repository is compliant with the Guidelines and I have registered with DRIVER. What will happen now?
DRIVER will harvest the metadata from your repository and from repositories across Europe. This harvested data will be cleaned and used by DRIVER to provide the DRIVER Search. This data will also be available for use by other service providers to create new useful services.
The records in my institution's repository all link to the full text of the article which is free to access. However, some of these articles are not stored on my institution's server. For example when an academic joins my institution, records of their previous publications are added to our repository and linked to the file still held on their old institution's repository and server. Will this cause any difficulty for DRIVER in harvesting from my repository?
No this will not cause a problem for DRIVER. DRIVER searches for a URL in the metadata record that links to the document. There are no specific constraints regarding the URL as long as it is valid.
The Advice on implementing the DRIVER Guidelines says "Do not place any URLs in any element other than dc:identifier". A large number of our records have to have another URL, because the publisher requires a link to their published version.
How do we deal with this and still meet the Guidelines?
One way to deal with this issue is to have two dc:identifiers:
- One with the link to the local copy stored in the local system.
- One with the link to the publishers site.
Of course within Dublin Core the user cannot really see the difference unless they look at specific elements of the URL. A better solution is required but at present this is the best option available.
Our repository contains only records that link to the entire document (full text) of materials held in our repository, i.e. no metadata only records. Our repository meets all the mandatory requirements of the Guidelines except that we do not implement metadata Sets for full text. Can our repository be harvested by DRIVER?
Yes! Sets are required to allow DRIVER (and indeed other service providers) to distinguish between records that link to full text and those that do not. If your repository contains only records that link to the full text then you do not need to implement the Sets requirements.
We have some embargoed papers in our repository and they will not be available direct from our repository until the embargo ends. Can our repository still be harvested by DRIVER?
Yes if Sets are implemented to allow records that link to the full text to be distinguished from those that do not for example, embargoed papers.
Another possible approach is to use the Leiden Tool, which was developed by the University of Leiden for their DSpace repository and allows embargoed papers to be 'hidden' until the embargo expires.
We include a link (or information) so that readers may request a copy of the embargoed article from the author under Fair Dealing/Fair Use. Do we still need to implement Sets?
Sets will be required. At present this is a difficult question because
some repository software does offer features to support this function.
However, until there is an agreed approach to the distribution of embargoed
papers this is the best solution available.
How can we create a DRIVER Set in DSpace to exclude material that is restricted access, from being harvested?
A small Java program was developed by the University Library in Utrecht
which populates a dedicated harvesting community or collection which is
used by Narcis (formerly DareNet). This program runs at a convenient time
(usually during a quiet period, for example at 11.00pm) and every evening
it does the following:
a. Deletes all items in the collection
b. Maps all items from all required collections into the Dare collection
c. Ensures that items 'under embargo' are excluded from the Dare collection
d. Sends an email with the results to the team managing the repository
For administrative purposes Utrecht added a new table to DSpace to indicate for each collection if it is part of the Dare collection. This table is used by the program to know which collections to pick up items from. By doing so there is no need to modify the program-code if new collections are created.
By using the automated DSpace mapping structure, the Dare collection is easily manipulated without touching the owning collection. The advantage for the owning collections is that it becomes visible that an item is also mapped to the Dare collection and is thus harvested and available at Narcis or to DRIVER in the future. In the OAI it is also noted that the item is used in multiple sets (collections) giving some additional (grouping) options to the service provider.
This program and the set up by Utrecht are currently looked at by the University of Minho for the implementation of the DRIVER Guidelines and it will serve as a very useful starting point from which to develop a tool to serve the particular needs of the University of Minho and other repositories in Portugal.
With regard to author identification, could you give me more information on Driver's advances relative to the concept of "dai"?
The DAI is a national number that identifies scientific authors. The Registration agency differs for each country. For example in the Netherlands it is the Dutch department of OCLC, for historical reasons. In Belgium this is the Ministry of EWI.
With regard to subject classification, what are DRIVER's recommendations?
Our latest recommendation is to use any subject classification. However, terms or codes used in the classification MUST be "URI-fied" by an authoritative namespace in order for service providers to recognise the classification scheme. Service providers can use this to translate classification codes into English terms for example, or translate terms to other languages.
How does Driver retrieve OAI sets?
In an OAI-PMH response each OAI record provides "Header" information and in this "Header" the sets are specified. DIRVER uses this set information as "Provenance" information. A classification can also be made based on sets. The main use of sets in DRIVER is focussing on Open Access full text documents. So a "DRIVER"-set is mandatory if the repository contains a mix of Closed and Open Access documents.
If we are working towards adapting our crosswalk for DRIVER's harvesting, is it better to base our typology on the Bibliographic Ontology Specifications?
Recently we have found out that the Bibliontology describes Reference-Types. In DRIVER we focus on Publication Types, which basically is scientific output material. The Publication Type vocabulary of DRIVER is a carefully selected list of terms that are not too abstract that the differences between scientific expressions disappear and not too detailed so that terms fit to only one country. The "Publication" type vocabulary is able to fit must of the European scientific material that is used in scholarly communication. This list is made with interoperability and ease of implementation in mind.
What language codes does DRIVER use?
The new norm is ISO 639.3. DRIVER accepts all ISO 639.x language codes. It uses a synonym list to translate from one code to another. The most important message is to use an ISO 639 controlled vocabulary. The most noteworthy thing of the DRIVER Guidelines is that one does not need to URI-fy the language code.
With regard to citation, data relative to citation are in different fields (volume, year etc). Do we have to group these data in one field in order for DRIVER to retrieve them?
We only recommend to enter citation information in the dc:source field, preferably in the APA reference list style. However for the next version we also have recommendations for MODS Metadata format where these expressions are possible.
Is the Boolean operator a permanent feature?
It is under consideration for a variety of reasons but it is likely to change in the future.
If you cannot find the answer to your question please contact the DRIVER Helpdesk
Last updated: 04-Feb-2010