iVia

Chapter 12: The iVia Editorial Control System

This chapter describes the iVia editorial control system. It is designed to help institutions will to work in concert to produce high-quality, peer-reviewed records.

To understand the system, it is necessary to understand the role of the two main iVia databases: the live (or record_info) database contains the finished records that are search-able by all visitors, while the pending database holds the incomplete and unfinished records that are not yet ready for public use. Records are created in the pending database, where they are reviewed by one or more Adders, becoming increasingly polished at each step, before finally being committed to the live database by a senior Adder.

A simple example

In simple iVia installations, all the Adders are given permission to add records to iVia, and to edit records that are in iVia. This means that the editorial control system is very simple (almost non-existent).

If an Adder wants to add a new record, she clicks on the "Create a New Record" option on the main menu, then supplies all the necessary details in the Record Adder (as described in the Adding Records chapter). When the record is complete, she uses the preview button to review her work, which is stored in the pending database. She then clicks the "Commit to live database" to add it to the live database. In this scenario, the Adder created a record with no assistance from her fellow Adders.

A collaborative example

In a more complex scenario, a Contributor (junior Adder) creates a new "draft" record. They work on this record until it is complete, and then submit it for review, whereupon it is marked "contributor_done" and stored in the pending database. The record then becomes visible to the Editors and Catalogers (mid-level Adders) at the same institution.

One of the Editors "claims" the record for further review, and works on it further. (When a record has been claimed by an Adder, no other Adder may alter it. Each record in the pending database is associated with a particular institution, and can only be claimed by Adders from that institution.)

When the Editor has finished, they too submit the record for review. At this point it is noticed by a Coordinator (senior Adder) who claims it, makes a few changes, and decides it is suitable for inclusion in the live database. They commit the record to the live database, at which point it is available to the general public through the search and browse interfaces.

Types of Adder

There are six Adder types, listed here in order of increasing responsibility. Each has an equivalent title, and though this can vary within certain bounds.

The Pending Database

The pending database is our repository for "working copies" of records. It has almost the same structure as the live database, plus five extra fields. These fields are used to keep track of the status of each pending record.

The fields are:

1. owner: this field contains the user name of the Adder who "owns" the record. When the owner field is set, no other Adder may work on the record in any way. When the Adder has finished working on the record, it is "released" and the owner field is set to NULL. When the owner field is NULL another Adder may "claim" the record and become its owner.

   Note that "owner" only applies to the copy of the record being edited in the pending database. More generally, a record might be said to be "owned" by, and the responsibility of, the person who created it.

2. institution: this field contains the institution code of the Adder responsible for creating the record in the pending database. A record can only be claimed by Adders from this same institution.

   The institution field can be NULL, meaning Adders from any institution can claim the record.

3. source: This field records how the record in pending was created (this is quite different from the origin field). Possible values are:

   1. new_record: The record was created from scratch when the Adder elected to "Add a new record".
   2. existing_record: The record is a proxy for a record in the record_info database, created when the Adder elected to "Edit an existing record". When the record is complete it will replace the version in record_info.
   3. clone: The record was created by cloning a record in the record_info database.
   4. crawler_added: The record was created with the interactive focused crawler (equivalent to new_record).
   5. record_builder: The record was created with the record builder (equivalent to new_record).
   6. deleted: The record was previously in the record_info database, but has since been deleted.
   7. suggestion: The record was suggested by a member of the public or similar untrusted source. (i.e. Karen’s "shell" record.)

4. progress: This field records the level of review that the record has received. Possible values are:

   1. draft: The record is newly created and the owner is still working on it. (Every draft record must have a non-NULL owner.)
   2. student_done: The record was created by a student and is now ready for an instructor to review.
   3. instructor_done: The record was created by a student and reviewed by an instructor; it is no longer needed by the class and can be considered for addition to iVia.
   4. contributor_done: The record has been reviewed by an Contributor, and is now ready for a more senior Adder to review.
   5. editor_done: The record has been reviewed by an editor.
   6. cataloger_done: The record has been reviewed by a cataloger.
   7. all done: The record has been reviewed by an editor and by a cataloger. It is ready to be added to the database.
   8. hold: The record is all_done (it not does not currently require attention from the Catalogers or Editors) but is not yet ready to put in the record_info database.
   9. future: The record is all_done (it not does not currently require attention from the Catalogers or Editors) and is being held back from record_info for a forthcoming special collection.
   10. inactive: The record is not being actively modified (i.e. it is a deleted record).

5. record_id_in_record_info: This field is only used by records that have come from the record_info database (i.e. those whose source is "existing_record" or "deleted") to contain the value of the record_id field in record_info. Otherwise, it is NULL.

   The record_id_in_record_info field will also be used to ensure that only one Adder can edit a particular record from record_info at any given time.

The data in these fields will be lost when the record is added to the live database.

Note: when an Adder elects to update an existing iVia record, a "proxy" record is created in the pending database that can be edited in the same way as a new record, and which is subject to the same editorial review process. The "live" database will thereforeee remain untouched until the changes to the proxy record are approved; when the proxy record is committed, it will replace the record in the live database..