ACIS Stage three requirements:	"Saskatoon paper"

Thomas Krichel and Ivan V. Kurmanov

This is the requirements document for stage 3 of ACIS. Its first draft was written when Ivan visited Thomas in Novosibirsk 2004-07-22 to 2004-07-28. His travel was funded by the Ford Foundation via its grant to the Socionet project.

To understand much of this document requires extensive background knowledge of the existing ACIS software, as well as its first running implementation in the RePEc Author Service (RAS). Since this background is not part of the formal requirements, we have moved the requirements to a Part 2 of the document, and start by general background in Part 2. Finally, there is Part 3 to this document that illustrates the time line of events.

Part 1: Background Material

Our experience with ACIS shows that academics are very eager to share their personal and research data. Many users write to us, asking about adding new documents to their research profiles. Some users feel frustrated because they expected to find this feature, looked for it everywhere, but did not find it.

While providing such facility seems to be an obvious way to meet the expectations of users, we have no plans to do so. In fact, doing this has been ruled out since the Montreal document. There are two reasons. First if every user is able to create new documents in ACIS documents database, this opens a door for a flood of low-quality and duplicate material. Second, there are tools and services for archiving documents, and there's no need to duplicate their functionality. Otherwise ACIS would become another Eprints or DSpace software. Therefore, in ACIS stage 3 we will be working to satisfy this users' need to express themselves by:

giving the users the ability to upload files with material that belongs to existing document records

introducing interoperability features into ACIS, which will make for a reasonable integration with document submission services

In other words, recall that ACIS is based on a collection of description of documents. Let us refer to this as the document stock. Users of ACIS will have no ability to add documents to the document stock. They have to go through an intermediary, called a

document archive, for that. To make this a smooth experience is a core part of this requirements document.

Some preparatory work for this integration has already been done in Stage 1. Ivan is about to finish implementation of what is called Automatic Research Profile Update (APRU) system for ACIS users. This is part of stage 1. APRU simplifies the life of users by periodically, automatically searching for their works in the document stock, which,

of course, is constantly being updated by contributions from document archives. If any new works of an author is found it will be added to the research profile automatically or suggested to him through email. The user chooses which option to follow.

(? not clear here if what follows is part of stage 1 or a requirement for stage 3?)

Now to simplify a user's life even further and to provide for better quality of the document metadata, we will promote use of personal identifiers in document metadata. If a document archive will uniquely identify the authors in the document descriptions, and the personal identifier can be found in the personal data maintained by ACIS such documents will be automatically included into those authors' profiles through APRU.

For that we need do two things:

increase visibility of the personal identifiers in ACIS

provide access to the latest registered authors data, including the identifiers

To complicate matters slightly, a discussion of identifiers in ACIS is required. There are, in fact, two types of identifiers in ACIS. First, there there is the identifier of the person. It combines an expression of the name of the person, in ASCII chars, with a date in the lifetime of the person. If the user does not give us a date, we use the date of registration. In each ACIS installation a prefix is added. For RePEc, the prefix is "RePEc:per:". Thus RePEc:per:1965-06-05:thomas_krichel is a typical identifier. This identifier is called the person handle. The person handle is an intelligent identifier. When looking at the identifier a human should be able to find the person in question. The use of the date means that the identifier is long-lived. The scheme can be used without any problem for several centuries, which is what we aim at in building personal identification. Thus intelligence and longevity are the attraction of this scheme. However, they also imply drawbacks to the scheme. First, some people object to their birthdays being made public. Second, if the name of the person changes, she may be tempted to change it. Third, the handle is long, and we know, from our experience with users, that they prefer short handles. As an aside, HoPEc, the precursor system did not show handles at all, since the dates buried in them were used as password.

These problem with the use of personal handles lead Ivan to construct an alternative scheme to refer to a person known as the "short-id". The short-id is formed by taking the first letters of the person's first and last name and append a counter to ensure uniqueness. This is a typically dumb identifier. It is short, but relies on a feature of ACIS and will not be of much use in future centuries when, ACIS is likely to be gone. While ACIS is around, it is safe to deploy short-ids. Strictly speaking, though, a short-id does not identify the person. Instead, it identifies the record in ACIS that describes the person.

Let us return to the discussion about how to integrate ACIS and document archives. When we talk about increasing the visibility of identifiers in ACIS we mean

increase the visibility of shot-ids to users

increase the visibility of short-id and handles to machines

Generally, all public data about registered authors in ACIS is exported in publicly accessible metadata files. A document archive has access to these data. But they may not be up to data. What we want is to support the case when somebody wants to access and use the most recent registered person data. That will create new interoperability possibility for ACIS. The integration with document submission services can both make users' life easier and provide for better metadata collected.

Imagine a scenario in which a user submits a document to a document archive. She enters the names of the document authors, which is a usual thing to do while submitting a document. The document archive can then search for personal records, whose names (or name variations) match to what the submitting user entered. If it finds any personal record that looks appropriate, the service might suggest it to the user, so that she helps identify the author precisely. Finally, such user will want to contact ACIS and find that the paper that she submitted to the document archive just a couple of minutes ago has been found by ACIS and has been claimed via ARPU. Note that if, at a later stage, the personal handle disappears from the document records, the document will still remain claimed, until the author removes association with it manually.

In ACIS stage three we aim at such a user experience.

Part 2: The requirements

There are two types of requirements in ACIS stage 3. First, there are requirements on the

ACIS software itself, called "A" requirements. Second, there are the requirements on external software that has to be enhanced in order to work with ACIS, called "E" requirements.

A.1. Author identification aid

