Draft: Subject to Change
Introduction
This page has an Introduction, a Brief Element Set Table, and a Full Element Set Table that includes a key to the fields within a table.
Purpose
This element set identifies the elements that compose a submission agreement (both a regular and standing submission agreement). The element set will likely evolve over the course of developing the submission agreement XML schema. This document has not yet received a careful edit so typos surely abound. This element set is illustrated in part by the accompanying case study.
Brief Element Set Table
| Element Category | Element |
| Submission Agreement Management | Submission Agreement ID |
| Endorsement Date | |
| Archive | Archive ID |
| Warrant to Collect | |
| Ingest Project Management | Accession Number |
| Activity Log Number | |
| Survey Report ID | |
| Producer | Records Creator Records |
| Recordkeeping System | |
| Records | General Records Description |
| Record Type Record | |
| Format Type | |
| Date Span | |
| Extent | |
| Copyright | |
| Access | |
| Arrangement and Naming Scheme | |
| Retention Period | |
| Producer to Archive | SIP Creation and Transfer |
| Transfer Date | |
| Archival Management | SIP to AIP |
| Archival Description Standard | |
| Respect de Fonds |
Full Element Set Table
Field Key
Element Category
Groupings or categories of elements. This category exists to help project staff and contractors think about the submission agreement elements. The Element Categories do not have any significance in a submission agreement and do not need to be conveyed in the submission agreement XML schema.
Element
The names of the elements that compose a submission agreement.
Description & Purpose
A free-text general description of an element.
Properties
Information about the nature and qualities of an element along with the nature and quality of the data that is in an element. This field has sub-elements (listed below)
R/O
Required or Optional
All/Some
All or Some
All = The data in the element MUST refer to all the records in an Ingest Project covered by the submission agreement
Some = The data in the element MUST refer to all or some of the records in an Ingest Project covered by the submission agreement
Repeatable
Yes or No.
Is the element repeatable?
Ref Rule DB/Inline
Ref Rule DB and/or Inline.
Ref Rule DB = The data in the element references an external rule.
Inline = The data in the element does not reference an external rule. All information is contained within the data in the element.
Data Content
A general description of the data in the element. This a very abbreviated data content standard statement.
Free Text or Text Controlled or alpa-numeric string local or alpa-numeric string standard or date string
Free Text = Free text sentences or paragraph
Text Controlled = A textual title that is from a controlled vocabulary.
alpha-numeric string local = An alpha-numeric code that has local (archive) significance. For example: j2008.024
alpha-numeric string standard = An alpha-numeric code that uses a national or international standard like an ISBN number.
date string = A date or date span.
Implementation Notes Column
Notes about implementing this element in a standing and regular submission agreement along with implementation examples. See [Standing vs Regular Submission Agreements] for more details.
Regular Notes about implementing the element in a regular submission agreement.
Regular Example An example of element data in a regular submission agreement. This example is illustrative only and is not meant to define a data content rule.
Standing Notes about implementing the element in a standing submission agreement.
Standing Example An example of element data in a standing submission agreement. This example is illustrative only and is not meant to define a data content rule.
Concerns
- Applying information in an element within a submission agreement to some but not all of the records covered by a submission agreement. For more details on this issue, see [Case Study One|Case Study One Submission Agreements].
- The difference between Standing and Regular submission agreements. For more details on this issue, see [Standing vs Regular Submission Agreements].
- It appears that all elements that are Some in the All/Some subfield are by definition Repeatable. However, all elements that are All in the All/Some subfield are not necessarily not Repeatable.
- Currently there is not an element in the element table for indicating if a submission agreement is standing or regular. But obviously this characteristic of a submission agreement needs to be indicated somehow.
- Currently there is not an element in the element table that explicitly delineates separate series within a single ingest project, as illustrated in [Case Study One|Case Study One Submission Agreements]. This needs to be delineated somehow, but its not clear if this needs to be addressed by an element within the XML schema or if some other solution is appropriate.
| Element Category | Element | Description & Purpose |
Properties |
Implementation Notes |
| Submission Agreement Management | Submission Agreement ID | Provides a local unique identifier for each submission agreement. | R/O Required
All/Some All Repeatable No Ref Rule DB/Inline Inline Data Content alpha-numeric string local |
Regular Nothing to note at the moment Regular Example Standing Standing Example |
| Endorsement Date | The date that a producer and archive endorse a submission agreement. | R/O Required
All/Some All Repeatable Yes (But only if a producer and archive endorse a submission agreement on different days) ExRef/Inline Inline Data Content Date String |
Regular 1. Use a recognized date standard, such as ISO 8601. Regular Example Standing Standing Example |
|
| Archive | Archive ID | Clearly identifies the archive with full official name. | R/O Required
All/Some All Repeatable No ExRef/Inline Inline Data Content Text Controlled |
Regular 1. There may be a nationally recognized way to identify an archive. See Describing Archives: A Content Standard (DACS). Eliot needs to look this up. 2. An archive may want to hard-code this data when implementing submission agreements since the data should be the same for all of its submission agreements. Regular Example Standing Standing Example |
| Warrant to Collect | Identifies policies, charters, charges, or other documents that give the archive the authority to accession, manage, and preserve the records in the ingest project. | R/O Optional
All/Some All Repeatable Yes ExRef/Inline ExRef Data Content Text Controlled |
Regular 1. Data will normally be the formal title of the authorizing document. Data might also include the location of the document. 2. Multiple documents may authorize an archive to collect records (hence this being a repeatable field), although that will be a relatively rare occurrence. Regular Example Standing Standing Example |
|
| Ingest Project Management | Accession Number | Creates a unique identifier for individual ingest projects of archival materials being transferred to an archive. | R/O Optional
All/Some All Repeatable No ExRef/Inline ExRef Data Content alpha-numeric string local |
Regular 1. An archive may be able to use its Submission Agreement IDs as its accession number and not have the need for a separate accession number id system. However, an archive might also not have a submission agreement for every single accession of records, particularly for small or surprise accessions. 2. An accession number usually references an accession log or database. Regular Example Standing Standing Example |
| Activity Log Number | An archive may log its activities with records creators, creating log activities for records surveys, transfers, advice, etc. | R/O Optional
All/Some All Repeatable Yes ExRef/Inline ExRef Data Content alpha-numeric string local |
Regular 1. An archive may track its interactions with producers and records creators. Not all of these interactions directly involve an ingest project, but an archive may want to track the interaction(s) that are somehow connected to the ingest project covered by the submission agreement. 2. An activity log number usually references an activity log or database. Regular Example Standing Standing Example |
|
| Survey Report ID | A survey report is a document that the archive writes giving an assessment of the records held by a records creator before the records are transferred to the archive. | R/O Optional
All/Some All Repeatable Yes ExRef/Inline ExRef Data Content alpha-numeric string local |
Regular 1. An archive sometimes writes a survey report (or multiple reports) of the records involved in an ingest project and it may want to associate that report with the records it accessions. 2. Often an archive will associate a survey report with an Activity Log Number, which would normally eliminate the need for using this element. Regular Example Standing Standing Example |
|
| Producer | Records Creator Records | An (at least locally) authoritative record identifying and describing a records creator (either an organization, a sub-unit within an organization like a department, an individual, or a family). | R/O Required
All/Some Some Repeatable Yes ExRef/Inline ExRef or Inline Data Content alpha-numeric string local or Text Controlled |
Regular 1. A submission agreement must reference a records creator, either referencing a separate object (separate database) representing the records creator, or internally containing the name of the records creator if no such external object (database) exists. 2. Ideally an archive would have a database of records creator records that a submission agreement can reference. However, many archives do not have such a database so the submission agreement must then at a minimum clearly identify the records creator(s) involved in the ingest project. 3. In the context of submission agreements, most records creators will have the status of being a producer, the entity that transfers the records to the archive, but this is not always the case. See “Producer” in the Glossaryfor more details. Regular Example Standing Standing Example |
| Recordkeeping System | An (at least locally) authoritative record identifying and describing a recordkeeping system. | R/O Optional
All/Some Some Repeatable Yes ExRef/Inline ExRef or Inline Data Content alpha-numeric string local or Text Controlled |
Regular 1. Few archives currently describe recordkeeping systems but this is becoming an emerging need. For example: Tufts has six registrars offices that all use the same student information system. So student records come from different offices and producers but from the same recordkeeping environment. The archive may need a way to structurally describe this difference in a submission agreement. 2. The need for this element might be eliminated if recordkeeping system becomes a class or type within the record creator record. Regular Example Standing Standing Example |
|
| Records | General Records Description | A submission agreement must have a brief description that provides a narrative description of the circumstances, records creator, and the records covered by the submission agreement as a whole. | R/O Required
All/Some All Repeatable No ExRef/Inline Inline Data Content Free text. |
Regular 1. An archive may want to map this directly into the scope and content note in its archives management database system. 2. data will usually be one to five or so sentences long, a paragraph essentially. Regular Example Standing Standing Example |
| Record Type Record | An (at least locally) authoritative record identifying and describing types, or categories, of records. A submission agreement may identify the record type(s) of the records covered in a submission agreement. | R/O Optional
All/Some Some Repeatable Yes ExRef/Inline ExRef or Inline Data Content Alpha-numeric string local or Text Controlled |
Regular 1. A submission agreement should reference a record type record, either referencing a separate object (separate database) representing the record type, or internally containing the name of the records type if no such external object (database) exists. 2. Often this external database will take the form of a records retention schedule. Regular Example Standing Standing Example |
|
| Format Type | The format of the records covered in a submission agreement | R/O Required
All/Some Some Repeatable Yes ExRef/Inline ExRef or Inline Data Content |
Regular 1. A submission agreement must identify the format of the records in an ingest project, ideally referencing a local separate database (real database, registry, or simple list) of formats or an external nationally or internationally recognized format registry. 2. If such a local formats database does not exist, the archive must name the formats in the submission agreement even if it does not reference an external database, registry or document. Regular Example Standing Standing Example |
|
| Date Span | The data span of the records records covered by the submission agreement. | R/O Required
All/Some Some Repeatable Yes ExRef/Inline Inline Data Content Date string |
Regular 1. There are a variety of ways to write date spans. Regular Example Standing Standing Example |
|
| Extent | The amount or number of records covered by the submission agreement | R/O Required
All/Some Some Repeatable Yes ExRef/Inline Inline Data Content See Implementation Notes |
Regular 1. For paper records, extent is usually expressed in linear feet, cubic feet, or number of boxes. For electronic records, extent is usually expressed in byte size or number of files or number of media objects. 2. Extent data usually has a numeric value and then a unit of measure. Regular Example Standing Standing Example |
|
| Copyright | Copyright status usually identifies the copyright owner of the records covered by a submission agreement. It may include or reference a licensing agreement or terms of use between the copyright holder and the archive. The copyright status may also identify the copyright date and the date the copyright is scheduled to expire. | R/O Required
All/Some Some Repeatable Yes ExRef/Inline ExRef or Inline Data Content Free Text or Text Controlled |
Regular 1. Ideally, the identification of the copyright holder will reference an external record creator object (see the Record Creator Records element). In practice many archives will only have a clearly identifiable name in the submission agreement that does not reference an external object or database. 2. Data about a licensing agreement may be fully embedded into a submission agreement or a reference to an external document. Because many agreements are so complex and long, they will usually be external documents. Regular Example Standing Standing Example |
|
| Access | Access rights define who can see what records covered in the submission agreement when. Access restrictions may include dates of when restrictions are scheduled to end. | R/O Required
All/Some Some Repeatable Yes ExRef/Inline ExRef or Inline Data Content Free Text or Text String |
Regular 1. Many archive will reference access categories that are part of its local policies. 2. Some archives will embed the access restrictions entirely within a submission agreement without a reference to an external document. 3. Some archives will include dates for the expected lifting of access restrictions. Regular Example Standing Standing Example |
|
| Arrangement and Naming Scheme | An arrangement and/or naming scheme created by the records creator that the archive is going to continue to associate with the records covered in the submission agreement. | R/O Optional
All/Some Some Repeatable Yes ExRef/Inline ExRef or Inline Data Content Free Text |
Regular 1. An archive may put this naming or arrangement scheme entirely within a submission agreement. An archive may also refer to an external document that has the naming or arrangement scheme. Regular Example Standing Standing Example |
|
| Retention Period | The retention period declares how long the archive must preserve the records covered in a submission agreement. | R/O Optional
All/Some Some Repeatable Yes ExRef/Inline Inline Data Content Free Text |
Regular 1. Retention periods are either expressed as a time period or an event plus a time period. 2. Retention periods should also express the disposition of the records: what happens to the records at the end of the retention schedule. 3. Retention periods should also indicate who has the authority to execute the disposition of the records. 4. Most records an archive collects are going to have a permanent retention period. Regular Example Standing Standing Example |
|
| Producer to Archive | SIP Creation and Transfer | This details how the records creator will prepare and transfer to the archive the records covered in the submission agreement. See the Glossaryfor more information on SIPs. | R/O Required
All/Some Some Repeatable Yes ExRef/Inline Inline Data Content Free Text |
Regular 1. An archive wants to be able to control how it receives records and be able to plan for what it receives. 2. Components of a SIP can include: a) the format of records; b) the packaging of the records (put the paper records in a records center box); c) the metadata associated with the records; d) the method of transferring the records to the archive. 3. Data in this element ranges from being very regularized, detailed, and extensive to being informal and brief. Regular Example Standing Standing Example |
| Transfer Date | This indicates the date a producer actually transferred records to an archive. | R/O Required
All/Some All Repeatable No ExRef/Inline Inline Data Content Date String |
Regular 1. Use a recognized date standard, such as ISO 8601. Regular Example Standing Standing Example |
|
| Archival Management | SIP to AIP | This details what the archive will do with the records covered in the submission agreement when it receives them from the producer. See the Glossaryfor more information on AIPs. | R/O Optional
All/Some Some Repeatable Yes ExRef/Inline Inline Data Content Free Text |
Regular 1. An archive may want to document how it transforms its SIPs to AIPs to a) facilitate an operation that is transparent to the producer b) support the semi-automation of its management and preservation of the records it receives from producers. 2. Components of a SIP to AIP can include: a) migration of records from one format to another; b) creation of derivative datastreams; c) associated metadata. 3. Data in this element range from being very regularized, detailed, and extensive to being informal and brief. Regular Example Standing Standing Example |
| Archival Description Standard | The descriptive standards the archive will use to describe the records covered by the submission agreement. | R/O Optional
All/Some Some Repeatable Yes ExRef/Inline ExRef or Inline Data Content Text Controlled |
Regular 1. An archive may list the name of archival descriptive standard without making a reference to any external resource. But an archive may choose to reference an external resource, usually a website with the official version of the standard. 2. An archive may use multiple descriptive standards on a set of records. Regular Example Standing Standing Example |
|
| Respect de Fonds | The archival collection or fonds (the intellectual home) the records covered by the ingest project will belong to when the archive manages the record. | R/O Optional
All/Some Some Repeatable Yes ExRef/Inline ExRef Data Content alpha-numeric string local |
Regular 1. Normally a set of records covered by a submission agreement will be associated with a single archival collection. But on occasion, an archive will associate portions of a set of records to multiple collections. 2. The data will always reference the archival collection or fonds record in the archive’s archival management database system or other database. Regular Example Standing Standing Example |