Digital-Asset-Management

Digital-Asset-Management (DAM) bezeichnet Softwareanwendungen zur Speicherung und Verwaltung von beliebigen digitalen Inhalten, insbesondere von Mediendateien wie Grafiken, Videos, Musikdateien und Textbausteinen. Im medialen Bereich wird es teilweise auch als Media-Asset-Management (MAM) bzw. im Spezielleren als Video-Asset-Management (VAM) bezeichnet. Es gehört zum Bereich der Content-Management-Systeme.

Typische Funktionen

Hauptfunktionen in klassischen Digital-Asset-Management-Systemen sind:

• Import und Export von Dateien, ggf. mit Formatkonvertierung
• Anreichern von Binärdateien mit Metainformationen zu Recherchezwecken (z. B. IPTC-IIM-Standard)
• Suchen von Dateien anhand von Metadaten, Dateinamen oder sonstigen Eigenschaften
• Anzeigen, Sichten (ggf. Anhören und Ansehen) von Dateien
• Kombinieren von Dateien zu Paketen (meist als Sammlungen, Kollektionen, Alben bezeichnet)
• Archivieren und Versionieren von Dateien
• Bereitstellung eines oft „Brand Portal“ oder „Presseportal“ genannten Webportals, über das Werbeagenturen, Verlage, Journalisten sowie die Mitarbeiter und Händler eines Unternehmens aktuelles Bild- oder Werbematerial selbst herunterladen können.

Digital-Asset-Management kann manuell oder automatisiert angesprochen werden. Manche Systeme sind auch für externe Lieferanten oder Dienstleister zugänglich, damit ein einfacher Austausch der Daten im Rahmen der Produktion schneller möglich ist. Im Gegensatz zu einer Bilddatenbank können mit einem MAM/DAM-System nicht nur Bilder verwaltet werden, sondern alle Arten von Dateien, d. h. sogenannte Assets jeder Art, beispielsweise Dokumente aus verschiedenen Programmen, Videos, Animationen.

Das Digital-Asset-Management kann aus verschiedenen Einzelkomponenten, Rechnern, Speichersystemen usw. zusammengestellt sein.

Die verbreitetsten Architekturen bestehen aus entweder einer Datenbank oder einem Indexer und einer lokal installierten Anwendungssoftware oder einer Oberfläche im Webbrowser. Die Tendenz der meisten Hersteller geht dabei zu einer relationalen Datenbank und Browser-Frontends.

DAM-Systeme werden meist angeboten zur Installation auf Server-Hardware vor Ort oder als SaaS-Dienst, letzterer entweder in einer Private Cloud oder Public Cloud, was erhebliche Auswirkungen auf den Schutz der verwalteten Daten haben kann.

Bei neueren DAM-Systemen stehen Funktionen zur Integration im Unternehmensumfeld im Vordergrund, zum Beispiel die Bereitstellung von Assets in Content-Management-Systeme, Webshop-Systeme, Produktinformationsmanagement-Systeme und Web2Print-Systeme.

Während ältere DAM-Systeme vor allem als „Behälter“ für Media Assets verstanden wurden, werden moderne Systeme auch zur Produktion von Mediendateien und Werbemittel sowie auch zur Steuerung von Publikationsprozesse verwendet. Dafür werden verbreitete Anwendungs- bzw. Autorenprogramme wie Microsoft Office, die Adobe Creative Suite, Videoschnittsysteme und andere entweder über Verlinkung oder zusätzlich zu installierende Addons angebunden. Im Vordergrund steht dabei die Funktion, Dateien zur Bearbeitung aus dem DAM-System zu laden (meist als „Auschecken“ bezeichnet), zu bearbeiten und wieder zu importieren (meist als „Einchecken“ bezeichnet). Einige Anbieter integrieren auch Prozesssteuerung-Funktionen wie etwa Korrekturmanagement, Freigabemanagement oder Lizenzrechteverwaltung.

Metadaten

