Managing Digital Assets

Preservation Collection Digital Asset Management Systems?

Puh. Where to begin?

It’s a database and some UI possibly referring to files. Designed to find and organize stuff.

CMS: Collection Management System
MAM: Media Asset Management
DAM: Digital Asset Management

CMS usually includes a MAM, and a MAM is a media-type-aware version of a DAM.

Disclaimer: DAMs or MAMs may be used for preservation, but are sometimes/often not designed or intended for use in a preservation context, but merely to store and handle “digital assets”: from regular office files (documents, images, etc) to managing in-house assets of larger companies. And some of these systems were then “also” used by archives.

The term “Collection Management System” usually indicates that it was more likely intended to be used in a preservation context, such as museums for example - where it may be used beyond digital: To handle physical collections even, like books, chairs, or anything. And files ;)

You may see the term “Collection Management System” being used interchangeably with DAM or MAM by the preservation community.

(Note: The abbreviation “CMS” usually means “Content Management System” which is something completely different. In order to save some screen space, I will use the abbreviation “CMS” in these slides however instead of typing “Collection Management System”)

A DAM is usually the generic version of MAM - and sometimes the borders between “is it a MAM? is it a DAM?” are fuzzy and unclear, because they are so closely related.

Typical for “classic” DAMs: Often trimmed and designed for handling “2D material” (documents, images). When it comes to audiovisual, they’re mostly inadequate or not suitable for archive-suitable quality media handling.

MAMs are usually better suited for handling media. For example:

auto-generating access/preview copies suitable for low-bandwidth/internet/browser access.
image area annotation
time based annotation (“markers”)

But watch out! Even systems designed to handle AV media, are often not taking too much care about preservation/archival aspects. It’s not uncommon that “looks/sounds good enough!” is exactly where you’re at.

So please:

Try before you buy!
Don’t trust sales. Ever.

It’s a commitment.

Serious long term. So choose and configure well… 🧙️🌟️

A loooong list of (70+) systems… 😮️

https://bits.ashleyblewer.com/blog/2017/08/09/collection-management-system-collection/

Condensed update (50+)

kb.kulturerbe-digital.at/books/empfehlungen-software/page/vergleich-sammlungsverwaltungssysteme

A short list

of some popular OpenSource CMS:

Not all DAMs are created equal.

Which use-cases was it designed for?
Proper media-type handling? (image, docs, AV?)
Multiple data schemas in parallel?
Local app vs browser-based?
License model?
Setup/maintenance complexity?

CMS Criteria - Examples

Loan/request: Can it manage sending stuff out and getting it back?
- Multilingual: Can it support multiple languages?
- Permissions: For user permissions within the organization, or for the public.
- Physical: Stores physical location of assets?
- Reporting: Exports data/spreadsheets/charts/PDFs for your boss.
- Rights: Can it handle copyright stuff?
- Tasking: Can you assign tasks? Who is working on what?
- Web-Access: Does this come with a public online access portal?
- Batch Edit: Are there ways to change data in ways more significant than one-at-a-time?
- Data Model & Metadata Schema: Can it manage different, rich, shared data models/schemas?
- Collection Management: Can it perform CRUD operations [Create, Read, Update, Delete]?
- DAMs: Suitable as a digital asset management system?
- Ingest: Suitable for packaging materials for preservation (making AIPs)?
- Preservation Storage: Suitable for managing stored materials for long-term digital preservation
- Open Source: Is the software free to use and change?
- Import/Export: Getting data in AND getting data out?
- API: Has an API and/or supports integration with other systems?
- IIIF: “Is there support for the IIIF core APIs (image and/or presentation)? https://iiif.io/technical-details/”
- Support: Can you ask or pay an organization to fix things for you?
- Community: Is there an ability to get support from a user community (peers, not only vendor/provider)?

Basic Features?

Multilingual
Permissions
Physical Location
Reporting
Rights
Web-Access

Advanced Handling?

Batch Edit
Data Model & Metadata Schema
Preservation Storage
Workflow/Task Management
Loan/request

Future Proof & Interoperable?

Open Source
Import/Export
API
IIIF

Who you gonna call?

Paid Support
Community

Language matters.

For tech: English, please? 😇️

All field-names
All tech-terms
Documentation
but: UI and term-labels multi-language

Date and Time Formats

A classic.
Never gets “old”. 😜️

Date Formats

Dates	Times
January 3rd, 1981	13:37
3. Jänner 1981	13:37:00
1/3/1981	0h13m37s
3.1.1981	123.4
1977-11-23-02

Timezones?
Other calendar systems…?

ISO 8601. 🤩️

Date:
1981-01-03
Date & Time (+TZ):
1981-01-03T00:12:34+02:00
Week (+weekday):
2022-W46-5
Duration:
PnYnMnDTnHnMnS

See: (Wikipedia) ISO 8601

Whatever you do, please:

Support iso8601 for date/time input (if possible).
Support exporting/importing iso8601 date/time/duration strings.

