Removing piece-level records

Instructions for removing piece-level records from Calm

Identifying items to edit

  • Search for an entire collection (RefNo plus *, e.g. PPSUL*)

  • Sort the resulting hitlist by RefNo and look through the results to identify where the piece-level records are and how many items they sit beneath.

Checking the physical item

Finding the item in the stacks

  • In Calm, note the box number for each item in the BoxNumber field and see if a location is in the Location field. If not, you’ll need to look up the location in the ring-binder in the basement stacks

The ring-binder is arranged by collection prefix (GC, PP, SA etc.) and then alphabetically.

Find your collection to see where it is located. Be aware that many collections are spread across multiple aisles. The ring-binder entry will specify which boxes are in which location

Checking the item

  • Once you have located your item, check that it is contained within a single box and note how many parts (folders) it is in.

  • One item comprising multiple folders within the same box is very common and not a problem, but it might determine how you proceed (see next section).

  • If not already there, write the PublicRef for the item (not pieces) on the folder. For multi-folder items, make sure “File 1/3”, “File 2/3” etc. is written on each folder. In Calm, check the extent matches (see below).

  • In most cases you are not required to go through every folder to make sure all the pieces are there, but if you happen to notice anything is missing, flag this with an Archivist or Metadata Analyst.

  • If Calm suggests an item contains a single piece record, check whether this is the case. More likely, only one of several pieces has been given a Calm record. This will need to be noted in the description field (see below)

  • When checking the item, you may discover multiple items packaged. This is a problem, but it is outside the remit of this task, unless it impacts the pieces you are working on. See Multiple items packaged together for guidance.

Deciding the approach

  • In most cases, the best approach is to move the piece-level information to the item record. This will almost certainly be the case if the item is contained in a single folder.

  • If the item is spread across multiple folders, the preference is still to move the piece information into the item, making sure the Calm extent field says “1 file (in [number] parts)”

Creating multiple items

If the item is spread across multiple folders and there are numerous piece records and/or the piece records are very detailed, it might be better to split the item into multiple items (1 folder = 1 item).

  • Work out which pieces are in which folders and how many item records you need to create.

  • In Calm, open the Item record above the pieces and clone it to create the additional Item records needed. Copy the RefNo into each new RefNo field and add "a", "b" etc. to the end of each one to create unique RefNos that sit in the correct place in the hierarchy. For example: PPHCT/C/1a

  • The PublicRef should mirror the RefNo but with the extra forward slash. Alternatively, if the existing PublicRef includes the range of pieces, modify this to give the correct range for the first item and follow the format for the new items.

    • If modifying the PubliRef of the existing item, add its old PublicRef to the Previous_Numbers field

  • Edit all the item records, following the guidance below. Update the extent of the original Item record and check if the date also needs modifying. In ArchivistNotes field in the new Item records, add the following text:

Record created as part of piece-level deletion work in [month year] by [initials]

Editing the Calm item record

Find the item record and its piece-level children. Edit the following item record fields:

Description

  • Copy & paste information from the piece-level records to the item. Key fields are the PublicRef; Title; Date; and Description fields. Quickly check the rest of the record, though other fields are less likely to contain data. If any fields duplicate what is already in the item record, you can ignore them.

    • PublicRef: should be retained in the item record in case it has previously been documented by researchers and/or cited

    • Title: in most cases this will be where the key information is recorded

    • Date: should be recorded alongside the specific piece, if dates vary across the pieces. If every piece has the same date, you do not need to include these in the description (date will be given in the Date field)

    • Description: sometimes contains additional information to supplement the title. In some cases the pieces will share similar titles and the key distinguishing information is in the description

    • Other_Number: some collections may have previous non-Wellcome references recorded in the other_number field. These should be included in the item record description alongside the other corresponding piece-leve information.

  • Where there are several pieces and/or there is a lot of variation, the best tactic is to list the pieces. Consider aggregating descriptions of very similar piece records (particularly correspondence)

Example of a list with aggregated entries
  • Use html tags for formatting the description field:

    • <p></p> [for paragraphs]

    • <br> [breaks]

    • <li></li> [unordered list]

    • <ol></ol> [ordered list]

    • <i></i> [italics]

    • <b></b> [bold]

  • If appropriate, you can write a prose summary rather than a list, but you should still include the piece-level archive references

Example of a prose summary
  • If the item record already contains text in the description field, try and integrate this into the text you add. For instance, if the field already says "Presumably extracted from school files by Chave", this could be updated to say “Comprises the following, presumed to have been extracted from school files by Chave: [...list of pieces]"

  • If only some of the pieces has been given a Calm record, you do not need to itemise the remaining pieces in your description. However, you should indicate that the list/description is not exhaustive.

Extent

Check the extent is accurate ("1 file" or "1 volume") and specifies the number of parts, if multiple ("1 file (in 2 parts)")

Date

  • Check the date in the item record is correct. It should be a range encompassing all the piece-level dates (e.g. June 1980-November 1984). If the content all dates from a single year, the date field can either specify the months, or can just give the year (e.g. May-July 1944 vs. 1944)

  • Update the date in the item record if it does not conform to current practice. There is a full list of acceptable date formats. Commonly, the update is writing out months in full (January 1900 rather than Jan 1900)

ArchivistNotes

  • Add the following phrase to the field (if the field already contains text, add it to the end):

“Piece-level data moved to item record and piece records flagged for deletion in [month] 2025 by [initials]

Once finished, save the item record. Changes will automatically feed through to the front end in a couple of hours.

Marking piece-level records for deletion

  • Create a hitlist containing just the piece-level records.

  • Using the Find/replace function, change the CataogueStatus field from “Catalogued” to “For deletion”. Also change the Harvest field from “Yes” to “No”.