Alle heute verbreiteten Betriebssysteme verwalten Dateien in einer rein hierarchischen Verzeichnis- bzw. Ordnerstruktur. Damit ist die Abbildung der vielfältigen Eigenschaften von Mediendateien nur hierarchisch und damit nur sehr eingeschränkt möglich, da Verzeichnis- und Dateinamen nur eine weitgehend unkontrollierte Eingabe nur weniger Eigenschaften erlauben:

• Die bei normaler Benutzung auftretenden Tippfehler machen eine vollständige, maschinenlesbare Auswertung von Datei- und Verzeichnisnamen zunichte.
• Es kann keine Liste von wünschenswerten Begriffen – ein sogenanntes „kontrolliertes Vokabular“ verwendet werden, in dem die zu verwendenden Begriffe und Schreibweisen festgelegt sind.
• Die Ablage von Dateien ist in der Regel nur in einer einzigen Verzeichnishierarchie möglich. Werden Bilder von Gebäuden beispielsweise in einer Verzeichnishierarchie abgelegt, die sich an geografischen Begriffen wie den Namen von Kontinenten, Ländern, Städten etc. orientiert, fehlt die Möglichkeit, weitere Eigenschaften eindeutig festzulegen, z. B. die Art des Gebäudes, Material, Architekt, Kosten, Zustand etc.
• Um diese Schwächen auszugleichen, wird häufig mit Dateinamenskonventionen gearbeitet, deren Einhaltung jedoch bereits selbst in kleinen Arbeitsgruppen ein disziplinarisches Problem darstellt.
• Ebenso werden häufig Dubletten von Dateien erzeugt, um sie über ihren Ablageort mit weiteren Eigenschaften zu versehen. Beispielsweise wird ein häufig verwendetes Logo oft in Ordnern mit abgelegt, die alle Bestandteile eines Auftrags zur Werbemittelproduktion enthalten.

Um diese Schwächen zu beheben, verwenden alle gebräuchlichen DAM-Systeme Metadaten.

Ein wesentlicher Bestandteil moderner DAM-Systeme sind kontrollierte Vokabulare. Um die Eingabe von Metadaten zu vereinfachen, einheitliche Begriffe durchzusetzen und Tippfehler zu vermeiden, werden feldweise oder feldübergreifend Listen oder Kataloge angelegt, in denen die erlaubten oder erwünschten Begriffe aufgeführt werden. Die Hersteller der einzelnen DAM-Systeme gehen dabei in der Struktur der Metadaten als auch in der Bedienung sehr unterschiedliche Wege, von einfachen Listen, die feldweise hinterlegt werden, bis zu feldübergreifenden Thesauren und Taxonomien, automatischen Vorschlägen und mehrsprachigen Thesauren, die für den Benutzer bei der Eingabe von Begriffen in einer Sprache quasi eine automatische Übersetzung vieler Begriffe in mehrere Sprachen durchführen.

Metadaten-Standards

Als Metadaten-Standard bezeichnet man im Zusammenhang mit DAM-Systemen eine festgelegte Norm, mit der Metadaten strukturiert und eindeutig verwaltet werden können. Bestandteil dieser Norm sind eine technische Umschreibung und eine Anzahl von Feldern. Die technische Umschreibung beinhaltet das Dateiformat einer Metadaten-Datei oder die Einbettung von Metadaten in die zu beschreibenden Dateien. Mit Feldern sind meist Felder im Sinne von Datenbankfeldern gemeint, die wiederum Eigenschaften haben, beispielsweise, dass sie als Datumsfeld oder als Textfeld verwendet werden.

Verbreitete Metadaten-Standards in DAM-Systemen

IPTC (IPTC-IIM und IPTC Core)

Die ersten DAM-Systeme bezeichnete man als Bilddatenbank-Systeme; die Verwendung anderer Dateiformate spielte in früheren Jahren keine Rolle. Dementsprechend unterstützen DAM-Systeme fast immer den 1991 definierten IPTC-IIM-Standard, heute meist im etwas moderneren XMP-Format in Form von IPTC Core. IPTC Core beinhaltet dabei im Wesentlichen die seit der Frühzeit der Systeme üblichen Felder.

