Instructions are needed regarding containers information and/or links in order to abide by the "for use" principle

[KateBowersHarvard2]

Potential language

Retrieval reference.
It is strongly encouraged that archivists include information necessary to request parts of large archival resource--such as container numbers or links to online delivery--at the lowest appropriate level in the archival hierarchy. In the case of analog archival resources or analog parts of archival resources that occupy multiple containers, container information should never be the basis for the unit of description, but rather a reference to the container that holds the portion of the archival resource should accompany each component description.

Rationale

It's not a numbered principle, but it is the first sentence of the introduction to the principles includes this phrase: "Archival description exists to facilitate the use of archives."

If a description lacks

• information necessary for a user to request a part of the archival resource, or
• information necessary for a user to reference a part of the archival resource that has been accessed,
  then,
  the description has failed to fulfill the use principle.

I expect that this will require a

• Minor change to DACS
• Major change to DACS
• Do not know

Link(s) to any relevant part(s) of DACS

label

[regineheberlein]

I agree with this 100% @KateBowersHarvard2, thank you for identifying this gap!

I would think this also falls under Principle 2:

2. Users are the fundamental reason for archival description.Permalink
   Archivists make descriptive choices that impact how users find, identify, select, and use archival records. To make wise choices about descriptive practices, archivists must develop and maintain an awareness of user needs and behaviors.

[helrond]

I think there might actually be two things here, which are important to disambiguate:

• Container information
• Hyperlinks to digital surrogates

Container information

I strongly disagree that container information should be required by DACS, or even articulated as an element of archival description. I don't believe that it is either necessary or adequate to ensure the retrieval of archival records. A user does not and should not need to know the details of a container in order to request records housed in it. They are requesting the records, not the container. Additionally, container information by itself is inadequate to support retrieval of archives; location information is also required. This might be different if archives were open-stack, and if there was a general practice of making location information publicly available, but in my experience neither of those are true. What I've typically seen is that requests for records are translated or enhanced (by a person or machine) to add location information, which then facilitates retrieval. Container information is one way to do that, but it's not the only way and, depending on your systems context, there are probably more efficient and less error-prone ways.

Hyperlinks to digital surrogates

This is an interesting idea! I'm not totally sure this can/needs to be a distinct element of description because there are a lot of ways to encode a hyperlink (which depend on your publication platform), so the guidance would need to be general enough to support linking from existing descriptive elements (like a title) or other elements in a UI while also supporting web accessibility standards and best practices.

[michelsd]

Kate and Hillel have brought up some very interesting ideas here.

One of the tricky aspects is that while DACS is helpful for collections management, that is not its purpose. Is what Kate wrote a good idea for most finding aids in most repositories in 2024? Absolutely. Is it something that should be permanently codified in a descriptive standard? I'm not so sure.

I certainly don't think it should be a required element, but I don't think that was Kate's intention.

[regineheberlein]

Thanks for starting to unpack this @helrond and @michelsd ! Lots to think about.

First of all, apologies @KateBowersHarvard2 (and all) if in renaming this issue I suggested that DACS should require containers. I meant to simplify the title and may have inadvertently changed Kate's intention. I'll change it back now!

I absolutely agree with you that conceptually, container information (or location, for that matter), is not in scope for a descriptive content standard. And yet, from a service perspective I think things aren't quite that simple.

If we put the user at the center of description, our goal has to be to facilitate retrieval in one way or another. For physical archives, that means getting the documents in front of the user.

As you point out, one way of doing that is to have two separate systems, one for the description and one for the inventory management. It’s the pivot point between the two—what @helrond you call the translation—that interests me. What does one record need to know about the other to facilitate that pivot, and how do we account for that in a way that it serves most of our users? And where if anywhere does DACS figure into this?

There are different scenarios we can imagine here. Some of us have a fully-automated solution where the identifier of the resource links to the identifier of the container or shelf location (or rather, their records link to one another). In ArchivesSpace, post-addition of the container module, the record for the intellectual content knows about the record for the container, which in turn knows about the container’s location.

A one-stop system like that relies on stable identifiers. Under the hood, though not always explicitly, is an assumption about the relationship between the resource and its location: is it the resource that has a location, or the location that contains a resource?

On the other hand, some of us have a fully human-mediated solution, where a reference archivist does the translation from the intellectual content to the inventory. Identifiers would help here, but the reality is that the human-mediated lookups, including those that manage physical inventory in separate databases, overwhelmingly rely on the container number as the pivot point--a quasi-identifier if you will. As in: Correspondence A-B is in Box 7, Box 7 is at address X, floor Y, shelf Z. Not all users need to know about that, but one user group does: archivists.

So to me, the question is: should DACS acknowledge the reality that archives are often retrieved by container number/id as the pivot point between intellectual description and inventory management, and if so, should it include guidance to help with that?

[helrond]

