Uploading DIP objects to an existing AtoM description without a new child level, and per-item target descriptions in metadata.csv

[Ygor Souza]

Hi all,

We run Archivematica (version 1.15.1) integrated with AtoM (version 2.8.2) at our institution, and we have two related but separate questions about the DIP upload to AtoM workflow. Posting both here since they may have different answers/audiences.

---
Question 1 - Attaching a digital object to an existing description without creating a new child-level description

We already have a large number of descriptions created directly in AtoM (not created by Archivematica). We now want to use Archivematica to upload digital representations into some of these existing descriptions, but without Archivematica creating a new child-level description under the target (which is the default behavior when using the Access system ID / slug and the "Upload DIP to AtoM" microservice).

Is there any supported way, either via configuration, an Archivematica setting, or a specific AtoM-side behavior, to have the digital object attach directly to the target description itself (the same node identified by the slug), rather than always being inserted as a new item-level child underneath it?

If there isn't a supported way to do this through the standard DIP upload integration, we'd appreciate confirmation of that, so we know to rely on manually linking/uploading the digital object directly in AtoM instead.

---
Question 2 - Sending different items in the same transfer to different existing target descriptions via metadata.csv

Separately, we're wondering whether there's any way to have a single transfer's metadata.csv specify a different target AtoM description (a different slug/level of description) per item/row, so that each digital object in the transfer ends up under its own pre-existing description rather than all objects going to the single slug set via the Access system ID field for the whole transfer.

We understand that today the target description is set once per transfer (via Access system ID or the slug entered at the Upload DIP step), and that metadata.csv only supplies descriptive metadata (Dublin Core fields), not routing/destination information. We saw an old related feature request (archivematica/Issues #402, from 2018, proposing something like atom.level / atom.repository columns) that doesn't seem to have been implemented.

Is there any newer mechanism, script, or supported workaround for sending multiple items in one transfer to multiple different existing descriptions, short of creating one separate transfer per target description? If not, could this be considered as a feature request?

Thanks in advance for any guidance!

Best,

Ygor

[Johan Pieterse]

Hi Ygor

Q1: You are correct as far as I know

Q2: On the second question: no, and the reason is structural rather than a missing feature.

The DIP upload is a single SWORD deposit of one zip to one URL, where the target is taken from the transfer's Access system ID:
POST {atom}/sword/deposit/{access_system_id}
X-Packaging: http://purl.org/net/sword-types/METSArchivematicaDIP

metadata.csv is consumed by Archivematica and never reaches AtoM, and nothing in the deposit carries a per-file destination. So there is no mechanism to route rows to different descriptions, and the 2018 request (#402) is still the right place for it.

There is a workaround short of one transfer per target, though. AtoM's REST API accepts a target per digital object:
POST {atom}/api/digitalobjects

{"information_object_slug": "...", "path": "..."}

With information_object_slug it attaches the object to that description rather than creating a child, which also answers your first question. So a post-processing script over the DIP can place each file against its own existing description, doing in one pass what would otherwise need one transfer per target.
  

I verified this against Archivematica 1.17.1 on our VM and AtoM 2.10. You are on 1.15.1 and 2.8.2. The SWORD deposit mechanism is long-standing and I'd be surprised if it differs, but I haven't checked his versions, so either say which versions you checked".

JOhan