Exif

Das Exchangeable Image File Format ist der verbreitetste Standard zur Verwaltung von Digitalbildern. Beinahe jede Digitalkamera schreibt in Form von Exif-Daten in ihre Bilddateien technische Bildinformationen, beispielsweise die verwendete Blende, Belichtungszeit oder die ISO-Einstellung. Die meisten DAM-Systeme lesen die Exif-Informationen aus und können sie darstellen. Für die Organisation von Mediendateien in den klassischen Anwendungsbereichen spielt Exif jedoch keine Rolle.

ID3

Der ID3-Tag wird meist bei Musikdateien verwendet. Insbesondere bei MP3-Dateien stellt er den Standard dar.

Volltext

Viele moderne DAM-Systeme extrahieren aus texthaltigen Dateien wie z. B. PDFs, Microsoft-Word-, Powerpoint-, Excel-, OpenOffice-Dateien den enthaltenen Text und speichern ihn in der Datenbank, um ihn wie sonstige Metadaten zur Volltextsuche zu verwenden. Einige produktionsnahe Systeme bieten ähnliche Funktionen auch für Dateien aus Programmen wie Adobe InDesign. Meistens werden zudem auch von der Titelseite oder allen Seiten solcher Dokumente Vorschauen unterschiedlicher Größen erzeugt, die einen visuellen Eindruck vom Inhalt vermitteln.

Metadaten-Standards aus anderen Anwendungsgebieten

Im Vordergrund von DAM-Projekten in Unternehmen steht heute vor allem die Integration in die vorhandene Systemlandschaft. Das bedeutet, dass DAM-Systeme mit ERP-Systemen, Webshops und anderen Systemen verbunden werden. Dadurch spielen Metadaten aus anderen Anwendungsgebieten heute in Projekten oft eine ebenso große Rolle wie die traditionellen Metadaten-Standards.

Bei Installationen in Industrie- und Handelsunternehmen spielen dabei vor allem eine Artikelnummer und mitunter auch weitere intern verwendete Identifikationsnummern eine Rolle. Das Ziel besteht dabei immer darin, einen durchgängigen Metadatenbestand in allen Systemen zu haben, vom ERP-System über Produktionssysteme bis hin zum Webshop, zum Content Management System und zur Katalogproduktion. Es gibt dadurch gelegentlich funktionale Überschneidungen zwischen PIM-Systemen, von denen einige auch einfache Funktionen eines DAM-Systems bieten, und DAM-Systemen, von denen wiederum einige auch PIM-Funktionalitäten zum Produktdatenmanagement enthalten. Die Durchgängigkeit von Identifikationsschlüsseln und Metadaten soll die Aktualität und Richtigkeit der Daten sicherstellen und die Fehlerquoten verringern.

Wichtige Metadatenstandards in DAM-Projekten sind zum Beispiel:

• EAN, die European Article Number; dieser Begriff ist veraltet, wird aber häufig noch verwendet. Seit 2009 lautet die Bezeichnung Global Trade Item Number (GTIN, Globale Artikelidentifikationsnummer), eine international unverwechselbare Produktkennzeichnung für Handelsartikel.
• ISBN, die Internationale Standardbuchnummer

Die Vielfalt der insbesondere in industriellen Anwendungen verwendeten Metadaten ist enorm und reicht von EDIFACT mit seinen zahlreichen Subsets über die Typgenehmigung eines Kraftfahrzeugs oder den Erzeugercode von Hühnereiern bis zu hauseigenen Kodierungen, die ein Unternehmen nur intern für seine Kunden, Lieferanten, Produkte oder Ersatzteile verwendet. Dementsprechend spielt es heute in den Anforderungen an DAM-Systeme eine wesentliche Rolle, jenseits der traditionellen Metadaten-Standards virtuos mit unterschiedlichsten Metadaten umgehen zu können. Manche DAM-Systeme bieten dafür eigens Plugins oder Module zur Verbindung mit bestimmten Drittsystemen an oder verfügen über eine umfangreiche Programmierschnittstelle. Bei Systemen mit einer modernen serviceorientierten Architektur geht der Trend hin zur Verwendung von Standard-Webdiensten wie SOAP, weil damit der Entwicklungsaufwand zur Integration und die Projektlaufzeiten reduziert werden können und der Aufwand zur Wartung bei Updates sinkt.