Users of document archives must be given access to the latest version of the ACIS database. However, they do not need to see the whole database, but only a part of it. They should not be given access to the whole database anyway, some elements, such as email addresses, for example, must be hidden from public access. At document archive services, users will interact with interfaces that will allow them:

to verify a known short-id

to query the ACIS database for short-ids and/or handles matching a name variation

This will be achieved using the MySOL database used by ACIS. Such databases can be accessed remotely over the network. Currently, ACIS creates some tables for its own work. We will document those existing tables and we will define new tables, especially intended for the external use. By default, these tables will cover

name data (first name, last name etc)

name variations

handles

short ids

By default, these tables will be open for public access by anyone. But ACIS installation administrators can easily restrict access to those databases, if they so wish. There are free, open-source tools, such as phpMyAdmin which can help with the task.

A.2. Document metadata pushes

In order to more seemingly integrate document archives with ACIS, we need document archives to push metadata into ACIS for immediate APRU processing.

When a external metadata provider which supplies data to an ACIS installation has a new or an updated document record, it may want ACIS to process it as soon as possible. For this we introduce an update request interface. A metadata provider sends a HTTP

request to ACIS, identifying itself and specifying which particular object it wants ACIS to update from it.

In RePEc terms such a request must contain an archive identifier and a pathname to the new/updated file that needs to be mirrored, relative to the root directory of the archive's access point. In OAI terms, ACIS processes a GetRecord request. ACIS gets the archive identifier and the OAI URL.

ACIS first will authorize this request by checking its originating IP address against a list of allowed IP addresses. These IP addresses are maintained by the administrator of the archive. If IP authentication fails, ACIS sends the HTTP error code 403.

If authentication is successful, ACIS will pass the update request to a data-mirroring function. This function will go fetch the file and store it to a local copy of the archives' data. After that ACIS will process this new or updated file and its data will enter ACIS database in a usual way.

If gathering the data from the document archive was successful, ACIS sends the HTTP code 200 together with the newly acquired record. This can be use by the archive for debugging purposes.

The name of the data-mirroring function will be configurable by administrator. Since ACIS can be used on a set of data in files of completely different structures and using different underlying technology, an appropriate data-mirroring function will have to be

written for it externally. But note that data-mirroring mechanism will have to exist in the first place anyway, to get the data into ACIS in the first place, All that has to be done is allow such software to process a small set of records. Ideally there should be only one. Under OAI, this is trivial.

This update request interface will allow a document service like EconWPA to `push' its recent additions to the RePEc Author Service nearly real-time. In combination with author identification aid and automatic research profile update system, this will simulate document archive and ACIS installation as if they were an integrated system.

A.3. Supplement upload

Registered users will have the ability to add supplements to documents in the document stock. The full-text of a working paper version of a document would be a possible supplement, a dataset used in writing the document would be another possibility. Supplements are always related to a document in the stock that has been claimed by the

user.

The supplements are supplied as files. Users can submit several files for any document in his research profile. They can remove any files that they have previously submitted. All the files are stored on ACIS machine in a publicly available web space. Each document, which has at least one supplement file, has its own directory for those files. Thus one document cannot have two supplement files with the same file name.

The user describes the relationship between the file and the document in a free text input field. We will try to capture the MIME type of a file by giving the user a drop-down box with friendly names. The last selection in that box is other, in which case no MIME type information will be captured. The date of submission is read as the date stamp on the file. If a user deletes her association with a document, the files corresponding to that document, that have been provided by the user, are deleted by ACIS. ACIS does not maintain an archive of withdrawn files.

The data about the supplements will be exported as AMF files with a simple structure: for each of the documents all its supplements will be listed. Supplements listing will include file relationship to the document (as described by the submitter), URL of the file and MIME file-type where it is present.

E. Requirement to complement other software

E.1 Implementation for Eprints

Eprints, by default, generates metadata in Dublin Core for all the documents contained in an Eprints archive. Provided such metadata has a DC:creator field and a DC:title

field, as, well as an identifier, such documents can be readily given a primitive AMF translation. Here DC:title becomes AMF:title, DC:creator becomes AMF:/hasauthor/person/name. In addition, it will be possible to capture the handle of the

document in Eprints as AMF:id, and the URL of the HTML page in Eprints as AMF:displaypage. This is a minimum conversion at this stage. It will imply that there is only one collection for the whole of the archive, and all documents in the archive belong to that collection. Work funded under this project will implement this basic AMF

conversion. Software funded under this project will provide such a basic conversion and store it, one file per record, on the Eprints machine.

The Eprints archive, may, if it wishes, provide a customized collection of AMF that an ACIS collection could import. Providing such solutions for individual archives is beyond

the scope of the project.

In main contribution of the project to Eprints should be the usage of personal handles in the Eprints document metadata capturing process. At the time of writing this document we have not decided that instant claiming will be implemented.

E.2 Implementation for EconWPA

For EconWPA, we will offer to rewrite their submission script and we will furnish a script that will implement instant claim processing. This script will come with

a full AMF conversion of the internal metadata format, as traditionally being converted to ReDIF first. This will then be pushed to the RePEc author service via the interface to be built in A.2.

Part 3:	Sequence of events

Stage 3 will start with a study period of Eprints. A small working party will be established with Ivan Kurmanov, Antonella de Robbio and Thomas Krichel as members. Antonella and Thomas will examine a report by Ivan on how to best integrate author identification into Eprints. The supplement uploading interface A3 will be implemented in parallel to the study period. Once the study period is finished, this document will be

updated to allow for further insights gained from the process.

2004-07-30T12:45:32