Texte und Bilder, die Redaktionen von extern zugeliefert bekommen – hauptsächlich von Nachrichten- und Bildagenturen – werden digital und meist mit guten Metadaten angeliefert. Der Weg in die Produktionssysteme des Verlags erfordert aber oft zu viel Handarbeit, und es gehen Metadaten dabei verloren. Das liegt daran, dass die Software im Verlag technische Beschränkungen hat oder sie nicht entsprechend konfiguriert wurde. Ein Rückweg zum Lieferanten nach der Veröffentlichung fehlt entweder oder ist aufwändig.

Im Idealfall hätte der Redakteur:
… eine übergreifende Sicht auf die Planung: wann zu welchen Themen Agenturen oder eigene Mitarbeiter Inhalte liefern werden, mit Übernahme in die Produktionsplanung
… eine einheitliche Sicht auf digitale Inhalte aus allen verfügbaren Quellen: ein Portal oder eine Suchmaschine, über die man auf selbst produzierte Texte und Bilder, Agenturmaterial, Angebote von anderen Redaktionen oder Freien, interne und externe Archive zugreifen kann
… eine 1-Klick-Übernahme aller (geplanten oder bereits vorhandenen) Inhalte in die eigene Produktion, mit sämtlichen Metadaten (Angaben zum Urheber, Nutzungsrechte und Vergütung, Bildunterschriften, Verschlagwortung, Verknüpfung zur Planung)
… einen automatisierten Rückweg, der den Anbieter über die geplante bzw. erfolgte Veröffentlichung informiert und so die Erstellung von Nutzungsstatistiken, Abrechnung und Belegexemplaren stark vereinfacht
… eine einfache Möglichkeit, selbst eigene Inhalte anderen Redaktionen anzubieten

All das ist technisch machbar. Programmieren muss man dafür elegante und verständliche Schnittstellen für Inhalteanbieter (z.B. Portale von Nachrichtenagenturen und Bilddatenbanken) und Produktionssysteme (Redaktionssysteme, CMS). Schwieriger ist die nötige Standardisierung von Metadaten und Protokollen:

Es braucht Konventionen, welche Metadaten-Formate wie genutzt werden (z.B. NewsML G2, RightsML). Zumindest die für die Produktion grundlegenden Metadaten (Datum, Embargo, Bildunterschrift, Nutzungsrechte, Copyright) müssen einheitlich (bzw. kompatibel) ausgetauscht werden können. Für ein themenzentriertes Arbeiten muss man noch deutlich weiter gehen und ein gemeinsames Metadaten-Vokabular (für Personen, Orte, Ereignisse/Veranstaltungen, Themen) schaffen. Das bringt einen erheblichen “Mehrwert”, ist aber schwierig: Mit der Vereinheitlichung von Vokabular und Strukturen kämpft das “Semantic Web” schon länger. Am ehesten können Nachrichtenagenturen hier Standards setzen.

Und es müssen sich Protokolle für die Schnittstellen etablieren, über die man Bilder und Texte anbietet. Wenn jeder Anbieter und Abnehmer sein eigenes Datensilo betreibt mit proprietären APIs, kann kein universaler Content-Marktplatz entstehen. Schauen wir uns doch vom Web ab, wie es geht: Jeder Inhalte-Anbieter nutzt entweder einen Dienstleister oder hostet selbst eine Website, die für jeden Text (bzw. jedes Bild) und jedes Thema eine eigene HTML-Seite (unter einer permanenten URL) anbietet, mit Links und semantischem HTML-Markup (für Metadaten und Rechte, z.B. RDFa). Dafür können verschiedene Parteien Crawler und Suchmaschinen bauen. Alternativ zum Crawling können XML-Sitemaps, RSS-Feeds und PubSubHubbub bereitgestellt werden. Inhalte und Suchmaschinen werden meist nicht öffentlich sein, sondern ein Login erfordern (was z.B. auch die Personalisierung der Rechte ermöglicht).

(Siehe auch: Software für Journalismus – zwei Ideen vor dem scoopcamp 2013 und Linked Data for better image search on the Web.)

Wie sieht’s aus, wer macht mit?