Metadaten aus einer Bildanalyse

In den aktuellen Versionen heutiger DAM-Systeme findet sich häufig eine Funktion zum Auffinden von Bildern und ähnlichen Dateien auf der Basis einer Bildanalyse (Content Based Image Retrieval). Dabei wird ohne das Vorhandensein von Metadaten über den Bildinhalt erkannt, ob Bilder sich ähneln oder identisch sind. Der Trend geht hin zum „Autotagging“. Unter diesem neuen Begriff verstehen die Hersteller das automatische Zuordnen von Schlagworten zu Bildern anhand des Bildinhalts ohne menschliches Zutun.

Diese Verfahren sind relativ neu und erweisen sich in der Praxis oft als bereits brauchbar für allgemeine Bilder, aber verbesserungsfähig für spezielle Fachthemen. Daher geht der Trend hin zu auf maschinellem Lernen basierenden Verfahren, die die Metadaten eines vorhandenen Datenbestands verwenden, um neu hinzukommende, ähnliche Bilder besser zuzuordnen.

Metadaten in Assets vs. Metadaten in der Datenbank

Die Grundidee des aus dem Presse- und Nachrichtenagenturwesen stammenden alten IPTC-IIM-Standards ist, ein Foto direkt mit Metadaten zu versehen, so dass die Metadaten dem Empfänger als Bestandteil einer Bilddatei mit übertragen werden. Dies geschieht dadurch, dass ein separater Block in die Bilddatei hineingeschrieben wird. Dieses Konzept hat Vor- und Nachteile.

Vorteile:

• Der Empfänger erhält alle Metadaten mit einem Bild und muss sie nicht separat sichten. Bedingung dafür ist, dass er Software verwendet, die die Metadaten aus dem Header auch darstellen kann.
• Fällt das DAM-System unter Verlust aller in dessen Datenbank gespeicherten Metadaten aus, können die Metadaten aus den Assets wiedergewonnen werden.

Nachteile:

• Eine nachträgliche Aktualisierung von Metadaten, die in Assets geschrieben wurden, ist nach der Übertragung nicht mehr möglich.
• Es können unabsichtlich Daten übertragen werden, die dem Empfänger nicht zugänglich sein sollen. Dazu gehören beispielsweise Honorardaten, Bankverbindungen etc.
• Es können Daten übertragen werden, die unerwünscht Rückschlüsse auf den Autor bzw. Fotografen zulassen. Beispiel: zu den Metadaten, die als Teil des EXIF-Headers automatisch in digitalen Fotos eingetragen werden, gehören auch die Seriennummer der Kamera und oftmals die GPS-Position. Dies kann für Fotografen, die in Krisenregionen oder Ländern mit eingeschränkter Presse- und Meinungsfreiheit erhebliche Gefahren mit sich bringen.
• In der Regel weniger performant, da immer wieder Lesezugriffe auf Dateien durchgeführt werden müssen.

Dem gegenüber können Metadaten auch lediglich in der Datenbank des DAM-Systems gespeichert und verwaltet werden. Auch dieses Konzept hat Vor- und Nachteile.

Vorteile:

• Keine unerwünschte Weitergabe von Informationen
• Performant

Nachteile:

• Werden Dateien weitergegeben, sind Metadaten nicht enthalten.

Bei modernen DAM-Systemen ist eine Kombination aus beiden Verfahren üblich. Die praktische Umsetzung folgt dabei sehr unterschiedlichen Ansätzen und reicht von praxisnah bis kompliziert.

