Digital-Asset-Management

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Digital-Asset-Management (DAM) ist die 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[Bearbeiten | Quelltext bearbeiten]

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

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, wie Dokumente aus verschiedenen Programmen, Videos, Animationen etc.

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, Produkt-Informations-Management-Systeme und Web2Print-Systeme.

Während ältere DAM-Systeme vor allem als Behälter für Media Assets verstanden wurden, werden moderne Systeme vor allem auch zur Produktion von Mediendateien 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).

Metadaten[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

IPTC (IPTC-IIM und IPTC Core)[Bearbeiten | Quelltext bearbeiten]

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

Exif[Bearbeiten | Quelltext bearbeiten]

Das Exchangeable Image File Format ist der verbreitetste Standard zur Verwaltung von Digitalbildern.[2] 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.

ID-3[Bearbeiten | Quelltext bearbeiten]

Der ID-3-Tag[3] wird meist bei Musikdateien verwendet. Insbesondere bei MP3-Dateien stellt er den Standard dar.

Volltext[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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.

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, da damit der Entwicklungsaufwand zur Integration und die Projektlaufzeiten reduziert werden können und der Aufwand zur Wartung bei Updates sinkt.[4][5]

Metadaten in Assets vs. Metadaten in der Datenbank[Bearbeiten | Quelltext bearbeiten]

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.[6][7][8]
  • In der Regel weniger performant, da immer wieder Schreibzugriffe 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[Bearbeiten | Quelltext bearbeiten]

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[9]" der schwedischen Firma Hasselblad, Canto Cumulus und später die "Fotostation" des norwegischen Unternehmens Fotoware.

Client-Server-Generation[Bearbeiten | Quelltext bearbeiten]

Derartige Lösungen wurden häufig 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.

Vom Client zur Browseranwendung[Bearbeiten | Quelltext bearbeiten]

Die Generation der DAM-Systeme, die Anfang des Jahrtausends 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-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.

Vom Monolithen zur SOA-Architektur[Bearbeiten | Quelltext bearbeiten]

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[10]. 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.

Einsatzbereiche[Bearbeiten | Quelltext bearbeiten]

  • Musikindustrie z. B. zur Speicherung von Musikstücken zur Weiterverarbeitung
  • Druckindustrie zur Verwaltung von Layouts, Kundenlogos, Bildern, Fotos etc.
  • 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
  • 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.[11]
  • Forschungsdatenrepositorien

Artikel zu Digital-Asset-Management-Lösungen[Bearbeiten | Quelltext bearbeiten]

Name Hersteller Betriebssystem ca. Kosten Sprache Bemerkungen
Canto Cumulus Canto Microsoft Windows, macOS, Linux ab 10.000 € multilingual Client-Server-System und browserbasiert; Cloud-Erweiterung; Plugins für Adobe Drive, Microsoft Office, CMS, ERP, PIM, ECM, E-Commerce, Video, SAP. SaaS basiert auf Amazon Webservice Cloud.
censhare censhare AG Microsoft Windows, macOS, Linux k. A. multilingual Lauffähig als Cloud-, SaaS- oder On-Premise-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
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 Extention
Phraseanet Alchemy LAMP Open Source (GPLv3) multilingual Browserbasiert
Pic2base Klaus Henneberg LAMP Open Source multilingual Browserbasiert
Pimcore Pimcore GmbH LAMP Open Source (GPL) multilingual Browserbasiert / PIM/MDM/CMS/DAM/Commerce / PHP API
ResourceSpace Montala Limited LAMP Open Source (BSD-Lizenz) multilingual Browserbasiert

Siehe auch[Bearbeiten | Quelltext bearbeiten]

Literatur[Bearbeiten | Quelltext bearbeiten]

  • 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[Bearbeiten | Quelltext bearbeiten]

  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 Ltd., 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. 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.