Hmm, when you put it like that @regineheberlein I'm not sure that rises to the level of what should be in a content standard for archival description. This feels very much like a collections management concern that applies to a pretty specific slice of archives and archivists. My two cents, anyway!

[regineheberlein]

Well, I'm torn myself. Let's try from another angle: Is DACS making an unspoken assumption that access is being handled elsewhere, and should that assumption perhaps be spelled out?

[meau]

I'm loving reading this thread.

Generally I agree that there is lots of room for guidance within the profession about collection control and that there are friction points between this and archival description (there are also friction points between archival description and how we fulfill access to electronic records / digitized records).

I complain about these friction points all the time -- containers and carriers aren't the same thing! It's important that our pointer to what's being fulfilled (the URI or the container) is a 1:1 match to what's being described! We need to all stop mixing different semantic meanings when we create identifiers! There's a lot of room for improvement.

But my guess is that this being mentioned in DACS isn't an oversight -- we don't have anything about collection control in ISAD(G) or other national implementations of it that I'm aware of.

I would be so eager to see SAA (or maybe, ideally, ICA!) create a standard for collection control. But it feels like there's so much to be said about it that I'm not sure that shoe-horning it into DACS, without a pretty meaningful effort to think this all through, would be the right way to go.

Also, there's a lot that the "archives are for use" clause could necessitate, from guidance about reading room hours to accessibility to digitization workflows, so I'm not sure that it's quite a strong enough reason to include this information in DACS.

[KateBowersHarvard]

If container information is necessary to the user to obtain the content, I think it needs to be included in a description, just as we include access restriction information

If you're in an archives where this information is not needed, then this does not apply.

Do a thought experiment: Imagine describing a web-delivered portion of an archival resource and assuming the user would ask the archives for a link, rather than the archive providing the link at the appropriate level of description.

Adding this to DACS would be an opportunity to provide instructions that clarify the distinction between unit of description and container--that is, to indicate that if a container that is an artifact of archival intervention and not an element of original order then it is not the basis of a unit of description.

[KateBowersHarvard]

Summary of discussion of this issue from breakout group TS-DACS Virtual Community Meet for aligning DACS principles with DACS rules

Suggested but not required element
Possible element name: delivery reference

Summary of Discussion

Requires more discussion--there is a lot to unpack and a focused discussion is warranted

Opinions of group:
•This would be a recommendation rather than a requirement
•Recommendations would be immensely helpful to archivists
•At least a box-level delivery reference for descriptions that go into more than collection-level description would be helpful
•Would also be element for link information to digital content as well
•Would be helpful guidance especially for new users of DACS

Other discussion points:
•Terminology should distinguish this issue from identifiers: Delivery reference vs. identifier. We want to ensure that we are distinguishing from “reference code”
•Container instances should be considered separately from intellectual arrangement (ex: “boxes” should not be used interchangeably with “series”)
•We discussed the possibility of this fitting under DACS 2.1.3 (Reference code - local identifier), but decided that because an identifier should be permanent and box/folder locations are subject to change, this is not a clean fit.
•How do local practices possibly affect this issue (ex: storing multiple collections in one box)

What the issues might be (blockers):
•Where would this issue fit within the structure of DACS? Would you make a new element? Does it fit in any existing?
•Local practices seem to vary greatly. Is DACS an appropriate place to set standards?

[kelinbs]

Summary of discussion of possible next steps from Day 3 breakout group TS-DACS Virtual Community Meet for aligning DACS principles with DACS rules

Due to the major nature of the possible change (adding an element to DACS) and the perceived lack of consensus over the need or appropriateness of this addition, a possible next step is information gathering (i.e. a survey) to see if there is field-wide consensus or a primary opinion on this issue and/or if people would find the inclusion of container information in DACS appropriate and beneficial. Further steps could be influenced by the information gathered.

[jbrcka]

I think Kate’s suggestion contains two great instructions, and I wonder if they could be incorporated in two locations.

1. Re: container info and hierarchical level, perhaps a statement like:

“Independently or in conjunction with other management systems, elements within subsequent levels of multilevel description should include sufficient information to facilitate the retrieval of resource components at the lowest appropriate level in the archival hierarchy.“

could be added to the bulleted “Notes” section under the multi-level required instructions?

The “lowest level” piece seems really helpful. Across descriptive outputs, It is inherently not user-centric when a child descriptive component lacks a direct pointer which can be used to retrieve the described content. This is true of container instances applied at levels disparate from their content descriptions within an ACMS. It’s also true of paper or xml finding aids manually crosswalked to stand alone shelf lists where indexing in the finding aid is only sufficient to land one within a box or two (or four) of the requested file.

A statement like this might be a step in the right direction while broader questions about the relationship between container data and DACS are considered.

2. Re: container info and unit of description, a note or footnote along the lines of:

“In devising a title, do not interpolate description of the intellectual nature of the archival unit with description of its instantiation or housing.”

might be added to 2.3.3 or 2.3.19.