Systemarchitektur

Seit den Anfängen der ersten Bilddatenbanksysteme als Vorgänger der heutigen DAM-Systeme Anfang der neunziger Jahre hat sich die IT-Welt stark verändert. Daraus ergaben sich immer wieder Überarbeitungen der Architektur von DAM-Systemen. Die ersten Anwendungen in den Jahren 1992–1994 waren Programme für einzelne Anwender wie zum Beispiel „Pixolo“ der schwedischen Firma Hasselblad, Canto Cumulus und später die „Fotostation“ des norwegischen Unternehmens FotoWare.

1. Generation: Client-Server-Architektur

Derartige Lösungen wurden in den 1990er Jahren zu Client-Server-Systemen erweitert. Die meisten Systeme basierten dabei nicht auf den heute üblichen SQL-Datenbanken, sondern auf proprietären Anwendungen zum Management von Indexen wie zum Beispiel dtSearch, die eigentlich zum Dokumentenretrieval, genauer gesagt zur freien Suche in großen Textmengen dienen und Ähnlichkeit mit heutigen Suchmaschinen hatten. Durch die gegenüber einer relationalen Datenbank mit ihren exakt definierten Felddefinitionen recht unstrukturierte Datenhaltung gilt diese Art der Architektur heute als veraltet und wird nur noch in sehr wenigen Systemen angewandt. In manchen Systemen finden sich noch Überreste dieser Systemgeneration, z. B. durch die Kombination einer relationalen Datenbank mit einer Suchmaschinen-Software.

2. Generation: vom proprietären Client zur Browseranwendung

Die Generation der DAM-Systeme, die Anfang der 2000er Jahre diesen heute überholt erscheinenden Ansätzen folgte, zeigte einen klaren Trend hin zu browserbasierenden Systemen. Der Vorteil gegenüber den frühen Einzelanwenderprogrammen und den nachfolgenden Client-Server-Architekturen lag vor allem darin, dass keine Softwareverteilung von Client-Anwendungen mehr notwendig ist und eine zentrale Datenhaltung erzwungen werden kann. Die zu dieser Zeit auch für andere Anwendungen gebräuchliche Architektur sah meist vor, eine Applikation im Webserver mittels PHP oder über .Net-Framework-Technologien mit einer Datenbank zu verbinden. In vielen Systemen dieser Generation werden die zum Zeitpunkt der Systementwicklung noch sehr geringen Fähigkeiten der Webbrowser zur Darstellung multimedialer Inhalte durch zusätzliche Technologien ergänzt – beim Woodwing Elvis DAM beispielsweise Adobe Flash, bei den FotoWare-Systemen Apple Quicktime. Unter den bekannteren Systemen benutzen lediglich Canto Cumulus, Extensis Portfolio und FotoWare heute noch Client-Software.

3. Generation: vom Monolithen zur SOA-Architektur

Die Aufgabenstellung für DAM-Systeme war anfangs überschaubar, wuchs jedoch mit den Jahren immens. Zur reinen Verwaltung von immer neuen Dateitypen, immer höheren Anforderungen an die Interoperabilität und einer exponentiell wachsenden Anzahl an zu verwaltenden Dateien kam der Wunsch der Kunden, immer mehr Arbeitsschritte zu automatisieren. Die dadurch folgenden Skalierungen und Funktionserweiterungen führen zunehmend zu Problemen, da die monolithische Architektur der meisten etablierten DAM-Systeme Zusatzentwicklungen kompliziert machen kann. Die Anbindungen an andere Systeme, die meist auf der Basis proprietärer APIs der Hersteller entwickelt wurden, müssen bei Updates häufig kostspielig erneuert oder vollständig neu entwickelt werden.

