ArchivesSpace is supported by a grant from the Andrew W. Mellon Foundation and is a partnership between the New York University Libraries, the UC San Diego Libraries, and the University Library of the University of Illinois at Urbana-Champaign.
General Architecture
At heart, the application will consist of:
three main modular areas, allowing users to manage five main record types;
six ‘supporting’ modules, allowing users to manage six record types that can be attached to main record types in many to many relationships; and
a method to create four sub-records types, which can be attached to main record types in a one to one relationship.
In programming terms, each of the five main record types, six main record types, and four sub-record types may be thought of an an object, and each of these objects can be related to other object types in a way that can be represented in subject, object, predicate (triplestore) relationship. The entity relationship diagram available at [http://www.gliffy.com/publish/2269861/] provides on overview of the potential relationships, which are discussed in more detail in each of the specifications, linked below as PDF files.
In addition, we are proposing that the the overall system architecture allow for the user community to develop new main record types, supporting record types, and sub-record types, or to extend the functionality of core areas. In other words, the overall architecture must be extensible. As a design principle, it must be possible to add additional functional areas without requiring any changes to the application core, that is to say without modifying storage architecture (e.g.table structures), object model, and API/libraries for the functional areas that are described below.
Three Main Modules
Main modules represent the most important functional areas of the application and are the areas where most staff and public users will interact with the system. Using these modular areas, staff users will create, edit, and delete records, as well as establish relationships between five record types:
Accession Records (pdf) / Deaccession Records (pdf)
Resource and Resource Component Records (Preliminary Draft)
Digital Object and Digital Object Component Records
For each of the five record types listed above, users will be provided a method to link records of prescribed record types to other prescribed record types. Specifically, a user will be allowed to link the following record types to each other:
accession to resource; source of
resource component to resource; child of
resource component to resource component; child of
digital object component to digital object; child of
digital object to resource (siblings or child to parent); representation of\*
digital object to resource component; representation of\*
* In practical terms, the digital object may represent a surrogate of the entire resource/resource component record or only a portion of the resource/resource component record.
Six Supporting Modules
The supporting modules will allow for the creation of supporting records that sit in a many-to-many relationships with accession resource, resource components, digital objects, and digital object component records. For example, one or more subject record may be linked to one or more resource records, each staff user record is required to have an associated repository, and so on. the permissible relationships are as spelled out in the specifications and are shown in summary form in the draft entity relationship diagram.
The supporting modules will allow users to create, edit, and delete the following record types:
Repository Records
Staff User Records
Location Records
Name Records
Subject Records
System Administration/Configuration Directives (under development; will control display properties and other values).
System operators will creation and delete supporting record relationships within the interface for the ‘main’ record type. For example, if a user is wishing to specify that a particular resource record contain information related to the subject x, he or she would make the linkage in a designated area of the resource record. In cases where a supporting record type can be linked to another supporting record type, the linkage will take place within the interface to create, edit and delete the supporting records. For example, if a user wants to give a particular staff member permission to edit records for repository y, that relationship would be established on the staff user editing page. If a user wishes to say that Name Record z was the parent of Name Record A*, the relationship would be established in the names module.
* Where users create a hierarchical or temporal relationship between name records, the interface should create reciprocal relationships. If a user make record A the parent of record B, it should also mark record B as the child of record b.
Sub-records
Sub-records can be created only in the context of an open accession, resource, or digital object record, and they are linked to the parent record in a one-to-one relationship.
Date Statement Sub-records
Extent Statement Sub-records
External Document Sub-records
Rights Management Sub-records
Location sub-records (consists of a linked location record and additional attribute values, as defined in location specification.)
For example, within the context of a particular resource record, a user can launch a method to create a date statement, extent statement, external document statement, or rights management statement. Each of those statement sub-records can be attached to one and only one parent record.
From Maria:
The project is still in Design phase. There are some good analysis and design documents: [Specifications|http://www.archivesspace.org/documents/ArchiveSpace specifications/]
...