Using the find/replace function

FAQs

The RefNo and PublicRef are significantly different: is this a problem?

In most cases, no.

In most modern catalogues, the RefNo and PublicRef are the same aside from the PublicRef have an extra forward slash between the collection prefix and the three-letter collection code (i.e. PPSUL/A/1 vs. PP/SUL/A/1).

Some older catlaogues construct the RefNo and PublicRef differently, mostly for cosmetic reasons for the online catalogue. This can include the PublicRef using full stops rather than forward slashes, seemingly missing levels of hierarchy and including child ranges in the parent reference. Examples:

  • RefNo = PPEPR/G/28 | PublicRef = PP/EPR/G.28-68

  • RefNo = PPGSW/D/43/43 | PublicRef = PP/GSW/D/43-83

  • RefNo = PPGSW/D/43/43/49 | PublicRef = PP/GSW/D/49

However, some differences are due to mistakes. PublicRefs that contain completely different numbers are more likely to be errors. For example, PPSUL/A/1 vs. PP/SUL/A/11. If in doubt, ask someone else in the team for their opinion. You can also check the online catalogue to see if the tree displays as you would expect

There's an odd RefNo / PublicRef: is this a problem?

Over the years, catalogues references have been constructed using different formatting standards. Despite not conforming to current practice, they are not problematic

Another convention is to add a letter suffix to new references in order to sit in the correct place in the hierarchy. For instance, if the series PP/ABC/A/1-25 is arranged alphabetically and a new "L" record needs to be added after cataloguing, the cataloguer would crete a record with the RefNo PP/ABC/A/10a to ensure the "L" record displays in between "J" (PP/ABC/A/10) and "M" (PP/ABC/A/11).

If you still think the RefNo / PublicRef doesn't make sense and could be an error, raise it with an Archivist or Metadata Analyst

Is it OK to have different levels of hierarchy existing at the same depth?

For example, PP/ABC/A/1-3 comprising two series (PP/ABC/A/1 & PP/ABC/A/2) and one item (PP/ABC/A/3)

Having different depths of hierarchy in one collection is fine and usually the preferred option, rather than creating artificial parent levels in order to keep all the items at the same depth.

Having items within items shouldn't really happen, but doesn't technically break anything.

However, it is essential is that piece level records sit within an item record (so that they are part of an orderable unit). A hierarchy that jumps from series to piece is a problem. In some instances the solution is to turn the series into an item record. Otherwise, item records will need to be created for batches of pieces, that mirrors how the physical material is packaged. See Creating multiple items for guidance.

Similarly, a series that comprises items and piece records on the same level as the items (rather than within an item) is also a problem. See the FAQ question below for guidance.

A series contains items and pieces on the same level: how do I deal with this?

Scenario 1: the item should be a piece

  • Edit the actual item record following the above instructions and include the details of the fake-item

  • in the fake-item record, change the Level field from Item to Piece

  • In Sierra, find the Sierra item record for the fake-item and change the ICODE2 field to option "d" DEL/SUPP ITEM

Scenario 2: the piece record should be an item

  • Edit the record so that it conforms to standard item-record cataloguing. See the archive cataloguing guidelines, particularly the list of mandatory fields.

  • Create a Sierra item record for the new item. See the guidelines for manually creating Sierra item records.

Scenario 3: the piece record is part of one of the items

  • Update the item record to include details of the piece record, following the instructions above.

How many pieces can you have in one list?

There is no hard and fast rule. We want to avoid very lengthy description fields, in order to avoid lots of scrolling on the online display. But in some instances it may be unavoidable. For instance, if the parent item record has been digitised it has to remain intact: we cannot split the item into multiple ones (without re-igesting the digital images through Goobi, which we are not going to do).

Where possible, look to aggregate similar pieces into a single line of description. If material is split across multiple folders you can also consider creating item records for each folder. (see Creating multiple items)

Archival description conventions that you may come across (or may be lacking)

"Original titles": Original titles transcribed from the material are put in double quotation marks

[additions by the cataloguer]: additions are put in square bracket, such as expanding on an abbreviation in an original title. They are typically only used in the title, though some older catalogues will use them in the description.

If a public ref indicates the wrong number of files, is it okay to correct it?

Example: PP/GWP/B/5/1-14 implies there are only 14 pieces in the item but there are actually 15

No, best not to change the reference as it might have been cited.

It is possible to change PublicRefs (the old one moves to the Previous_Notes field) but best to use sparingly. In this case, the PublicRef is misleading to anyone who understands reference construction, but the range doesn't have to be correct for the reference to be a valid unique indentifier.

An item contains piece records within piece records: how do I deal with this?

Previosuly, we used to have "group of pieces" as a level option but got rid of them a few years ago as they were causing trouble for the new online catalogue. In some cases "got rid of" meant changing the level from "group of pieces" to "pieces", hence the hierarchy shows piece records within piece records.

Look at the physical item to check that all the pieces are contained within the item (in a single box, though can be in multiple folders) . If so, move the piece record data into the item following the standard instructions above.

Depending on the original cataloguing, the old "group of pieces" records can be incorporate into the new item description, or can be ignored if they only duplicate information in their child piece records.

A record seems to exist in the tree, but I can't open it or find it via searching the RefNo

This is a "phantom" record. The archive hierarchy (tree) is built from the RefNo and Calm requires there to be a record for each hierarchical level. If you accidentally fail to create a record for one level of the hierarchy, Calm will create a placeholder in order to build the hierarchy. Thus is seems to exist in the tree, but there is no record to open and view.

This is solved by creating the missing record. If you give it the correct RefNo it will slot into the correct place in the hierarchy with all the correct child records underneath.

Last updated