Aus diesem Problem entstand der neue Ansatz, statt einer monolithischen Architektur mit proprietären APIs eine serviceorientierte Architektur aufzubauen, bei der standardisierte Webdienste wie SOAP und REST nicht nur nachträglich hinzugefügt und im Sinne der proprietären APIs benutzt werden, um einfache Abfragen zu ermöglichen, sondern sind quasi der Hauptbestandteil des Systems, um Verbindungen innerhalb des Systems und zu anderen Systemen herzustellen. Diese Architektur ermöglicht eine starke Skalierung der darauf aufbauenden Systeme, eine erheblich leichtere Entwicklung von Schnittstellen zu anderen Systemen, erhöht die Sicherheit bei Updates und vereinfacht die Wartung. Die offene Systemarchitektur ermöglicht eine sichere Integration von Unternehmensanwendungen und Systemen wie z. B. PIM, CMS, E-Commerce-Anwendungen oder ERP-Systemen.

Einsatzbereiche

• Musikindustrie z. B. zur Speicherung von Musikstücken zur Weiterverarbeitung
• Druckindustrie zur Verwaltung von Layouts, Kundenlogos, Bildern, Fotos etc.
• Verlage zur Verwaltung der Medien und Steuerung der Produktionsprozesse
• Marketing- oder Presseabteilungen in Firmen der werbenden Wirtschaft, NGOs etc.
• Presse- und Rundfunkarchive
• Informations- und Dokumentationszentren
• Filmprojekte
• CG- und Animationsprojekte (3D-Modellierung)
• Firmen- bzw. Unternehmensarchive
• Marketingportale im B2B- bzw. B2C-Bereich zur Verwaltung der Medien (Bilder, Videos etc.) und Steuerung der Werbemittelproduktion sowie um die Produktkommunikation zu verbessern, in Verbindung mit Produktinformationen.
• Speicherung und Organisation von Daten bilderzeugender Systeme in der Medizin; der Begriff „DAM-System“ wird in der Medizin eher selten verwendet, dort ist meist die Rede von PACS-Systemen, die mit Metadaten- und Übertragungsstandards wie DICOM, HL7 und IHE arbeiten.
• Forschungsdatenrepositorien

Artikel zu Digital-Asset-Management-Lösungen

Name	Hersteller	Betriebssystem	ca. Kosten	Sprache	Bemerkungen
Canto Cumulus	Canto	, ,	ab 10.000 €	multilingual	Seit 1992. Client-Server-System und browserbasiert; Zwei Produkte: OnPremise Cumulus (Cumulus is no longer supported/sold), Cloud/SaaS (Canto); Plugins für Adobe Drive, Microsoft Office, CMS, ERP, PIM, ECM, E-Commerce, Video, SAP. SaaS basiert auf Amazon Webservice Cloud.
cavok	PEAK-14	, ,	ab 10.000 €	multilingual	Browserbasiert, SOA-Architektur (Kern des Systems ist ein SOAP/REST-Webservice), Schwerpunkt auf Integration und Automation mit ERP, CMS, PIM, Webshops etc., scriptfähig, Adobe InDesign-Plugin. On-Premise oder SaaS (in Deutschland gehostet), Ähnlichkeits- und Dublettensuche, Audio- und Videokonvertierung und -Streaming.
CELUM	Celum GmbH	, ,	SaaS ab € 34,90 pro Monat und User	multilingual	Verfügbar als Cloud-, SaaS Lösung. Browserbasierter Client. Connectoren für Adobe CC, SAP Hybris, ERP, PIM, CRM, CMS, Social Media via HootieSuite, eCommerce.
censhare	censhare AG	, ,	k. A.	multilingual	Lauffähig als Cloud-Lösung; Browserbasiert und nativer Client (macOS, Windows, Linux); PlugIns für Adobe InDesign und InCopy; Schnittstellen zu WCM, ERP, PIM, CRM, Social Media (Facebook, Twitter, YouTube), Web-Analytics (Google Web Analytics), Video-Transcoding (Amazon Transcoder, Sorenson Squeeze Server)
easydb	Programmfabrik GmbH	LAMP	k. A.	multilingual	Browserbasiert. Seit 2003 erhältlich. Basiert auf PostgreSQL und der Indexierungs-Engine Elasticsearch.
eyebase	CMB GmbH	LAMP	SaaS ab € 40.- pro Monat, Lizenz ab ca. 3000 €	multilingual	Verfügbar als Cloud-, SaaS- oder On-Premise-Lösung; Browserbasiert; PlugIn für Adobe InDesign; Schnittstellen zu WCM, ERP, PIM, CRM, Social Media (Facebook, Twitter, YouTube), kompatibel mit Amazon S3 oder Google Drive, eyeSync als eigene Dropbox Extension
Phraseanet	Alchemy	LAMP	Open Source (GPLv3)	multilingual	Browserbasiert, vor allem in Frankreich verbreitet. Basiert auf der Indexierungs-Engine Elasticsearch.
Pimcore	Pimcore GmbH	LAMP	Open Source (GPL)	multilingual	Browserbasiert. Eigentlich ein PIM-System mit einigen DAM-Anteilen. Module auch für CMS und Commerce
ResourceSpace	Montala Limited	LAMP	Open Source (BSD-Lizenz)	multilingual	Browserbasiert; nur Bild-, Video- und PDF-Verwaltung, verwendet nur IPTC/XMP/EXIF
Pixx.io	Pixx.io GmbH	, ,	SaaS ab € 9.- p.P./Monat	deutsch, englisch	SaaS Lösung, unterstützt 190 verschiedene Datei-Formate, Integrationen: Shopify, ConHootsuite, Akeneo, Adobe Photoshop, Indesign, Canva, Contentbird, Contentpepper, Imory, Microsoft Office, Neos, TYPO3, WordPress

