Working towards an Open Library for Economics: The RePEc project </td><td>

1: The main user services

I list them by order of historical appearance.

BibEc& WoPEc
provide static html pages for all working papers that are only available in print (BibEc) and all papers that are available electronically (WoPEc). Both datasets use the same search engines. There are three search engines, a full-text WAIS engine, a fielded search engine based on the mySQL relational database and a ROADS fielded search engine. The mySQL database is also used for the control of the relational components in the RePEc dataset. BibEc and WoPEc are based at Manchester Computing in Japan and the United States.

EDIRC
provides a Web pages that represent the complete institutional information in RePEc.

IDEAS
provides an Excite index of static html pages that represent all Paper, Article and Software templates. This is by far the most popular RePEc user interface.

NEP: New Economics Papers
is set of reports on new additions of papers to RePEc. Each report is edited by subject specialists who receive information on all new additions and then filter out the papers that are relevant to the subject of the report. These subject specialists are PhD students and junior researchers. They work as volunteers. On 14 March 2000, there are 2753 different email addresses that subscribe to at least one list.

Tilburg University working papers & research memoranda
This site also operates a Z39.50 server for all downloadable papers in RePEc is available at dbiref.kub.nl:9997. The name of the database is "repref". The attribute set is Bib-1, and the record syntax supported are USmarc, SUTRS, GRS-1 (only string tags, tag type 3).

RuPEc
is a server in Russian. It offers search facilities to Russian users. Its maintainers also provide archival facilities for Russian contributors.

INOMICS
not only provides an index of RePEc data but also allows simultaneous searches in indexes of other Web pages related to Economics.

HoPEc
provides a personal registration service for authors and allows to search for personal data.

The "Tilburg University working papers & research memoranda" service is operated by a library-based group that has received funding from the European Union. INOMICS is operated by the Economics consultancy Berlecon Research. All the other user services are operated by junior academics.

2: The ReDIF metadata format

The ReDIF metadata format is inspired by Deutsch et alii commonly known as the IAFA templates. In particular it borrows the idea of clusters from the draft

There are certain classes of data elements, such as contact information, which occur every time an individual, group or organization needs to be described. Such data as names, telephone numbers, postal and email addresses etc. fall into this category. To avoid repeating these common elements explicitly in every template below, we define "clusters" which can then be referred to in a shorthand manner in the actual template definitions.
ReDIF takes a slightly different approach to clusters. A cluster is a group of fields that jointly describe a repeatable attribute of the resource. This is best understood by an example. A paper may have several authors. For each author we may have several fields that we are interested in, the name, email address, homepage etc. If we have several authors then we have several such groups of attributes. In addition each author may be affiliated with several institutions. Here each institution may be described by several attributes for its name, homepage etc. Thus a nested data structure is required. It is evident that this requirement is best served in a syntax that explicitly allows for it, such as XML. However in 1997--when ReDIF was designed--XML was not available. We are still convinced that the template syntax is more human readable and easier understood. However the computer can not find which attributes correspond to the same cluster unless some ordering is introduced. Therefore we proceed as follows. For each group of arguments that make up a cluster we specify one attribute as the "key" attribute. Whenever the key attribute appears a new cluster is supposed to begin. For example if the cluster describes a person then the name is the key. If an "author-email" appears without an "author-name" preceding it the parsing software aborts the processing of the template.

Note that the designation of key attributes is not a feature of ReDIF. It is a feature of the template syntax of ReDIF. It is only the syntax that makes nesting more involved. I do not think that this is an important shortcoming. Instead I believe that the nested structure involving the persons and organizations should not be included in the document templates. What should be done instead is to separate the personal information out of the document templates into separate person templates. This approach is discussed extensively in the main body of the paper.

The examples of Subsection 3.1 emphasizes that ReDIF is not just a format to encode preprints or other online publications. Of course it is suitable for that, but it objects of description is far broader. The ReDIF vocabulary as currently defined aims the output aspects of an academic discipline. These include the resources (digital or digitisable objects) that it creates, the creators of these resources as well as the institutions that support the creation process. ReDIF allows to describe things in the world that are important to the work of an academic discipline. We will use the word "item" to refer to any such things. ReDIF describes three classes of items: resources, bodies and collections. A "resource" is something that is digital or can be digitized. For example, a book is a resource. Resource templates include ReDIF-paper and ReDIF-article. A "body" is something that is neither digital nor can be digitized. Body templates include ReDIF-person and ReDIF-institution. A "collection" is something that has a manifold nature that makes it difficult to say if it is digitisable or not. ReDIF-archive and ReDIF-series belong to the collection category.

As far as version 1 of ReDIF is concerned, the grouping of record types is not important. The record type structure is in fact a flat finite list of templates types. This is the main limitation of the current version of ReDIF. It is hoped that the version 2 of ReDIF will object oriented. Record types will be classes. For example a preprint record type will be defined as subclass of a document record type. Thus commonities using ReDIF will be able to refine existing types as they wish. ReDIF records will be syntax independent. Version 2 of ReDIF is an important area of further research.

ReDIF is a metadata format that comes with tools to make it easy to use in a framework where the metadata is harvested. A file that is simply harvested from a computer system could contain any type of digital content. Therefore the harvested data must be parsed by a special software that filters the data. This task in accomplished by the rr.pm module written by Ivan V. Kurmanov. It parses ReDIF data and validates its syntax. For example, any date within ReDIF has to be of the ISO8601 form yyyy-mm-dd. A date like "14 Juillet 1789" would not be recognized by the ReDIF reading software and not passed on to application software that a service provider would use.

The rr.pm software uses a formal syntax specification redif.spec. This formal specification is itself encoded in a purpose-built format code-named spefor. Therefore it is possible for ReDIF-using commonities to change the syntax restrictions or even design a whole new ReDIF tag vocabulary metadata vocabulary from scratch.