You may however, want to be able to at least display date/time also in different formats (configurable).

Why? The “psycho-visual perception” (does it look/feel good?) of people reading ISO8601 syntax is mixed…

Standalone dates: ok. Sometimes cleaner to read than written date. Sometimes not.
Date+Time: rather hard to grasp visually. (Add a timezone and you’ve lost most operator staff)
Duration: Forget it. Hard to read as a person.

Examples:

1981-01-03 (nice) vs January 3rd, 1981 (warmer)
1981-01-03T20:15+01:00 (uck.)

Here’s a link to documents from the US LoC, about rules and extensions for date/time cataloging:

Duration / Period

Support having “from/to” in date fields?
With different, even mixed “precision”?
- “1920-1923”
- “1920-01 - 1923”

Got “Fuzzy” Dates…?

1910-01?
circa 1800?
Bronce age
WWII
etc.

Oh, btw: Got a common syntax?

Partially Approximately Uncertain?

“?”: Uncertain
“~”: Approximate (circa)
“%”: Both uncertain & approximate
“X”: Unspecified.

1981-01?, 20XX, 197X-11?-XX (https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_iso_wd_8601-2_2016-02-16.pdf)

The Identifer

A “must have”. Also known as:

Object ID, Item ID, …
Archive signature
UID: Unique ID
UUID: Universally Unique ID
PID: Persistent ID
…

Everyone’s got one! 😉️

Examples

V-00815
W/S #00034
38AF2EC1A13494B9DF6FD6E75960307
FBW002984
8-717774-330128
adBDwKf_aSE
Q83697636
…

PIDs - Persistent Identifiers

Example: NHMW-ZOO-FS50750

“[PIDs] provide [means for offering] a long-lasting click-able link to a digital object.”

(Source: https://tanc-ahrc.github.io/HeritagePIDs/

PIDs - Infos

ID Requirements

Unique? Persistent?
Stable syntax?
Recognizable?
Scope?
Filename-safe?
Printable? (QR- or barcode label)

DAM-handle it?

Auto-generate?
Increment?
Validate?
More than 1 syntax?

Common terms?

“We’ve always called it that way, so it’s clear.”

Person, Company, Actor or: Agent?
Recording, Film, Video or: MovingImage?
Action, Shooting or: Event?
Author or: Creator?
etc.

Can you re-label terms in the UI?

I’m very sure, most use-cases are not unique. As said before: If someone else is collecting and cataloguing and managing similar items or has similar use-cases, please get in contact with each other.

But: As great as sharing and using common CoVocs is, it brings the “problem” that you need to agree on common terms. :)

This can sometimes be trivial, and otherwise be non-trivial - and even very emotional. Practically, a major issue is often that different domains have different terms in their professional vocabularies already - which are (or may be) mis-interpreted or confusing for other domains.

“But we call it ‘…’ - and calling it ‘…’ may completely confuse our operators”

Example: The term “Agent” ;)

Be ready for trade-offs. Be ready to use different, but now common, terms.

Controlled Vocabularies

“Controlled vocabulary schemes mandate the use of predefined, authorised terms that have been preselected by the designers of the schemes, in contrast to natural language vocabularies, which have no such restriction.”

Source: “Controlled Vocabulary” (Wikipedia)”

Why CoVocs / Taxonomies?

Same-same 😇, but different… 😭

35mm = 35 mm = 35 millimètre
dup pos = duplicate positive
de = deu = german = German = alemán
yuv422p10le = YUV, 4:2:2, 10 bpc
Director = Directed by = Regisseur = Regie

Handling CoVocs

Clear choice/definition of terms?
Standard terms? (e.g. ISO mapping for Language, Country, Region, Tech-Terms, etc.)
Keyboard shortcuts to select specific terms?
Nested hierarchies?!
Maintaining / augmenting terms?
Identifier vs Label?

Identifier & Label

Can the MAM store & handle this properly?

Identifier(for machines)	Label(for humans>)	Translations?
`sq`, `sqi`, `alb`, …	Albanian	Albanisch^(de), Albanais^(fr)
`de`, `deu`, `ger`, …	German	Deutsch^(de), Allemand^(fr)
`und`	Undetermined	…?

Examples: ISO 639 (Languages), ISO 3166 (Countries),…

Shared CoVocs

Same vocabulary terms/lists can be used across different systems/domains.
Use existing CoVocs where possible.
Share/publish yours.
Be in contact/exchange with others.
Be ready for embracing trade-offs.

Dynamic CoVocs

How does your DAM deal with:

Adding new terms (on the fly)?
Editing terms that have already been assigned…? 😱️
Import / export lists?

Shared Identifiers

If you’re not the only one referring to …

Wouldn’t it make sense to have a common, shared identifier?

Handling Multiple IDs?

Add attribute option declaring “which” identifier:

<id schema="dnb"> ... </id>
<id schema="efg"> ... </id>
<id schema="wikidata"> Q84199 </id>

Wikidata

“[…] is a free and open knowledge base that can be read and edited by both humans and machines.”

