compared with
Version 3 by Maria Todorova
on Oct 07, 2011 14:52.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (5)

View Page History
Web Site: [ArchiveSpace|http://www.archivesspace.org/]

The project is still in Design phase. There are some good analysis and design documents: [Specifications|http://www.archivesspace.org/documents/ArchiveSpace%20specifications/]

The ArchivesSpace community is building an open-source web application to manage descriptive information for archives, manuscripts, and digital objects.

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.

http://www.archivesspace.org/documents/specifications/
General Architecture

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.
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.