[Archivesspace_Users_Group] extent sub-records

Callahan, Maureen maureen.callahan at yale.edu
Tue Aug 5 10:38:20 EDT 2014


Our ArchivesSpace implementation group at Yale has been going through extent sub-records, and we have a few questions and concerns.

The major issue has to do with required fields in the extent sub-record. For a number of reasons, we would like to keep the extent type controlled list pretty short and tight, and have the option to put inevitable weird extent information into container summary. In AT, this would be perfectly acceptable, but it's unfortunately not possible to do this in ArchivesSpace. We would like to see the application updated so that number and type are no longer required, or that container summary is an alternate option.

We're also concerned that Extent Number can be entered as a non-integer. We'll do what we can to enforce data entry practices with training, but it will be very difficult to run reports if non-numbers are in this field. We would prefer that this field be restricted to numbers.

Also, it would be really great if "Physical Details" were repeatable. A component may represent a film, for instance, which may have information about film stock, run time, canister color, whatever. Since <physfacet/> is repeatable, it would be good if Physical Details were too.

Finally, two concerns about import.

The MARCXML import does something very strange. No matter what extent information is in the MARC 300, it will import the entire string as container summary and assign 1 linear foot as the numerical extent.

This is the 300:

<marc:datafield tag="300" ind1=" " ind2=" ">
            <marc:subfield code="a">5.51</marc:subfield>
            <marc:subfield code="f">linear ft. (7 boxes)</marc:subfield>

And this is what you get in ASpace:

1 Linear feet
Portion: Whole
Container summary: 5.51 (linear ft. (7 boxes))

This looks like a bug.

And back to extent/container summary. It looks like container summary information in AT is being mapped to a generic physdesc note in ASpace. We would much rather see that stay in container summary.

Thanks so much,

Maureen Callahan
Archivist, Metadata Specialist
Manuscripts & Archives
Yale University Library
maureen.callahan at yale.edu<mailto:maureen.callahan at yale.edu>

Webpage: web.library.yale.edu/mssa
Collections: drs.library.yale.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20140805/d650ad11/attachment.html>

More information about the Archivesspace_Users_Group mailing list