Siehe auch

• Bilderverwaltung
• Cross Media Publishing

Literatur

• Erich Koetter: Datenharmonisierung als Grundlage für die optimale Mediennutzung. MAM-Studie 2010. Chmielorz Verlag, Mötzingen 2010, ISBN 978-3-87124-349-3.

Einzelnachweise

1. Andrea Trinkwalder: IPTC und XMP. In: c't. Heise-Verlag, 13. August 2009, abgerufen am 4. Oktober 2016. 
2. Michael J. Hußmann: Was sind EXIF-Daten? In: Website. digicam-experts, abgerufen am 4. Oktober 2016. 
3. Dan O’Neill: ID-3 Introduction. Dan O’Neill, 17. Dezember 2013, abgerufen am 4. Oktober 2016 (englisch). 
4. Peter Hausken, Paul Heisholt: Integrating DAM in the enterprise architecture. In: Journal of Digital Asset Management. Vol. 2. Palgrave Macmillan, Januar 2006, S. 282. 
5. David Austerberry: Digital Asset Management. Hrsg.: Focal Press. 2. Auflage. Focal Press, New York / London 2013, ISBN 978-1-136-03362-9, S. 99 ff. 
6. Herbert Bos, Fabian Monrose, Gregory Blanc (Hrsg.): Research in Attacks, Intrusions, and Defenses: 18th International Symposium RAID 2015. Springer, Heidelberg Januar 2015, S. 441. 
7. Haitao Xu, Haining Wang, Angelos Stavrou: Privacy Risk Assessment on Online Photos. (PDF) Abgerufen am 4. Oktober 2016 (englisch). 
8. Hints and Tips for Whistleblowers - Photo Image Files. Spy Blog, 11. Juni 2011, abgerufen am 4. Oktober 2016 (englisch). 
9. Kurt K. Wolf: Das Electronic Picture Desk bewährt sich im praktischen Einsatz des Zeitungsbetriebs. HZW für Crossmedia Management, 1994, abgerufen am 5. Oktober 2016. 
10. Refatoring a Monolith. Abgerufen am 7. Oktober 2016 (englisch). 
11. Was ist ein PACS? In: itz-medi.com. ITZ Medicom, 13. Juli 2012, abgerufen am 4. Oktober 2016.