Digital representations of physical media as ca_objects?

AlejandraSummit

Hi, I'm wondering if there's anyone that has experience tracking preservation-quality digital files as objects in CA? Since (in our use cases) the preservation mandate passes from the legacy tape to the new, high-quality digital file, so should the tracking of the preservation management follow to the digital file. This high-quality file would subsequently have its own representation- say, a compressed MP4 file of an uncompressed video file. Thoughts?

If you did do this, did you map both the physical and digital asset as a ca_object? If you've done anything similar to this what were your experiences?

alcoma

Hi Alejandra, I can share a bit of our situation in case its helpful, as your question reminds me of a similar struggle I've experienced dealing with a large amount of records for analog audio objects and for those that are digitized, their digital counterparts.

During the initial setup of C/A, it became clear that having a separate record for every "instantiation" of a digitized item could quickly become unwieldy for us. (We modified a PBCore template for the configuration). So for most cases, we try to track everything under one umbrella; meaning for analog objects we have sections in the record for "Reformatting History" to track engineer/technical info, and "Instantiations" where info for preservation files and access derivatives can be listed. The object representation generally stems from one of the listed access files.

There are instances where we do create records for digital audio objects and make relationships between them and a source analog object, which is ideal in some scenarios.

AlejandraSummit

alcoma Thank you for your response! It is good to hear from others who are also modifying the PBCore profile. If I understand correctly you have your instantiations tab that has a list of your preservation files. After that list is created you add object representation relationships as needed. Did you have to modify your profile to allow you to list preservation file information without creating relationships? What are your likes and dislikes about this setup?

Could you tell me more about the instances where you create digital audio objects and make relationships between them and their source analog objects? I am curious why you choose to handle your data like this in only some occasions. It is especially intriguing to hear how others handle their data since some of our data is born digital but so far I only have experience importing physical objects.

Do you happen to have a public view of your catalog I can look at as reference? I would love to see more examples of PBCore compliant catalogs.

alcoma

I should note that modification of the profile was minimal. Also, I don’t know if the profile template has changed but the one we started on was from 5+ years ago.

So yes, one of the tabs in our object editor is for Instantiations. We have repeatable fields to reference digital files (master and access), along with fields for other specs like formats, generation, channel config etc.. We didn’t have to modify anything for this since these fields existed in our legacy database which was migrated into CollectiveAccess, though some were also mapped into relevant PBCore fields. But because we might have many files for one digitized recording (Ex: multiple mono, intermediate, and edited files), it seemed overkill to have to create a new record (how the instantiation relationship seemed setup in the template) for every file reference. Static fields seemed to be enough for our needs so this is one function I disabled in the template. We do create separate objects for digital files that are created as a result of needing to edit multiple analog items together to represent the original recording (particularly concerts or radio broadcasts). Then that digital object will have a relationship to the various analog objects whose parts are contained within so the source is better understood.

Another example similar to this is when we received a digital collection of audio from a performing group; the files were delivered in tracks, but stemmed from analog sources. We created digital objects based on each file delivered, then created analog objects based on whatever notes they gave that would allow us to connect the parts to their source. Whenever we can we make these relationships between materials visible; we do as a rule maintain relationships between parts of a whole. One of the reasons we switched to C/A was the ability to have these relationships between objects, entities, events, etc. which we did not have in our legacy database. So some of our oldest records may not reflect this practice.

I hope this isn’t too confusing! Our public site presents very differently than our Providence instance so it’s probably not helpful for an understanding of how we’ve adopted PBCore, but you can see how related objects are used.