Example: Earth (Q2) vs Earth (Q83697636)

Data Structure Matters

“classical” catalogue = flat, table/cell thinking.

Better: Identify Entities and Attributes.
Then: Identify Relationships (and their “@”)
Entity Relationship Model (ERM)
Think in “Semantic Triples”:
Subject - Predicate - Object

Example elgrito.witness.org

Relationships

Forward: Agent1 is parent of Agent2
Reverse: Agent2 is child of Agent1

Annotating relationships

For which time-period was the relationship valid? (Agent “married to” Agent)
Anything else you’d like to add?

Relationship queries?

(How well) can a system handle/search relationship-details?

Which Work(s) feature which Agent(s) under the alias of …?
List all … related to a work, in order of their …?

More than just 1 standard/schema?

Great! Now what about the “film-related” materials? 🤨️ (posters, documents, etc)

Import / Export

Import / Export: Considerations

(Nested) Lists & CoVocs?
Link cataloguing data (DB) & files? (storage)
Programming language skills required?
Value/term/schema mapping options?
Metadata layout (schema) valid?

Reference between Catalogue and Files

How are catalogue entries related to files (and vice-versa)?
How (in)dependent of the catalogue can files be used/modified?

Filename & Folder structure

Many DAMs do that automatically.
In a non-human readable layout (UUIDs).
Which level of control do you need over this?
Got external workflows accessing the files/data?

Files intact, but DAM gone?

Access & Control

(Web) APIs: Application Programming Interfaces
REST API:
OAI-PMH: Protocol for Metadata Harvesting
…

APIs: Whatfor?

Access & exchange your data…

… with other institutions.
… by external tools.
… for backup/migration.
… to use your data differently.
etc.

APIs: Whatfor?

Remote Control!

Common backend + different UIs.
Automate workflows/actions externally.
etc.
And: Simply (more) future-proof. 😎️ 🤓️

Does it scale?

Ask experienced tech staff.

Speed? (search, retrieve, data, files, etc)
Cache & tuning options?
Synchronize multiple instances?
Ongoing import/export? (in-house, external)
License conditions and impact?
Multiple data schemas in parallel?
Multi-language support?
Migration to a “better scaling” system when needed?

Got Plugins?

Usually an all-in-one monolith is rigid and hard to maintain.
Preferred: Slim core + additional features as plugins.
Necessary: Plugin interfaces open & documented.

Got Support?

Whom to call in case of …?
Option to switch/choose “your mechanic”?
Under which conditions?
Support contracts?
Which license model?
Train your staff?
Proper documentation?

Good practice

Get access to a demo installation (local or online).
Try to import/export lists/CoVocs.
Consider import/export/ui-feel with your data (layout). (Before you make any final choice)
Get cataloguers & technicians together.
Get help from experts with your tool-choice/use-cases.
As simple as possible, as complicated as necessary.

Have a disaster-plan ready.

Backups?
Failover system?
Got support contracts?
Aware of migration requirements?

The End

Questions?

Comments?

Peter Bubestinger-Steindl

info@kulturerbe-digital.at peter @ ArkThis.com

Oh, btw: “Says who?”

Declare information sources?
At which level? (record? field?)
Who edited which field when and why?
Could a source be “linked”? (as relationship)
What if you have ≥ 1 sources?

Oh, there’s a typo…

Should we correct it?
Is it even a typo, or was it proper “back then”?
Can we keep multiple “versions”?
(Where) can we document that? (commit msg)

Collection Management Systems - Considerations.

Managing Digital Assets

Preservation Collection Digital Asset Management Systems?

Puh. Where to begin?

It’s a commitment.

A loooong list of (70+) systems… 😮️

Condensed update (50+)

A short list

Not all DAMs are created equal.

CMS Criteria - Examples

Basic Features?

Advanced Handling?

Future Proof & Interoperable?

Who you gonna call?

Language matters.

Date and Time Formats

Date Formats

ISO 8601. 🤩️

Duration / Period

Got “Fuzzy” Dates…?

Partially Approximately Uncertain?

The Identifer

Everyone’s got one! 😉️

Examples

PIDs - Persistent Identifiers

PIDs - Infos

ID Requirements

DAM-handle it?

Common terms?

Controlled Vocabularies

Why CoVocs / Taxonomies?

Handling CoVocs

Identifier & Label

Shared CoVocs

Dynamic CoVocs

Shared Identifiers

Handling Multiple IDs?

Wikidata

Data Structure Matters

Relationships

Annotating relationships

Relationship queries?

More than just 1 standard/schema?

Import / Export

Import / Export: Considerations

Reference between Catalogue and Files

Filename & Folder structure

Files intact, but DAM gone?

Access & Control

APIs: Whatfor?

APIs: Whatfor?

Does it scale?

Got Plugins?

Got Support?

Good practice

Have a disaster-plan ready.

The End

Questions?

Comments?

Oh, btw: “Says who?”

Oh, there’s a typo…