Das “NITF 3.0 XML”-Format

Transcrição

Das "NITF 3.0 XML"-Format
Version vom 13. April 2012
dpa - Das “NITF 3.0 XML”-Format
Copyright © 2012 von dpa - Deutsche Presse-Agentur GmbH
Status des Dokuments: FINAL
Version des Dokuments: 4.4
Versionshistorie .................................................................................................................. 5
Unterschiede Version 4.4 zu vorherigen Versionen ......................................................................... 5
Vorwort ................................................................................................................................6
Der Standard NITF ........................................................................................................................... 6
Was kann NITF? .............................................................................................................................. 6
Gegenstand dieses Dokumentes ..................................................................................................... 6
1
Implementierungshinweise ................................................................................ 7
2
Konzepte ............................................................................................................. 7
2.1
dpa-Rubriken und Nachrichtenmanagement.......................................................... 7
2.2
Dubletten ....................................................................................................................8
2.2.1
2.2.2
2.2.3
2.3
Reihenfolge .............................................................................................................. 13
2.3.1
2.3.2
2.4
Unternehmen ................................................................................................................... 21
Andere Codes .................................................................................................................. 22
Strukturierung von Textinhalten ............................................................................ 22
2.7.1
2.7.2
2.7.3
2.7.4
2.8
Orte der Meldung vs. Orte in der Meldung ...................................................................... 17
Repräsentation................................................................................................................. 18
Metadaten zur Unterstützung von Affiliate-Programmen .................................... 20
2.6.1
2.6.2
2.7
Konzept ............................................................................................................................ 14
Repräsentation von Informationen zum Zurückziehen .................................................... 16
Prozesse .......................................................................................................................... 16
Geokodierung .......................................................................................................... 17
2.5.1
2.5.2
2.6
Konzept ............................................................................................................................ 13
Repräsentation von Reihenfolgeinformationen ............................................................... 13
Zurückziehen ........................................................................................................... 14
2.4.1
2.4.2
2.4.3
2.5
Eindeutige Meldungsidentifikation (UID) ........................................................................... 9
Varianten.......................................................................................................................... 11
Eindeutige Identifikation referenzierter Medienobjekte.................................................... 12
Teaser .............................................................................................................................. 22
Spaltenüberschriften in Tabellen ..................................................................................... 22
Verlinkung ........................................................................................................................ 23
Infokästen ........................................................................................................................ 24
Bilder ........................................................................................................................26
2.8.1
2.8.2
2.8.3
2.8.4
2.8.5
Bildformate ....................................................................................................................... 26
Seitenverhältnis von Bildern ............................................................................................ 26
Beispiele .......................................................................................................................... 29
Verknüpfung zwischen Texten und Bildern ..................................................................... 31
Bildergalerien ................................................................................................................... 31
- Seite 1 von 120 -
2.9
Videoinhalte ............................................................................................................. 33
2.9.1
2.9.2
2.9.3
2.10
3
Anwendungsszenarien .................................................................................................... 33
Komponenten................................................................................................................... 35
Repräsentation................................................................................................................. 37
Verzeichnisstrukturen ......................................................................................... 43
Die dpa-Meldung im erweiterten “NITF 3.0 XML”-Format ............................. 45
3.1
Kodierung und verwendete Zeichensätze ............................................................ 45
3.2
Das Wurzelelement nitf ........................................................................................ 45
3.3
Der Dokumentenkopf head .................................................................................... 45
3.4
Der Titel title ........................................................................................................ 45
3.5
Die META-Elemente meta ....................................................................................... 46
3.6
Der Subject-Code tobject.subject ................................................................... 46
3.7
Die Dokument-Metadaten docdata ....................................................................... 47
3.8
Die Länderkennung evloc ..................................................................................... 47
3.9
Die UID doc-id........................................................................................................ 47
3.10
Die redaktionelle Information ed-msg ................................................................ 48
3.11
Die Priorität urgency........................................................................................... 48
3.12
Die dpa-Rubrik fixture ..................................................................................... 48
3.13
Datum der Meldung date.issue ....................................................................... 49
3.14
Das Ressort doc-scope ...................................................................................... 49
3.15
Die Stichwortliste key-list............................................................................... 49
3.16
Identifizierte Entitäten identified-content .................................................. 50
3.17
Organisationen org ............................................................................................. 50
3.18
Klassifizierungen classifier ................................................................................. 50
3.19
Orte location ..................................................................................................... 51
3.20
Länder country ................................................................................................... 51
3.21
Staaten state ...................................................................................................... 51
3.22
Regionen region ................................................................................................. 52
3.23
Städte city .......................................................................................................... 52
3.24
Die Meldung body ................................................................................................ 52
3.25
Der Meldungskopf body.head ........................................................................... 53
3.26
Der Überschriftenbereich hedline .................................................................... 53
3.27
Die Überschrift hl1 .............................................................................................. 53
3.28
Die Unter-Überschriften hl2 ............................................................................... 53
3.29
Die Autoren-Zeile byline ................................................................................... 54
3.30
Meldungsinhalt body.content .......................................................................... 54
3.31
Text p ....................................................................................................................54
- Seite 2 von 120 -
4
5
3.32
Tabellen table ..................................................................................................... 55
3.33
Tabellenkopf thead ............................................................................................. 55
3.34
Tabellenende tfoot ............................................................................................ 55
3.35
Tabelleninhalt tbody ........................................................................................... 56
3.36
Tabellenzeile tr ................................................................................................... 56
3.37
Tabellenheader th ............................................................................................... 56
3.38
Tabellenzelle td ................................................................................................... 56
3.39
Multimedia-Objekte media .................................................................................. 57
3.40
Multimedia-Metadaten media-metadata .......................................................... 57
3.41
Multimedia-Referenz media-reference........................................................... 57
3.42
Beschreibungstext Multimedia-Objekte media-caption ............................... 58
3.43
Unsortierte Listen ul ........................................................................................... 59
3.44
Sortierte Listen ol ............................................................................................... 59
3.45
Der Textblock block ........................................................................................... 59
3.46
Hyperlinks a ......................................................................................................... 60
3.47
Betonungen em ..................................................................................................... 60
3.48
Fettung b ............................................................................................................... 60
3.49
Kurzübersicht der Dokumentstruktur ................................................................ 60
Beispiele von Meldungen im “NITF 3.0 XML”-Format ................................... 63
4.1
Eine “NITF 3.0 XML”-Textmeldung ........................................................................ 63
4.2
Eine “NITF 3.0 XML”-Textmeldung mit Bildern .................................................... 64
4.3
Ein „NITF 3.0 XML“ Textmeldung mit Audio......................................................... 65
4.4
Ein „NITF 3.0 XML“ Textmeldung mit Video ......................................................... 66
4.5
Eine „NITF 3.0 XML“ Textmeldung mit Tabelle .................................................... 68
4.6
Eine „NITF 3.0 XML“-Bildmeldung......................................................................... 69
4.7
Eine „NITF 3.0 XML“-Audiomeldung ..................................................................... 70
4.8
Eine „NITF 3.0 XML“-Videomeldung...................................................................... 71
4.9
Eine “NITF 3.0 XML”-Mobilmeldung ...................................................................... 72
4.10
Ein “NITF 3.0 XML”-Reihenfolgedokument ....................................................... 73
4.11
Ein “NITF 3.0 XML”-Berichtigungsdokument .................................................... 73
MMS-Dienste ..................................................................................................... 75
5.1
Dienststruktur und Arten von Kanälen ................................................................. 75
5.2
Struktur der Dokumente ......................................................................................... 75
5.3
Tabellen ....................................................................................................................75
5.4
Beispiele .................................................................................................................. 77
5.4.1
5.4.2
Alert- / Live-MMS ............................................................................................................. 77
Bulletin-MMS.................................................................................................................... 78
- Seite 3 von 120 -
5.4.3
Beispielmeldung mit Opener und Closer ......................................................................... 79
6
Validierung von “NITF 3.0 XML”-Dokumenten ............................................... 81
7
Unterschiede zu vorhergehenden Versionen ................................................. 82
7.1
Unterschiede zu NITF 2.5 XML ............................................................................... 82
7.1.1
7.1.2
7.1.3
Encoding .......................................................................................................................... 82
Repräsentation von Bildern ............................................................................................. 82
Externe Links ................................................................................................................... 82
Anhang A. Verwendete Stichwörter <key-list>.......................................................... 83
Anhang B. Subject-Codes ................................................................................................ 83
Anhang C. Länderkennung - ISO-3166 und dpa-Erweiterung ....................................... 91
Anhang D. Verwendete Zeichen ...................................................................................... 98
Anhang E. Datumsformat - ISO-8601 ............................................................................ 102
Anhang F. Erweiterte DTD von “NITF 3.0 XML” ........................................................... 103
Anhang G. Referenzen.................................................................................................... 120
- Seite 4 von 120 -
Versionshistorie
Unterschiede Version 4.4 zu vorherigen Versionen
•
2.2.3: Neues Konzept zur Repräsentation von ID und Versionsnummer von Medienobjekten,
die innerhalb eines NITF-Dokumentes referenziert werden.
•
2.3.2.4: Neuer Abschnitt zur Repräsentation von ID und Versionsnummer
Medienobjekten, die innerhalb eines Reihenfolgedokumentes referenziert werden.
•
2.5: Die Ebenen Bezirk und Ortsteil entfernt, da diese nicht mehr unterstützt werden. Ebenfalls
werden für die Orte der Meldung keine Geokoordinaten mehr unterstützt.
•
3.24: Beschreibung sublocation entfernt, da Bezirk und Ortsteil nicht mehr repräsentiert
werden
von
•
Überarbeitung und Umbenennung des Berichtigungskonzeptes in Konzept zum Zurückziehen
(s. 2.4)
•
Beschreibung des neuen Element ed-msg für redaktionelle Hinweise im Kontext eines
Zurückziehdokumentes (s. 3.10)
•
Beschreibung des Konzepts zur Unterstützung von Affiliate Programmen (s. 2.6)
•
Beschreibung des Elements classifier zur Repräsentation von Fremdschlüsseln für AffiliateProgramme (s. 3.18)
•
Erweiterte Beschreibung interner Verlinkungen (s. 2.7.3.2)
•
Beschreibung des neuen Konzepts Infokästen (s. 2.7.4)
•
Erweiterte Beschreibung der Video-Konzepte (s. 2.9)
•
Erweiterte Beschreibung des Konzepts für Geoinformationen, um die Orte in der Meldung (s.
2.5).
•
Erweiterte Beschreibung des Konzepts für Videos, um insbesondere die unterschiedlichen
unterstützten Anwendungsszenarien und die unterschiedlichen Repräsentatationsmöglichkeiten für Videoinhalte als Teil von NITF-Dokumenten besser zu verdeutlichen (s. 2.9).
•
Neues Konzept Geokodierung (s. 2.5)
•
Neues Konzept Video (s. 2.9)
•
Neue Abschnitte zur Beschreibung der Elemente für die Geokodierung (s. 3.19- 3.24)
•
Beispiel Textmeldung mit Video (s. 4.4)
•
Beispiel Videomeldung (s. 4.8)
•
Beschreibung der neuen Bildformate (Small und Large) hinzugefügt (s. 2.8.1)
•
Beschreibung des Abschnitts Seitenverhältnis von Bildern für neue Seitenverhältnisse im
Bildformat Small und zur Beschreibung des Bildschwerpunktes überarbeitet (s. 2.8.2)
•
Neuen Abschnitt für Bildergalerien eingeführt (s. 2.8.5)
•
Neuen Abschnitt zur Beschreibung des Elementes media-metadata eingeführt (s. 3.41)
- Seite 5 von 120 -
•
Neues Attribut name für das Element media-reference eingeführt (s. 3.42)
•
Abschnitt zu Verzeichnisstrukturen für die neuen Bildformate überarbeitet (s. 2.9)
•
Neuen Abschnitt zur Beschreibung der Elemente identified-content und org eingeführt (s. 3.16
und 3.17)
•
Beispiel für eine Textmeldung mit Audio eingeführt (s. 4.3)
•
Beispiel für eine Bildmeldung eingeführt (s. 4.6)
•
Beispiel für eine Audiomeldung eingeführt (s. 4.7)
Vorwort
Der Standard NITF
Die Inhalte der dpa-infocom-Dienste werden – anders als die traditionellen Agenturdienste der dpa –
in einem strukturierten XML-Format ausgeliefert, das frei von Layout-Informationen ist. Das News
Industry Text Format (NITF) wurde durch den International Press Telecommunications Council (IPTC)
festgelegt und standardisiert. Ausführliche Informationen zur Entwicklung von NITF und der IPTC gibt
es im Internet unter www.nitf.org bzw. www.iptc.org.
Die dpa-infocom liefert in Ihren Diensten unterschiedliche Arten von Objekten (Texte, Bilder, Grafiken,
Audio-Dateien etc.). NITF dient der Repräsentation aller Textinhalte. Binärdaten werden in eigenen
Dateien gespeichert und aus den NITF-Dateien verlinkt.
Was kann NITF?
Durch NITF bringt jede Nachricht strukturierte Informationen mit, die den Inhalt durch Metainformationen beschreiben und die Bestandteile der eigentlichen Meldung umfassen. Zur Zeit gibt es Felder
für die dpa-Rubrik, der die Meldung durch dpa-infocom-Redakteure zugewiesen wurde (die dpaRubrik hieß früher Catchline), für das klassische Zeitungsressort wie etwa Politik, Vermischtes, Kultur,
für die Stichwörter, die den Meldungsinhalt noch genauer beschreiben (etwa Arbeitsmarkt,
Bundespräsident) und für einen von 17 Subjectcodes (beispielsweise FRZ für Freizeit). Darüber
hinaus ist das Herkunftsland (Länderkürzel) enthalten, ebenso die Sendezeit (nicht mit dem
Dateidatum zu verwechseln) und Links auf Binärdaten.
Die eigentliche Meldung ist nach Überschrift, Autorenname, Text, verknüpften Media-Objekten (Bilder,
Audiodateien, etc.) sowie einem Block externer Links strukturiert. Zu beachten ist, dass es in Zukunft
ggf. zusätzliche Metainformationen und Meldungsinhalte geben wird.
Durch diese Struktur können die Meldungen mit Hilfe eines Parsers oder Stylesheets vollautomatisiert
auf die Kunden-Site übernommen werden. Jeder Kunde kann das Layout dabei selbst gestalten.
Denkbar ist beispielsweise das „Ausklinken“ der Überschrift und des ersten Absatzes als Teaser auf
der Titelseite eines Portals mit Link auf den kompletten Text in einer Rubrik. Das
Nachrichtenmanagement wird komplett von der dpa-infocom übernommen.
Gegenstand dieses Dokumentes
Dieses Dokument erläutert, in welcher Form die Inhalte der dpa-infocom-Dienste im Format NITF 3.0
XML ausgeliefert werden. Es richtet sich primär an Techniker, die verantwortlich für die Verarbeitung
der Inhalte sind.
- Seite 6 von 120 -
1 Implementierungshinweise
XML-Dokumente können über eine DTD genau definiert werden. Für die “NITF 3.0 XML”-Dokumente
wurde von der IPTC eine DTD festgelegt. Diese DTD befindet sich auch im Anhang "NITF 3.0 XML"DTD.
Für die Verarbeitung von XML-Dateien existieren eine Reihe von Programmen und Bibliotheken im
Internet. Darauf basierend lassen sich für “NITF 3.0 XML” Parser anpassen oder z.B. XSL-Stylesheets
schreiben.
Im Kapitel 3 werden diejenigen Elemente von “NITF 3.0 XML” erläutert, die aktuell von der dpainfocom für Ihre Dienste verwendet werden. Da zukünftige Erweiterungen in den Diensten geplant
sind, die eine Nutzung weiterer Elemente von „NITF 3.0 XML“ einbezieht, sollte bei der
Implementierung des Parsers bzw. des Stylesheets darauf geachtet werden, dass alle in der DTD
beschriebenen Elemente und Attribute interpretiert und verarbeitet werden können. Die DTD
beschreibt, an welchen Stellen die einzelnen Elemente im NITF-Dokument vorkommen können. Es ist
daher notwendig, dass der Parser bzw. das Stylesheet mit diesen Elementen an allen definierten
Stellen rechnet und entsprechend interpretiert.
Die von der dpa-infocom verwendeten Elemente, Attribute und Inhalte können von Datei zu Datei
variieren. Es wird bei der dpa-infocom stets darauf geachtet, dass die produzierten Dateien der “NITF
3.0 XML”-DTD entsprechen. Die Korrektheit aller NITF-Dateien wird durch Validierung gegenüber der
DTD sichergestellt. Somit bekommt der Parser bzw. das Stylesheet immer korrekte “NITF 3.0 XML”Eingangsdaten.
Nur wenn darauf geachtet wird, dass der Parser bzw. das Stylesheet mit jeglichen “NITF 3.0 XML”Dokumenten umgehen kann, ist davon auszugehen, dass gewünschte Ausgabedaten generiert
werden.
2 Konzepte
2.1
dpa-Rubriken und Nachrichtenmanagement
Die dpa-infocom übernimmt einen Großteil der Meldungen aus den klassischen dpa-Diensten. Die
Übernahme erfolgt jedoch nicht vollautomatisiert. Vielmehr verwendet dpa-infocom viel Aufwand auf
die Bewertung, Auswahl und Pflege der Nachrichten. Beispielsweise werden überholte Nachrichten
aus dem Bestand gelöscht, wenn aktuelle Meldungen eintreffen. Bei Bedarf berichtigt die Redaktion
auch Meldungen.
Die dpa-infocom bietet unterschiedliche Dienste mit genau definierten Inhalten. Zur besseren
Strukturierung werden die Dienste hierarchisch in so genannte dpa-Rubriken (früher Catchline)
unterteilt, denen Inhalte zugeordnet werden können. Inhalte werden bevorzugt den Blättern einer
solchen Hierarchie zugeordnet, aber aus historischen Gründen ist dies auch für jeden anderen Knoten
in der Hierarchie möglich.
Die Struktur von Rubriken ist für jeden Dienst relativ fest vorgegeben. Änderungen werden nur nach
vorheriger Information aller Kunden mit einem zeitlich ausreichenden Vorlauf durchgeführt.
Für jede Rubrik wird genau fest gelegt:
•
Welche Inhalte werden in der Rubrik repräsentiert (z.B. die wichtigsten Meldungen aus Politik
oder die wichtigsten Fußball-Meldungen)
•
Die Anzahl der Meldungen die einer Rubrik mindestens und maximal zugeordnet werden.
•
Die Häufigkeit der Aktualisierung von Inhalten (z.B. ständig, einmal täglich, einmal
wöchentlich)
•
Die durchschnittliche Lebensdauer von Meldungen in dieser Rubrik, die eng mit der Häufigkeit
der Aktualisierung zusammenhängt.
Ausgehend von diesen Eigenschaften erfüllen Rubriken unterschiedliche Zwecke:
•
Meistens ist eine Rubrik vergleichbar mit einem Navigationspunkt in einer Navigationsstruktur
einer Web-Site, d.h. die Inhalte einer Rubrik eignen sich dazu, auf einer Übersichtsseite einer
- Seite 7 von 120 -
Web-Site dargestellt zu werden. Dies bedeutet gleichzeitig auch, dass die dpa-infocom
sicherstellen kann, dass zu einer bestimmten Thematik immer ausreichend Meldungen
gefunden werden, die oben stehende Kriterien erfüllen. So würde dpa-infocom keine Rubrik
definieren, die von Ihrer Aktualität lebt, für die aber nicht sichergestellt werden kann, dass es
nicht zu jederzeit ein Minimum an aktuellen und relevanten Meldungen gibt.
•
In seltenen Fällen handelt es sich um eine ausgezeichnete Meldung einer übergeordneten
Rubrik. Z.B. gibt es beim Thema des Tages in der InfoLine eine Meldung, die als Anreißer
zum aktuellen Thema fungiert und somit vor allen anderen Meldungen angezeigt werden soll.
Um diese Meldung von den anderen Meldungen der Rubrik unterscheiden zu können, wird sie
in einer eigenen Unterrubrik repräsentiert.
•
In seltenen Fällen werden Rubriken verwendet, um immer wiederkehrende Meldungen zu
repräsentieren, damit diese leichter erkannt werden können (z.B. die Aktienkurse des DAX).
•
In seltenen Fällen soll eine Rubrik auch signalisieren, dass die Meldungen dieser Rubrik
spezielle gelayoutet werden sollten. Z.B. gibt es Kunden, die immer wiederkehrende Tabellen
nach Ihren Bedürfnissen darstellen möchten, so dass die Tabellen einer eigenen Unterrubrik
zugeordnet werden.
Die Zuordnung einer Meldung zu einer dpa-Rubrik wird durch ein eigenes Element innerhalb des
NITF-Dokumentes repräsentiert (Siehe auch den Abschnitt Die dpa-Rubrik fixture). Gleichzeitig ist
dieses Konzept im Zusammenhang der Reihenfolgebestimmung zu betrachten (Siehe auch den
Abschnitt Reihenfolge).
Ausgehend von dieser Rubrikstruktur betreibt die dpa-infocom ein Nachrichtenmanagement, das nach
redaktionellen Kriterien durchgeführt wird. Dies umfasst folgende Aspekte:
•
Für jede eingehende Meldung wird geprüft, ob und wenn ja für welche der vorliegenden
Rubriken eine Meldung geeignet ist. Gleichzeitig wird überprüft, ob die Wichtigkeit der
Meldung im Vergleich zu den anderen einer Rubrik zugeordneten Meldungen ausreichend
hoch ist, dass die maximal für eine Rubrik zulässige Meldungsanzahl nicht überschritten wird.
Sind beide Kriterien erfüllt, wird die Meldung der entsprechenden Rubrik zugeordnet.
•
Handelt es sich bei einer eingehenden Meldung um eine Aktualisierung einer bereits
publizierten Meldung, erfolgt eine Aktualisierung und erneute Publikation der betreffenden
Meldung. Somit wird sichergestellt, dass von jeder Meldung jeweils nur die aktuellste Version
im Dienst ausgeliefert wird.
•
Wird eine als wichtig eingestufte Meldung einer Rubrik neu zugeordnet, wird von der
Redaktion überprüft, ob stattdessen eine weniger unwichtige Meldung aus der Rubrik gelöscht
wird.
Somit wird durch das Nachrichtenmanagement sichergestellt, dass einer Rubrik zu jeder Zeit die
entsprechend der definierten Kriterien aktuellsten und wichtigsten Meldungen zugeordnet sind.
Zur Abbildung der Aktualisierungsoperationen (CREATE, UPDATE, DELETE) im Rahmen des
Nachrichtenmanagements auf Kundenseite spielt neben der UID eines Dokumentes (Siehe auch den
Abschnitt Eindeutige Meldungsidentifikation (UID)) auch die Art der Übertragung der Inhalte zu den
Kunden eine wesentliche Rolle. Näheres dazu findet sich in [1] .
dpa-infocom empfiehlt, diese vorgegebene Struktur wie auch das vorgegebene Nachrichtenmanagement zu übernehmen. Auf der anderen Seite steht es den Kunden natürlich frei, ihre eigene
Strukturierung anhand weiterer Metainformationen wie z.B. der Stichworte oder der Subjectcodes
vorzunehmen sowie den Lebenszyklus (CREATE/UPDATE/DELETE) in der Publikation auf der
eigenen Web-Site redaktionell zu steuern. Auch ist es möglich, eine Mischform zu definieren, d.h.
Inhalte bestimmter Rubriken werden vollautomatisiert verarbeitet, Inhalte anderer Rubriken dagegen
redaktionell betreut.
2.2
Dubletten
Inhalte der dpa-infocom werden in identischer oder ähnlicher Form häufig mehrfach unterschiedlichen
Rubriken zugeordnet. Um den Kunden, die sich bei der Strukturierung der Inhalte nicht an der dpaRubrik orientieren, das Erkennen von inhaltlich identischen oder ähnlichen Dokumenten zu ermöglichen, hat die dpa-infocom mehrere Konzepte umgesetzt.
- Seite 8 von 120 -
2.2.1 Eindeutige Meldungsidentifikation (UID)
Die eindeutige Meldungsidentifikation (UID) umfasst zwei Konzepte:
•
Die Eindeutige Identifikation einer Meldung über eine Meldungs-ID.
•
Die Identifikation verschiedener Versionen einer Meldung über Versionsnummern.
2.2.1.1 Meldungs-ID
Die dpa-infocom produziert Meldungen. Eine Meldung besteht aus einer beliebigen Kombination von
Objekten. Ein Objekt repräsentiert dabei eines der verschiedenen Medienformate Text, Bild oder
Audio (zukünftig können evtl. weitere Medienobjekte wie z.B. Video ergänzt werden). Jedes Objekt
besteht aus einer Reihe von Metainformationen (z.B. Priorität, Ressort, Bildgröße, Länge des
Audiobeitrages) sowie den eigentlichen Inhalten (z.B. Überschrift, Meldungstext, Bildunterschrift,
Anmoderationstext für Audio). Im einfachsten Fall besteht eine Meldung nur aus einem einzelnen
Objekt (Text, Bild oder Audio). Alternativ kann eine Meldung auch aus einem Textobjekt mit einem
oder mehreren Bildobjekten und / oder einem oder mehreren Audioobjekten bestehen. In MMSDiensten kann eine Meldung darüber hinaus aus mehreren Textobjekten mit einem oder mehreren
Bild- und / oder Audioobjekten bestehen. Ein einzelnes Objekt wiederum kann unterschiedlichen
Meldungen zugeordnet sein. Eine Meldung kann ein oder mehreren Rubriken zugeordnet werden.
Diese Kombination von Meldung und zugeordneter Rubrik wiederum wird in einem NITF-Dokument
repräsentiert.
Abbildung 1 Meldungs-ID
Zum bessern Verständnis, werden diese Zusammenhänge an einem Beispiel erläutert (s. Abbildung
1). In der Abbildung gibt es zwei Textobjekte Text1 und Text2 sowie zwei Bildobjekte Bild1 und
Bild2. Text1 und Bild1 sind zu einer Meldung Meldung1 zusammengefasst, Text2, Bild1 und
Bild2 zu einer Meldung Meldung2. Meldung1 ist zwei Rubriken zugeordnet, Meldung2 nur einer
Rubrik:
- Seite 9 von 120 -
•
In der Zuordnung zur Rubrik /sportsline/fussball/news/ ist die Meldung1 im NITFDokument NITF-Dokument1 repräsentiert und an die Kunden ausgeliefert.
•
In der Zuordnung zur Rubrik /sportsline/topnews/ ist die Meldung1 im NITF-Dokument
NITF-Dokument2 repräsentiert und an die Kunden ausgeliefert.
•
In der Zuordnung zur Rubrik /ecoline/ecotopnews/ ist die Meldung2 im NITF-Dokument
NITF-Dokument3 repräsentiert und an die Kunden ausgeliefert.
Jede Meldungen wird durch eine eindeutige Meldungs-ID gekennzeichnet. Wenn zwei NITFDokumente die gleiche Meldung repräsentieren, nur jeweils in einer anderen Rubrikzuordnung (s.
NITF-Dokument1 und NITF-Dokument2 im Beispiel), wird in beiden NITF-Dokumenten eine
identische Meldungs-ID repräsentiert. Die Meldungs-ID selbst ist folgendermaßen charakterisiert:
•
Eine Meldungs-ID wird immer nur einmal für eine Meldung vergeben. Ist eine Meldungs-ID
einmal vergeben worden, wird sie zukünftig nicht wieder für eine andere Meldung vergeben,
auch wenn die ursprüngliche Meldung schon lange aus dem Dienst gelöscht worden ist.
•
Die Meldungs-ID kann eine beliebige Struktur haben, d.h. es dürfen keinerlei Annahmen
darüber gemacht werden, wie sich eine Meldungs-ID zusammensetzt. Dies ist deshalb
wichtig, da die dpa-infocom nicht garantieren kann, dass sich die jetzt gewählte Struktur aus
welchem Grund auch immer zukünftig einmal ändert.
2.2.1.2 Versionierung
Um verschiedene Versionen einer Meldung unterscheiden und damit Aktualisierungen existierender
Meldungen identifizieren zu können, enthält die UID zusätzlich zur Meldungs-ID auch eine Versionsnummer. Die Versionsnummer folgt dabei folgenden Kriterien:
•
Die Versionsnummer ist eine ganze Zahl.
•
Die initiale Versionsnummer einer Meldung ist beliebig.
•
Versionsnummern werden in aufsteigender Reihenfolge vergeben, d.h.: Wird für die Meldung
m1 zum Zeitpunkt t1 eine Versionsnummer v1 erzeugt und wird für m1 zu einem späteren
Zeitpunkt t2 eine neue Versionsnummer v2 erzeugt, dann ist v1 < v2.
•
Der Unterschied zwischen zwei aufeinander folgenden Versionsnummern ist nicht definiert,
d.h. Versionsnummern müssen nicht in der Reihenfolge 0,1,2,3,...,n vergeben werden. Wird
also für die Meldung m1 zum Zeitpunkt t1 eine Versionsnummer v1 erzeugt und wird bei der
nächsten Änderung von m1 zum Zeitpunkt t2 eine Versionsnummer v2 erzeugt, gilt nicht
zwangsläufig v2-v1=1.
2.2.1.3 Repräsentation der UID
Die eindeutige Meldungs-ID (UID) einer Meldung besteht aus drei Komponenten:
•
Die vergebende Instanz.
•
Die Meldungs-ID.
•
Die Versionsnummer.
Die Repräsentation erfolgt durch das bereits verwendete Element doc-id:
•
Die Meldungs-ID und die Versionsnummer werden im Attribut id-string nach folgendem
Schema repräsentiert: <meldungs-id>:<versionsnummer>
•
Das Element sieht zusätzlich das Attribut regsrc zur Repräsentation der vergebenden
Instanz vor. Bis auf weiteres wird für alle Meldungen der dpa-infocom-Dienste als Wert dpainfocom gesetzt. Es ist aber nicht auszuschließen, dass zukünftig andere Werte möglich
sind.
- Seite 10 von 120 -
Beispiele
Meldung mit der vergebenden Instanz dpa-infocom, der Meldungs-Id 6841086 und der
Versionsnummer 1096355229000:
<doc-id regsrc=“dpa-infocom“ id-string=“6841086:1096355229000” />
Aktualisierung zur Meldung, signalisiert durch eine neue Versionsnummer 1096355245000:
<doc-id regsrc=“dpa-infocom“ id-string=“6841086:1096355245000” />
2.2.2 Varianten
Die Meldungs-ID dient dazu, inhaltlich identische Meldungen, die unterschiedlichen Rubriken
zugeordnet sind, zu identifizieren. Durch Auswertung der Meldungs-ID kann ein Großteil der Dubletten
erkannt werden. Darüber hinaus gibt es aber noch Dokumente, die nicht identisch, aber sehr ähnlich
sind. Dafür gibt es eine Reihe von Beispielen, u.a.:
•
Meldungen, die sich nur in der Überschrift unterscheiden. Z.B. tritt in der SportsLine häufig der
Fall auf, dass wichtige Meldungen sowohl einer sportartspezifischen Rubrik (z.B.
/sportsline/fussball/erstebundesliga/news/)
und
den
TopNews
(/sportsline/topnews/) zugeordnet sind. In den TopNews wird in der Überschrift meist
noch die Sportart vorangestellt.
•
Meldungen, die unterschiedlichen Rubriken zugeordnet sind, sich aber nur in einem Absatz
unterscheiden.
•
Meldungen, die unterschiedlichen Rubriken zugeordnet sind, aber unterschiedliche Bilder
haben.
In all diesen Fällen sind sich die Meldungen so ähnlich, dass der Enduser die Meldungen als identisch
einordnen würde, wenn beide beim Kunden in der gleichen Übersichtsseite angezeigt würden. Man
spricht in diesem Fall von Meldungen, die in einer Ähnlichkeitsrelation zu einander stehen und nicht
einer gemeinsamen Rubrik zugeordnet werden sollten.
2.2.2.1 Variantenkennung
Um Ähnlichkeitsrelationen zwischen zwei Meldungen erkennen zu können, hat die dpa-infocom das
Konzept der Variantenkennung eingeführt, das sich durch folgende Eigenschaften auszeichnet (s.
auch Abbildung 2):
•
Jede Meldung erhält eine eindeutige Variantenkennung.
•
Zwei Meldungen, die eine unterschiedliche Meldungs-ID, aber die gleiche Variantenkennung
haben, stehen in einer Ähnlichkeitsrelation.
•
Die Variantenkennung ist versionsunabhängig, d.h. sie bezieht sich nicht auf eine bestimmte
Version eines Dokumentes.
•
Unterschiedliche Versionen einer Meldung können unterschiedliche Variantenkennung haben.
Das kann passieren, wenn sich zwei Varianten einer Meldung inhaltlich so weit auseinander
bewegen, dass die Ähnlichkeitsrelation nicht mehr zutrifft.
Die Variantenkennung wird im Element meta repräsentiert:
•
Das Attribut name hat den Wert variant.
•
Im Attribut content ist die Variantenkennung repräsentiert. Über das Format der Variantenkennung sollten keine Annahmen gemacht werden.
Abbildung 2 Variantenkonzept
Beispiele:
<meta name="variant" content="24049413-1096355225905-1"/>
<meta name=”variant” content=”4231578”/>
2.2.2.2 Anmerkung
Es sei an dieser Stelle noch darauf hingewiesen, dass das Konzept der Ähnlichkeitsrelation mit
einigen Unschärfen versehen ist. Die Grenze, wann zwei unterschiedliche Meldungen als so ähnlich
eingestuft werden, dass sie die gleiche Variantenkennung erhalten, ist fließend. Es liegt somit im
Ermessen des Redakteurs der dpa-infocom, diese Entscheidung zu treffen. Es wird sich nicht
vermeiden lassen, dass es dabei in manchen Fällen zwischen den Redakteuren der dpa-infocom und
denen ihrer Kunden zu unterschiedlichen Auffassungen kommt.
2.2.3 Eindeutige Identifikation referenzierter Medienobjekte
Analog zu Meldungen gibt es auch für Medienobjekte, die in einer Meldung innerhalb des Elements
media referenziert werden, eine eindeutige Identifikation. Dies gilt jedoch nur für den Fall, dass es
sich bei der Meldung um ein anderes Objekt handelt als das in media referenzierte Medienobjekt. Bei
einer Textmeldung wird beispielsweise zu den referenzierten Bildern eine Identifkation repräsentiert.
Bei einer Bildmeldung ist das im Element media repräsentierte Bild dagegen integraler Bestandteil
des Dokumentes und hat somit keine eigene Identifikation.
Die Identifikation von Medienobjekten besteht aus einer ID und einer Versionsnummer. Sie wird im
generischen Element media-metadata repräsentiert. Dieses Element hat zwei Attribute:
•
name: Zur Repräsentation der ID von Medienobjekten hat dieses Attribut den Wert media-id.
•
value: In diesem Attribut wird die Medienobjekt-ID und die Versionsnummer nach folgendem
Schema repräsentiert: <medienobjekt-id>:<versionsnummer>
Medienobjekt-IDs werden sowohl in Meldungsdokumenten als auch in Reihenfolgedokumenten
repräsentiert (s. Abschnitt 2.3).
2.3
Reihenfolge
Eng verknüpft mit dem Nachrichtenmanagement bietet die dpa-infocom ein rubrikbezogenes
Reihenfolgemanagement, durch das den Kunden die Reihenfolge der Meldungen innerhalb einer
Rubrik explizit mitgeteilt wird. Dieses Reihenfolgemanagement wird redaktionell durch die dpa-infocom
betreut, so dass die Kunden keine eigenen Algorithmen zur Bestimmung der Reihenfolge implementieren müssen.
2.3.1 Konzept
Das Reihenfolgekonzept der dpa-infocom ist durch folgende Eigenschaften gekennzeichnet:
•
Die Reihenfolge wird über alle einer Rubrik zugeordneten Meldungen festgelegt.
•
Die Reihenfolgeinformationen werden getrennt von den eigentlichen Meldungen in eigenen
NITF-Dokumenten repräsentiert. Dadurch wird vermieden, dass Änderungen in der
Reihenfolge zu einer Auslieferung ansonsten unveränderter Meldungen führt.
•
Änderungen an der Reihenfolge müssen nicht zwangsläufig mit Änderungen an den
Meldungen einer Rubrik einhergehen. In der Regel führen zwar die Bereitstellung neuer
Meldungen, Änderungen an existierenden Meldungen oder das Löschen existierender
Meldungen, zu einem veränderten Reihenfolgedokument. Es ist aber durchaus auch möglich,
dass sich ausschließlich die Reihenfolge innerhalb einer Rubrik ändert.
2.3.2 Repräsentation von Reihenfolgeinformationen
Ausgehend von dem oben beschriebenen Reihenfolgekonzept, werden Reihenfolgeinformationen zu
einer Rubrik in eigenen NITF-Dokumenten repräsentiert. Zu jeder Rubrik gibt es ein Reihenfolgedokument, das den folgenden Aufbau hat:
<?xml version="1.0" encoding="UTF-8"?>

<nitf>
<head>
<meta name="copyright" content="dpa-info.com GmbH"/>
<meta name="generator" content="CoreMedia"/>
<docdata>
<fixture fix-id="$dpa-Rubric$"/>
<date.issue norm="20040827T160330+0200"/>
</docdata>
</head>
<body>
<body.content>
<media media-type="text">
<media-metadata name="media-id" value="$id1$:$version1$" />
<media-reference source="$referenz1$" mime-type="text/xml" />
</media>
</media>
<media-reference source="$referenzn$" mime-type="text/xml" />
</media>
</body.content>
<body.end/>
</body>
</nitf>
Die Bedeutung der einzelnen Elemente setzt auf der allgemeinen Beschreibung der Elemente für
NITF-Dokumente im Kontext der dpa-infocom auf. Deshalb soll an dieser Stelle lediglich auf einige
Elemente im Kontext von Reihenfolgedokumenten eingegangen werden.
2.3.2.1 Element fixture
Das Element fixture dient der Repräsentation der dpa-Rubrik, für die die Reihenfolge festgelegt
wird. Die dpa-Rubrik wird dabei im Attribug fix-id repräsentiert. Das Format ist das gleiche wie bei
NITF-Dokumenten zur Repräsentation der Meldungen.
2.3.2.2 Element body.content
Im Element body.content wird die Reihenfolge aller Meldungen einer Rubrik festgelegt.
2.3.2.3 Element media
Im Element media wird jeweils ein eine Meldung der Rubrik repräsentierendes NITF-Dokument
verlinkt. Die Reihenfolge der Meldungen ergibt sich durch die Reihenfolge der media-Elemente.
2.3.2.4 Element media-metadata
Im Element media-metadata werden die ID und Versionsnummer des referenzierten
Medienobjektes repräsentiert. Das Attribut name hat dabei immer den Wert media-id. Im Attribut
value werden ID und Versionsnummer im Schema <meldungs-id>:<versionsnummer>
repräsentiert.
2.3.2.5 Element media-reference
Das Element media-reference, das sich innerhalb des Elementes media befindet, enthält die
eigentliche Referenz auf das NITF-Dokument. Die Referenz wird dabei als relativer Pfad auf das
entsprechende NITF-Dokument repräsentiert.
2.4
Zurückziehen
In der Regel werden Inhalte von der dpa-infocom im Rahmen des Nachrichtenmanagements gelöscht,
wenn sie nicht mehr aktuell oder durch wichtigere Meldungen der zugeordneten Rubrik ersetzt
werden. Kunden, die sich nicht auf das Nachrichtenmanagement verlassen, übernehmen diese
Löschinformation jedoch häufig nicht, sondern löschen Inhalte nach eigenen Regeln. Das ist
grundsätzlich auch in Ordnung, solange die vertraglichen Bedingungen bezüglich des erlaubten
Veröffentlichungszeitraums eingehalten werden.
In bestimmten Situationen ist es aber notwendig, dass die Kunden eine Meldung auf jeden Fall aus
ihrem System löschen. Dies ist meist der Fall, wenn mit der Löschung rechtliche Konsequenzen
verbunden sind. Um die Verantwortung für eventuelle Haftungsfragen für die dpa-infocom
auszuschließen, müssen solche Löschinformationen gesondert gekennzeichnet werden. Der Kunde
wiederum übernimmt die Verantwortung für Haftungsfragen, sollte er die Löschinformation nicht
verarbeiten. Dieser Anforderung wird durch das Konzept zum Zurückziehen berücksichtigt.
2.4.1 Konzept
Das Konzept zum Zurückziehen spielt vor allen Dingen für diejenigen Kunden eine Rolle, für die
mindestens eine der beiden folgenden Bedingungen zutrifft:
•
Manche Kunden verarbeiten die Löschinformationen (DELETE) zu den von dpa-infocom
gelieferten Meldungen nicht. Diese Kunden haben somit eigene Kriterien definiert, nach denen
die Meldungen gelöscht werden.
•
Manche Kunden, die entsprechende Rechte erworben haben, archivieren von dpa-infocom
gelöschte Meldungen für einen definierten Zeitraum.
Um diese Anwendungsfälle bei den Kunden durch das Konzept zum Zurückziehen abzudecken,
ergeben sich folgende mögliche Szenarien im Kontext des Zurückziehens (s. auch Abbildung 3):
•
Eine Meldung besteht aus zwei Objekten (Teil1 und Teil2) und ist im aktuellen Dienst
publiziert. Die dpa-infocom bekommt den Hinweis, dass Teil2 nicht weiterverwendet werden
darf. Die Meldung muss also ohne Teil2 neu publiziert werden und die Kunden müssen den
Hinweis erhalten, dass Teil2 nicht mehr verwendet werden darf.
•
Eine Meldung bestand zu einem in der Vergangenheit liegenden Zeitpunkt aus zwei Objekten
(Teil1 und Teil2). Zu einem späteren Zeitpunkt wurde die Meldung erneut, aber ohne Teil2
publiziert. Dies ist auch der aktuelle Zustand der Meldung im Dienst. Die dpa-infocom
bekommt den Hinweis, dass Teil2 nicht weiterverwendet werden darf. Die Kunden müssen
darüber in Kenntnis gesetzt werden, dass der Teil2, der nicht mehr Teil des aktuellen
Zustandes der Meldung ist, nicht mehr verwendet werden darf.
•
Eine Meldung bestand zu einem in der Vergangenheit liegenden Zeitpunkt aus zwei Objekten
(Teil1 und Teil2). Anschließend wurde die gesamte Meldung aus dem Dienst gelöscht. Die
dpa-infocom bekommt den Hinweis, dass Teil2 nicht weiterverwendet werden darf. Die
Kunden müssen darüber in Kenntnis gesetzt werden, dass der Teil2 der Meldung, die nicht
mehr im aktuellen Dienst publiziert ist, nicht mehr verwendet werden darf.
Meldung
Meldung
update
Teil 1
Teil 1
Teil 2
Nicht mehr
verwenden: Teil 2
Meldung
Meldung
update
Teil 1
Teil 1
Nicht mehr
verwenden: Teil 2
Teil 2
Meldung
Meldung
delete
Teil 1
Teil 1
Teil 2
Teil 2
Version 1
Nicht mehr
verwenden: Teil 2
Version 2
Zeit
Abbildung 3 Szenarios im Kontext des Zurückziehens
Die dpa-infocom kennt Identifikationen nur auf Meldungsebene, nicht jedoch auf der Ebene der
Objekte. Eine entsprechende Erweiterung würde auch die Komplexität in den Diensten der dpaCopyright © 2012 von dpa - Deutsche Presse-Agentur GmbH
infocom zu sehr erhöhen. Insofern werden Berichtigungen von der dpa-infocom auf Meldungsebene
umgesetzt. Daraus folgert, dass es im Prinzip zwei Arten des Zurückziehens gibt:
•
Berichtigte Neufassung einer aktuellen Meldung (entspricht Fall 1)
•
Zurückziehen einer alten Version einer Meldung (entspricht Fall 2 und 3)
Um die Komplexität in der Verarbeitung durch die Kunden weiter zu reduzieren, hat sich die dpainfocom entschieden, das Konzept zum Zurückziehen folgendermaßen umzusetzen:
•
Eine Information zum Zurückziehen bezieht sich immer auf eine Meldung, nicht auf einzelne
Objekte.
•
Es wird nur das Zurückziehen, nicht die berichtigte Neufassung unterstützt.
•
Es wird immer die Meldung als ganzes zurückgezogen, d.h. wird eine Meldung
zurückgezogen, darf keine einzige Version einer Meldung mehr verwendet werden.
Parallel zur Information zum Zurückziehen wird das betroffene Dokument auch aus dem Dienst
gelöscht. Es ist aber nicht auszuschließen, dass zwischen dem Aussenden des Dokumentes zum
Zurückziehen und dem Löschen des betroffenen Inhaltsdokumentes eine zeitliche Differenz besteht.
2.4.2 Repräsentation von Informationen zum Zurückziehen
Jedes zurückgezogene Dokument wird in einem eigenen Zurückziehdokument repräsentiert. Solche
Dokumente werden dienstunabhängig ausgeliefert, d.h. wird in einem Dienst eine Meldung
zurückgezogen, wird in jedem Dienst, der von der dpa-infocom produziert wird, ein entsprechendes
Zurückziehdokument ausgeliefert. Kunden der dpa-InfoLine bekommen somit auch Informationen zum
Zurückziehen aus der dpa-SportsLine geliefert. Kunden, die die dpa-InfoLine und die dpa-SportsLine
beziehen, bekommen zu jedem zurückgezogenen Dokument ein identisches Dokument zum
Zurückziehen sowohl im Zurückziehordner der dpa-InfoLine als auch im Zurückziehordner der dpaSportsLine.
Ein Zurückziehdokument ist nach folgendem Schema aufgebaut:
"nitf.dtd" -->
<nitf>
<head>
<docdata management-doc-idref="6790038:1091973643000"
management-idref-status="canceled"/>
<ed-msg info="Das Zitat von xxx darf so nicht verwendet werden."/>
</head>
</nitf>
Die UID der zurückgezogenen Meldung befindet sich im Element docdata im Attribut managementdoc-idref. Zusätzlich liefert die Redaktion der dpa-infocom im Attribut info des Elements ed-msg
einen redaktionellen Hinweis, in dem der Grund für die Berichtigung näher erläutert wird. Der Name
von Berichtigungsdokumenten ist beliebig gewählt und enthält keinerlei Informationen, die für die
Verarbeitung einer Berichtigung herangezogen werden kann.
2.4.3 Prozesse
Ausgehend von den in Abbildung 3 dargestellten Szenarien stellen sich die Prozesse für den Kunden
folgendermaßen dar:
•
Fall 1: Zur aktuellen Meldung wird ein Zurückziehdokument erzeugt und ausgeliefert mit einer
UID, die aus der Meldungs-ID des zurückgezogenen Dokumentes und einer Versionsnummer
besteht, die mindestens so groß ist, wie die zuletzt durch den Kunden verarbeitete
Versionsnummer. Der aktuellen Meldung wird bei gleichbleibender Variantenkennung eine
neue Meldungs-ID zugeordnet, das betroffene Objekt wird aus der Meldung gelöscht und die
Meldung wird neu publiziert. Es wird ein neues NITF-Dokument mit neuem Dateinamen und
neuer UID ausgeliefert. Gleichzeitig wird das NITF-Dokument, das die Meldung mit der alten
Meldungs-ID repräsentiert hat, gelöscht.
2.5
•
Fall 2: Zur Meldung wird ein Zurückziehdokument erzeugt und ausgeliefert mit einer UID, die
aus der Meldungs-ID des zurückgezogenen Dokumentes und einer Versionsnummer besteht,
die mindestens so groß ist, wie die zuletzt durch den Kunden verarbeitete Versionsnummer.
Der aktuellen Meldung wird bei gleichbleibender Variantenkennung eine neue Meldungs-ID
zugeordnet. Es wird ein neues NITF-Dokument mit neuer Meldungs-ID und Versionsnummer
ausgeliefert. Gleichzeitig wird das NITF-Dokument, das die Meldung mit der alten MeldungsID repräsentiert hat, gelöscht.
•
Fall 3: Zur Meldung wird ein Zurückziehdokument erzeugt und ausgeliefert mit einer UID, die
aus der Meldungs-ID des zurückgezogenen Dokumentes und einer Versionsnummer besteht,
die mindestens so groß ist, wie die zuletzt durch den Kunden verarbeitete Versionsnummer.
Das NITF-Dokument, das die zugehörige Meldung repräsentiert, wird gelöscht.
Geokodierung
Inhalte können geokodiert werden. Jeder Meldung können beliebig viele Geokodierungen zugeordnet
werden. Die Geokodierung unterstützt zwei Semantiken – Filterung von Inhalten nach Relevanz und
Identifizierung von Orten in einer Meldung. Für beide Semantiken werden zusätzlich Geokoordinaten
ausgeliefert, um die Inhalte in einer Karte darstellen zu können.
2.5.1 Orte der Meldung vs. Orte in der Meldung
2.5.1.1 Orte der Meldung / Relevanz einer Meldung
Einige Kunden möchten Inhalte nach regionalen Gesichtspunkten filtern. Dies kann z.B. das
Verbreitungsgebiet einer Zeitung umfassen oder eine Region in einem Portal. Hierzu muss
identifizierbar sein, für welchen geografischen Bereich die Meldung relevant ist. Dies wird auch als
Orte der Meldung bezeichnet. Zu diesem Zweck werden die Geoinformationen in die folgende
Hierarchie eingeordnet:
•
Land: Neben dem Namen des Landes wird das dreibuchstabige Länderkürzel nach ISO-3166-1
repräsentiert.
•
Bundesland / Staat: Neben dem Namen lässt sich das Bundesland über einen Code
identifizieren. Dabei werden unterschiedliche Code-Schemata unterstützt. Bundesländer
innerhalb von Deutschland werden dabei durch den Amtlichen Gemeindeschlüssel (AGS)
repräsentiert.
•
Region: Je nach Land werden verschiedene Arten von Regionen unterschieden. In Deutschland
sind dies die Kreise und kreisfreien Städte. Neben dem Namen lässt sich die Region ebenfalls
über einen Code identifizieren, wobei für Deutschland wiederum der AGS verwendet wird.
•
Stadt: Neben dem Namen lässt sich die Stadt über einen Code identifizieren, wobei für
Deutschland wiederum der AGS verwendet wird.
Je nach Meldungskontext kann die Hierarchie beliebig tief sein. Hat eine Meldung z.B. Relevanz für
ein Bundesland, endet die Hierarchie auf dieser Ebene.
2.5.1.2 Orte in der Meldung
Anders als bei der Relevanz der Meldungen beziehen sich die Orte in der Meldung auf konkret in einer
Meldung genannte Orte. Orte in der Meldung werden mit folgenden Informationen ausgezeichnet:
•
Adresse: Die Adresse ist eine unstrukturierte Zeichenkette, wie sie der Google Geocoder zurück
liefert. Je nachdem, wie viel Informationen dem Googlecoder vorliegen, variiert der Umfang der
repräsentierten Informationen, z.B.:
o
Oststraße 2, 03052 Cottbus, Germany
o
Seidelstraße 39, 13507 Tegel, Berlin, Germany
•
Land: Neben dem Namen des Landes wird das dreibuchstabige Länderkürzel nach ISO-3166-1
repräsentiert.
•
Bundesland / Staat: Optional der Name des Bundeslandes
•
Region: Optional der Kreis oder die Kreisfreie Stadt
•
Stadt: Optional die Stadt / Gemeinde
Anders als bei den Orten der Meldungen werden jedoch bei den Orten in der Meldungen keine Codes
in den verschiedenen Ebenen der Hierarchie repräsentiert.
Die Orte in der Meldung, die zum Teil bis auf Straßenebene erfasst sind, eignen sich für die
Darstellung auf Karten, z.B.:
Dafür werden Breiten- und Längenangaben zu einem Ort benötigt. Diese werden wie die
Adressangaben auf Basis des Google-Geocoders erfasst und zusammen mit einem Ort in der
Meldung repräsentiert.
2.5.2 Repräsentation
Die Repräsentation von Geoinformationen basiert auf den Mechanismen, die NITF zur Verfügung
stellt, ergänzt um den Standard GeoRSS (s. http://georss.org/) zur Repräsentation von
Geokoordinaten, der als zusätzlicher Namespace integriert wird.
Die Repräsentation basiert für die Orte der Meldung und die Orte in der Meldung grundsätzlich auf
den gleichen Mechanismen. Unterschiede gibt es jedoch vor allen Dingen in der Repräsentation von
Geokoordinaten, die für Orte der Meldung nicht repräsentiert werden, und im Detail.
Zur Repräsentation von Ortsinformationen bietet NITF das Element location. Dieses Element
wiederum besteht aus verschiedenen Subelementen zur Repräsentation von Ländern (country),
Staaten (state), Regionen (region) und Städten (city).
Der Geocode wird über das Element georss:point repräsentiert – zunächst der Breiten-,
anschließend der Längengrad.
Die Ortsinformation wird im Element identified-content repräsentiert, die wiederum innerhalb
von docdata repräsentiert wird.
2.5.2.1 Orte der Meldung / Relevanz einer Meldung
Die Repräsentation der Orte der Meldung zeichnet sich durch die folgenden Eigenschaften aus:
•
Das Element location hat ein Attribut class mit dem Wert scope. Es enthält ausschließlich
die Elemente city, state und country.
•
Zu jedem eine Hierarchieebene repräsentierenden Element wird ein code mit einer den Code
vergebenden Instanz repräsentiert.
•
Der Name der Hierarchieebene erscheint als Text innerhalb des entsprechenden Elementes.
Beispiel 1: Repräsentation eines Ortsteils mit den Ebenen Land, Bundesland und Stadt:
<nitf xmlns="http://iptc.org/std/NITF/2001-10-12/"
xmlns:georss="http://www.georss.org/georss">
<head>
...
<docdata>
<evloc iso-cc="DEU"/>
...
<fixture fix-id="/regioline/berlinbrandenburg/"/>
...
<identified-content>
<location class="scope">
<city city-code="11000000" code-source="AGS">Berlin</city>
<state state-code="11000000" code-source="AGS">Berlin</state>
<country iso-cc="DEU">Deutschland</country>
</location>
</identified-content>
</docdata>
</head>
...
</nitf>
Beispiel 2: Repräsentation einer Stadt mit den Ebenen Land, Bundesland, Kreis und Stadt:
<nitf xmlns:georss="http://www.georss.org/georss">
<head>
<location class="scope">>
<city city-code="12067120" code-source="AGS">Eisenhüttenstadt</city>
<region region-code="12067000" code-source="AGS">Oder-Spree</region>
<state state-code="12000000" code-source="AGS">Brandenburg</state>
</location>
</docdata>
</head>
…
</nitf>
2.5.2.2 Orte in der Meldung / Relevanz einer Meldung
Die Repräsentation der Orte in der Meldung zeichnet sich durch die folgenden Eigenschaften aus:
•
Das Element location hat ein Attribut class mit dem Wert address.
•
Die Adresse wird als Text innerhalb von location repräsentiert und umfasst die optionale
Beschreibung zur Adresse sowie eine Geokodierung.
•
Die Hierarchieebenen werden über die Elemente city, state und country repräsentiert.
•
Die eine Hierarchieebene repräsentierenden Elemente werden ohne code repräsentiert.
•
Der Name der Hierarchieebene erscheint als Text innerhalb des entsprechenden Elementes.
Beispiel: Repräsentation einer Adresse mit den Hierarchieebenen Land, Bundesland und Stadt:
"nitf.dtd" -->
<nitf xmlns:georss="http://www.georss.org/georss">
<head>
<title>Früheres Cottbuser Gefängnis wird in Berlin versteigert</title>
<meta name="origin" content="dpa - Deutsche Presse-Agentur GmbH"/>
<tobject>
<tobject.subject tobject.subject.refnum="00000000"
tobject.subject.code="NIL" />
</tobject>
<docdata>
<evloc iso-cc="GER"/>
<doc-id regsrc="dpa-infocom" id-string="14657092:1205230305000"/>
<urgency ed-urg="4"/>
<fixture fix-id="/regiolinegeo/berlinbrandenburg/"/>
<date.issue norm="20080311T111145+0100"/>
<doc-scope scope="vm"/>
<key-list>
<keyword key="Brandenburg/Kommunen/Justiz/"/>
</key-list>
<location class="address">
JVA Cottbus, Oststraße 2, 03052 Cottbus,
Germany<georss:point>51.765887 14.38088</georss:point>
<city>Cottbus</city>
<region>Cottbus</region>
<state>Brandenburg</state>
</location>
</docdata>
</head>
…
2.6
Metadaten zur Unterstützung von Affiliate-Programmen
Affiliate-Programme bieten zusätzliche Erlösmöglichkeiten für Web-Site-Anbieter, indem sie z.B.
Inhalte über einen Deep-Link mit einem E-Commerce-Anbieter verlinken und so an den Umsätzen
beteiligt werden, die über diesen Deep-Link ausgelöst werden. Sie werden deshalb auch zunehmend
von den Kunden der dpa-infocom eingesetzt.
dpa-infocom möchte die Kunden dabei unterstützen, ihre Inhalte ebenfalls mit solchen AffiliateProgrammen zu verknüpfen. Deshalb verknüpft dpa-infocom redaktionelle Inhalte mit offiziellen
Fremdschlüsseln (Codes), über die ein Deep-Link zur Schnittstelle des E-Commerce-Anbieters
hergestellt werden kann.
Abbildung 4 Prozess zur Unterstützung von Affiliate-Programmen am Beispiel Buchkritik
Abbildung 4 zeigt einen typischen Prozess zur Einbindung von dpa-infocom-Inhalten in das AffiliateProgramm eines Kunden am Beispiel einer Buchkritik:
•
Die dpa-infocom veröffentlicht in der dpa-StarLine eine Buchkritik und ergänzt diese um die
ISBN-Nr. des Buches.
•
Die Buchkritik wird zusammen mit der ISBN-Nummer als NITF-XML-Dokument ausgeliefert.
•
Der Kunde schließt unabhängig davon eine Affiliate-Vereinbarung mit einem InternetBuchhändler, z.B. Amazon oder Buch.de.
•
Die von dpa-infocom angelieferte Buchkritik wird zusammen mit der ISBN-Nummer in das
Angebot des Kunden integriert. Aus der ISBN-Nummer wird ein Deep-Link auf die Bestellseite
des Buchs beim Affiliate Partner erzeugt.
•
Buchkritik und Deep-Link werden auf der Seite des Kunden publiziert.
•
Der User liest die Buchkritik und entschließt sich zum Kauf des Buches, indem er auf den DeepLink des Affiliate-Partners klickt.
•
Beim Affiliate-Partner gelangt er auf die entsprechende Bestellseite und kauft das Buch.
•
Der Affiliate-Partner erkennt anhand des Deep-Links, über welchen Kunden der User den
Bestellvorgang initiiert hat und schüttet die vereinbarte Umsatzbeteiligung an den Kunden aus.
dpa-infocom unterstützt verschiedene Arten von Fremdschlüsseln in seinen Produkten:
•
Universal Product Code (UPC) für CD’s, DVD’s, etc.
•
ISBN13-Nummer für Bücher
•
IATA-Codes für Flughäfen
•
ISIN (International Securities Identifying Number) für Finanzprodukte
Alle Fremdschlüssel werden innerhalb des Elements identified-content repräsentiert.
Bei der Umsetzung im Format NITF 3.0 XML kann grundsätzlich zwischen der Auszeichnung von
Unternehmen und anderen Codes unterschieden werden.
2.6.1 Unternehmen
Die Identifikation von Unternehmen erfolgt durch die ISIN innerhalb des in NITF definierten Elementes
org. Das Attribut idsrc hat den Wert ISIN und im Attribut value wird der ISIN-Code repräsentiert.
Innerhalb des Elementes org wird zusätzlich der offizielle Name des Unternehmens repräsentiert.
Beispiel:
<nitf>
<head>
…
<docdata>
…
<org idsrc="ISIN" value="FI0009000681">NOKIA OYJ</org>
<org idsrc="ISIN" value="SE0000108656">ERICSSON(L.M.)</org>
…
2.6.2 Andere Codes
Alle anderen Codes werden durch das generische Element classifier repräsentiert.
Beispiel:
<nitf>
<head>
…
<docdata>
…
<classifier idsrc="UPC" value="4711">Der Name des
Produkts</classifier>
<classifier idsrc="ISBN13" value="1232452342352">Der Name des
Buchs</classifier>
<classifier idsrc="IATA" value="HAM">Der Name des
Flughafens</classifier>
…
Im Attribut idsrc wird der Typ des Codes repräsentiert. Gültige Werte sind UPC, ISBN13 und IATA.
Das Attribut value enthält den eigentlichen Code / Fremdschlüssel. Innerhalb des Elementes
classifier wird zusätzlich noch eine Beschreibung des Codes repräsentiert, z.B. der Name der CD
oder der Name des Buchs.
2.7
Strukturierung von Textinhalten
Textinhalte einer Meldung können beliebig durch Paragraphen, Tabellen und Listen strukturiert
werden. Dabei werden einige Aspekte berücksichtigt, die für eine geeignete Darstellung in
unterschiedlichen Kontexten von Web-Sites eine Rolle spielen.
2.7.1 Teaser
Es wird darauf geachtet, dass jede Meldung, die sich dazu eignet, als Teaser auf einer Übersichtsseite
dargestellt zu werden, einen ersten kurzen Absatz enthält. Auch inhaltlich ist dieser Absatz so
gestaltet, dass er sich als Teasertext eignet. Es wird aber darauf hingewiesen, dass die dpa-infocom
natürlich nicht alle individuellen Wünsche bei der Layoutgestaltung solcher Übersichtsseiten
berücksichtigen kann, so dass eine Länge gewählt wurde, die einen guten Kompromiss unter allen
Kunden darstellt.
2.7.2 Spaltenüberschriften in Tabellen
Spaltenüberschriften in Tabellen spielen aus unterschiedlichen Gründen eine wichtige Rolle:
•
Die Länge von Spaltenüberschriften kann das Layout einer Site bzw. einer Tabelle zerstören.
•
Kunden wünschen häufig, dass Spaltenüberschriften layouttechnisch anders dargestellt
werden als der eigentliche Tabelleninhalt.
Um diesen Anforderungen gerecht zu werden, werden Tabellen von der dpa-infocom häufig in den
eigentlichen Header-Bereich (thead) mit den Spaltenüberschriften und den Inhaltsbereich (tbody)
unterteilt. Kunden können damit entscheiden, ob Sie die Spaltenüberschriften überhaupt anbieten
möchten und ob diese speziell gelayoutet werden sollen.
Durch die Einführung von Spaltenüberschriften ist aber noch nicht gewährleistet, dass diese auch
immer den Vorstellungen der Kunden entsprechen bzw. dass diese nicht zu Layoutproblemen bei den
Kunden führen können. Gerade wenn es um sehr schmale Spalten geht, gibt es unterschiedliche
Kundenwünsche darüber, wie Spaltenüberschriften abgekürzt werden sollen. Da die dpa-infocom
nicht allen Kundenwünschen gerecht werden kann, wurden Standardwerte definiert, die einheitlich
über verschiedene Tabellen verwendet werden. Kunden, denen diese Standardwerte nicht gefallen,
müssen bei der Übernahme von Tabellen eigene Tabellenüberschriften definieren. Das kann natürlich
nur für bekannte und immer wieder kehrende Tabellentypen gewährleistet werden.
2.7.3 Verlinkung
In den NITF-Dokumenten der dpa-infocom können andere Ressourcen verlinkt sein. Dabei werden
grundsätzlich drei verschiedene Varianten unterschieden, die in den folgenden Abschnitten näher
beschrieben werden.
2.7.3.1 Interne Verlinkung von Medienobjekten
Hierbei handelt es sich in der Regel um Verlinkungen zwischen NITF-Dokumenten und Binärobjekten,
d.h. Bild- oder Audioinhalten. Lediglich in den Reihenfolgedokumenten erfolgt zusätzlich eine
Verlinkung auf andere NITF-Dokumente. Diese Form der Verlinkung wird aber in einem eigenen
Abschnitt näher beschrieben, so dass sich dieser Abschnitt auf die Verlinkung mit Binärobjekten
konzentriert.
Die Verlinkung zu Binärobjekten erfolgt nicht aus dem Text selbst heraus. Es findet also keine genaue
Positionierung der Binärobjekte innerhalb des Textes statt, da dies aus Sicht der dpa-infocom eher
eine Layoutfrage ist und somit nicht zum Konzept der strukturierten Auslieferung von Inhalten passt.
Aus diesem Grund erfolgt die Verlinkung von Binärobjekten über das Element media. Eine genaue
Beschreibung der Repräsentation erfolgt in einem eigenen Abschnitt zu Bildern.
2.7.3.2 Verlinkung von internen Texten
Anders als bei der Verlinkung von Medienobjekten erfolgt eine interne Verlinkung zwischen NITFDokumenten innerhalb des Meldungstextes. NITF sieht analog zu HTML für die Verlinkung zwischen
Ressourcen das Element a und das Attribut href vor. Um interne Links von externen Links
unterscheiden zu können, sind interne Links nach dem folgenden Schema aufgebaut:
dpa-infocom:///<MeldungsId>
Dabei entspricht die <MeldungsId> dem MeldungsId-Teil der UID eines NITF-Dokumentes. Es wird
also nicht auf eine bestimmte Version eines NITF-Dokumentes, sondern immer auf die aktuelle
Version des NITF-Dokumentes verlinkt.
Im Internet finden sich zwei verschiedene Herangehensweisen in Bezug auf Verlinkungen:
•
Manche Kunden wünschen sich die Verlinkungen direkt aus dem Text heraus, um z.B. einen im
Meldungstext verwendeten Begriff mit einer Definition in Wikipedia zu verlinken.
•
Manche Kunden möchten Verlinkungen als separaten Kasten außerhalb des Meldungstextes
repräsentieren, aus dem Meldungstext heraus aber nicht verlinken.
Die dpa-infocom unterstützt beide Varianten:
•
Wo immer sinnvoll, werden interne Verlinkungen im Meldungstext vorgenommen.
•
Separat vom Meldungstext werden interne Verlinkungen zusätzlich als eigenständiger block
repräsentiert, bei dem das Attribut style den Wert INTERNAL-LINKS hat. Dieser Block
umfasst alle im Meldungstext erstellten internen Verlinkungen sowie optional weitere interne
Verlinkungen. Je internen Link wird ein eigener Paragraph p innerhalb des Blocks repräsentiert,
der wiederum Text sowie den Link im Element a und dem Attribut href enthalten kann. Dabei
gibt es keine Regeln dafür, wie die Verlinkung und der beschreibende Text aufgebaut sind.
Lediglich bei internen Verlinkungen, die aus dem Meldungstext übernommen worden sind, wird
als Meldungstext immer die Überschrift des verlinkten Dokumentes repräsentiert.
Beispiel:
<body.content>
<p>In <a href=“dpa-infocom:4711“>China</a> macht die Schule viele
Kinder krank. Sie müssen so viel lernen, dass ihnen nicht genug Zeit
zum Schlafen bleibt. Viele werden traurig und depressiv, weil der
Unterricht so anstrengend ist. Das früher arme Land will jetzt schnell
reich und modern werden. Damit das klappt, müssen die Chinesen viel
wissen.</p>
<block style=”INTERNAL-LINKS”>
<p><a href=“dpa-infocom:4711“>China – das land der aufgehenden
Sonne</a></p>
<p>Weitere <a href=“dpainfocom:4712“>Hintergrundinformationen</a></p>
</block>
2.7.3.3 Verlinkung von externen Ressourcen
In NITF-Dokumenten können außerdem noch Verlinkungen auf externe Ressourcen enthalten sein,
d.h. Links auf externe Web-Seiten. Solche Verlinkungen werden bewusst nicht innerhalb des Textes
vorgenommen sondern in einem eigenen Block separat vom Text repräsentiert.
Beispiel:
<body.content>
<block style=“EXTERNAL-LINKS“>
...<p><a href=”http://www.wikipedia.de/4711”>Lukas Pudolski</a> bei
Wikipedia</p>
<p>Spielerportrait <a
http://www.fcbayern.de/kader/lukas_podolski.html”>Lukas
href=“h
Podolski</a> auf der Homepage vom FC Bayern München</p>
<p><a href=”www.lukas-podolski.de”>Homepage von Lukas
Podolski</a></p>
</block>
</body.content>
Verlinkungen auf externe Ressourcen werden in einem eigenen Element block repräsentiert, bei
dem das Attribut style den Wert EXTERNAL-LINKS hat. Innerhalb dieses Blocks wird jede externe
Referenz in einem eigenen Paragraphen p repräsentiert, der wiederum Text sowie den Link im
Element a und dem Attribut href enthalten kann. Dabei gibt es keine Regeln dafür, wie die
Verlinkung und der beschreibende Text aufgebaut sind.
2.7.4 Infokästen
Zur Anreicherung von Meldungstexten werden Inhalte im Internet zunehmend um sogenannte
Infokästen ergänzt. Infokästen dienen dazu, einen im Meldungstext dargestellten Begriff oder
Sachverhalt näher zu erläutern. Da es sich meist um kurze Erläuterungstexte handelt, werden sie
häufig zusammen mit dem Meldungstext, aber graphisch abgesetzt auf der gleichen Seite
repräsentiert, so dass der User die Informationen nicht über einen weiteren Link abrufen muss.
Außerdem werden solche Infokästen selten in mehreren Meldungstexten gleichzeitig verwendet.
Abbildung 5 zeigt die beispielhafte Umsetzung eines Infokastens. Dabei ist der Infokasten innerhalb
des Textes positioniert und durch einen Kasten mit gelbem Hintergrund und rotem Rahmen vom
Meldungstext abgesetzt.
Abbildung 5 Hervorgehobener Infokasten in einer Meldung
Beispiel:
<body.content>
<p>Köln/Heidelberg (dpa/tmn) – Egal ob Kanzlerin Angela Merkel
ausländische Regierungschefs trifft oder Daimler zu einer
internationalen …</p>
…
<p>…«Simultan-Dolmetschen ist auch eine Frage der Begabung»</p>
<block style="INFO">
<hl1>Viele Konferenzdolmetscher arbeiten freiberuflich</hl1><p>Das
Einkommen von Konferenzdolmetschern hängt von vielen Faktoren ab. Bei
einer Festanstellung beginnt es nach den Daten der Bundesagentur für
Arbeit bei gut 2300 Euro brutto im Monat. Viele Dolmetscher arbeiten
allerdings freiberuflich. «Dann kann man nur die Einsatztage
abrechnen», erläutert der Dolmetscher Klaus Ziegler. «Zehn bis zwölf
im Monat sind realistisch. Das Honorar ist frei verhandelbar und liegt
etwa zwischen 700 und 1000 Euro pro Tag.» Ziegler rechnet mit rund 80
bezahlten Einsatztagen pro Jahr, zu denen Reisetage sowie Vor- und
Nachbereitungstage kommen.</p>
</block>
</body.content>
dpa-infocom unterstützt dieses Konzept der Infokästen, indem diese Informationen als Teil des NITFDokumentes repräsentiert werden, das den eigentlichen Meldungstext enthält, aber gesondert
ausgezeichnet sind. dpa-infocom liefert also die Strukturinformationen, damit ein Kundensystem einen
Infokasten vom Meldungstext unterscheiden kann. Die gestalterische Umsetzung von Infokästen ist
aber Aufgabe des Kundensystems.
Zur strukturellen Identifikation werden Infokästen als eigener block repräsentiert, bei dem das Attribut
style den Wert INFO hat. Ein Infokasten umfasst eine Überschrift hl1 und eine Folge von
Paragraphen p. Je Meldung kann es beliebig viele Infokästen geben.
2.8
Bilder
Die Verwendung von Bildern in den Diensten der dpa-infocom ist wie für die Textinhalte darauf
ausgerichtet, dass eine optimale Nutzung für das jeweilige Zielformat gewährleistet ist. Dies drückt
sich in Bildformaten, Seitenverhältnissen und der Zuordnung zu Textdokumenten aus.
2.8.1 Bildformate
Bilder werden normalerweise als JPG ausgeliefert. In Ausnahmefällen ist auch die Verwendung von
GIF möglich. Andere Formate werden derzeit nicht unterstützt. Es ist aber nicht auszuschließen, dass
zukünftig weitere Formate verwendet werden.
Bei der Bildproduktion wird darauf geachtet, dass die Größe der Bilddateien nicht zu groß ist.
Gleichzeitig wird aber auch darauf geachtet, dass die Bilder eine ausreichende Bildqualität aufweisen.
Um die Verwendung der Bilder in unterschiedlichen Kontexten – in Teasern in Übersichtsseiten,
innerhalb eines Artikels oder in einer eigenen Bildseite – optimal darstellen zu können, wurden Bilder
bisher in zwei Formaten – OnlineBild und Thumbnail ausgeliefert. Diese Varianten werden auch
weiterhin ausgeliefert. In den letzten Jahren hat sich jedoch die Auflösung der Bildschirme und damit
die von den Layouts der Web-Seiten unterstützte Auflösung erhöht. Um diesem Trend gerecht zu
werden, werden von dpa-infocom zwei zusätzliche Bildformate eingeführt, so dass zukünftig die
folgenden Bildformate unterstützt werden:
•
Thumbnail: Das Thumbnail hat wie bisher immer eine Breite von 80 Pixel und eignet sich
zur Anzeige innerhalb von Teasern oder innerhalb der Meldungsseite.
•
Small: Dieses neue Bildformat passt immer in einen Rahmen der Größe von 200x200 Pixel.
Dabei ist die längere der beiden Seiten immer genau 200 Pixel. Es eignet sich ebenfalls zur
Anzeige innerhalb von Teasern oder innerhalb der Meldungsseite. Dieses Bildformat ist
allerdings nur im Format NITF 3.0 XML erhältlich. Im Format NITF SGML wird dieses
Bildformat nicht unterstützt.
•
Medium: Dieses bisher OnlineBild genannte Bildformat passt immer in einen Rahmen der
Größe von 400x400 Pixel. Dabei ist die längere der beiden Seiten immer genau 400 Pixel.
Dieses Bildformat eignet sich zur Anzeige in einer eigenen Bildseite oder einem Popup.
•
Large: Dieses neue Bildformat passt immer in einen Rahmen der Größe von 800x800 Pixel.
Dabei ist die längere der beiden Seite immer genau 800 Pixel. Es eignet sich zur Anzeige in
einer eigenen Bildseite oder einem Popup. Dieses Bildformat ist allerdings nur im Format
NITF 3.0 XML erhältlich. Im Format NITF SGML wird dieses Bildformat nicht unterstützt.
2.8.2 Seitenverhältnis von Bildern
Im November 2005 hat die dpa-infocom feste Seitenverhältnisse (standardmäßig 4:3 und in
Ausnahmefällen 3:4) eingeführt, damit die Kunden ihr Layout an verlässlichen Seitenverhältnissen
ausrichten können. In zahlreichen Kundengesprächen hat sich jedoch gezeigt, dass die Kunden bei
den Seitenverhältnissen eine größere Flexibilität für Bilder benötigen:
•
Es wird häufig ein verlässliches und einheitliches Seitenverhältnis benötigt. Die bisherige
Praxis, dass abweichend vom Standardformat 4:3 in Ausnahmefällen auch ein Bild im
Seitenverhältnis 3:4 ausgeliefert wird, bereitet einigen Kunden Probleme.
•
Individuelle Seitenverhältnisse stellen zunehmend ein Instrument dar, um sich von anderen
Web-Site abzuheben. Insofern werden neben 4:3 und 3:4 weitere Seitenverhältnisse benötigt.
Bisher mussten Kunden, für die einer der beiden Aspekte relevant ist, die von dpa-infocom
angelieferten Bilder somit entweder manuell oder automatisiert auf das gewünschte Seitenverhältnis
anpassen. Die manuelle Anpassung erlaubt die Auswahl eines optimalen Bildausschnitts, während die
automatisierte Anpassung weniger Personalaufwand und eine schnellere Publikation der von dpainfocom angelieferten Inhalte auf die eigene Web-Site ermöglichte.
2.8.2.1 Standardseitenverhältnisse
Die dpa-infocom möchte dem Wunsch nach größerer Flexibilität und gleichzeitig einer qualitativ
besseren automatischen Verarbeitung der Bilder nachkommen. Da sich diese Anforderung basierend
auf den Kundenbefragungen größtenteils auf die in Teasern und Übersichtsseiten dargestellten Bilder
bezieht, liefert die dpa-infocom zukünftig zu jedem Bild weitere Seitenverhältnisse für das Bildformat
Small aus. Da dpa-infocom nicht alle Seitenverhältnisse standardmäßig ausliefern kann, wurde eine
Auswahl von Seitenverhältnissen getroffen, die auf Auswertungen von Kundenbefragungen und der
Analyse existierender Web-Sites beruhen. Der redaktionelle Bildbearbeitungsprozess wird dabei so
gestaltet, dass der Bildausschnitt für jedes der ausgelieferten Seitenverhältnisse optimal gewählt ist.
Basierend auf diesen Überlegungen gelten die folgenden Regeln für die Standardauslieferung von
Bildern in allen Web-Lines:
•
Wie bisher gibt es ein bevorzugtes Seitenverhältnis. Dieses ist in der Regel 4:3 und in
Ausnahmefällen 3:4. Die Bildformate Thumbnail, Medium und Large werden immer im
bevorzugten Seitenverhältnis ausgeliefert, d.h. also entweder 4:3 oder 3:4.
•
Für das Bildformat Small werden immer Seitenverhältnisse 4:3, 3:4, 1:1, 16:9 und 3:2
ausgeliefert.
Ist also das bevorzugte Seitenverhältnis 4:3, werden die folgenden Bildvarianten ausgeliefert:
•
thumbnail_4_3: Das Bildformat Thumbnail im Seitenverhältnis 4:3 und mit einer Größe
von 80x60 Pixel.
•
small_4_3: Das Bildformat Small im Seitenverhältnis 4:3 und mit einer Größe von 200x150
Pixel.
•
Pixel.
•
Pixel.
•
small_16_9: Das Bildformat Small im Seitenverhältnis 16:9 und mit einer Größe von
200x113 Pixel.
•
Pixel.
•
medium_4_3: Das Bildformat Medium im Seitenverhältnis 4:3 und mit einer Größe von
400x300 Pixel.
•
large_4_3: Das Bildformat Large im Seitenverhältnis 4:3 und mit einer Größe von 800x600
Pixel.
Ist das bevorzugte Seitenverhältnis dagegen 3:4, werden die folgenden Bildvarianten ausgeliefert:
•
thumbnail_3_4: Das Bildformat Thumbnail im Seitenverhältnis 3:4 und mit einer Größe
von 80x107 Pixel.
•
Pixel.
•
Pixel.
•
Pixel.
•
small_16_9: Das Bildformat Small im Seitenverhältnis 16:9 und mit einer Größe von
200x113 Pixel.
•
Pixel.
•
medium_3_4: Das Bildformat Medium im Seitenverhältnis 4:3 und mit einer Größe von
300x400 Pixel.
•
large_3_4: Das Bildformat Large im Seitenverhältnis 4:3 und mit einer Größe von 600x800
Pixel.
Es sei an dieser Stelle aber darauf hingewiesen, dass diese Größen in Ausnahmefällen um wenige
Pixel (meist beschränkt auf 1 Pixel) abweichen können, also z.B. 399x300 Pixel für das Format
medium_4_3. Dies ist auf Rundungsfehler zurückzuführen, die sich beim Ausschneiden und / oder
Skalieren eines Bildes auf die vorgegebenen Bildgrößen ergeben können. Damit die Kunden anders
als bisher aber leichter Bildformat und Seitenverhältnis identifizieren können, wird der Name der
Bildvariante zukünftig als Wert des Attributs name des Elementes media-reference mit
ausgeliefert.
2.8.2.2 Bildschwerpunkt
Da dpa-infocom standardmäßig nur die beschriebenen ausgewählten Seitenverhältnisse ausliefert, es
aber Kunden gibt, die davon abweichende Seitenverhältnisse benötigen, möchte die dpa-infocom
auch diese Kunden besser als bisher unterstützen. Zu diesem Zweck liefert die dpa-infocom mit jedem
Bild Informationen zum Bildschwerpunkt mit, der den Bereich eines Bildes kennzeichnet, der
optimalerweise in jeder Bildvariante enthalten sein sollte. Der Bildschwerpunkt stellt ein Rechteck dar,
dessen Größe abhängig vom gewählten Bild beliebig variieren kann. Er bezieht sich immer auf das
Bildformat Large. Ausgehend von der linken oberen Ecke des Bildes wird der Bildschwerpunkt durch
die Positionen der linken oberen und der rechten unteren Ecke festgelegt:
•
X1: Der horizontale Abstand zwischen der linken oberen Ecke des Bildes und der linken
oberen Ecke des Bildschwerpunktes.
•
Y1: Der vertikale Abstand zwischen der linken oberen Ecke des Bildes und der linken oberen
Ecke des Bildschwerpunktes.
•
X2: Der horizontale Abstand zwischen der linken oberen Ecke des Bildes und der rechten
unteren Ecke des Bildschwerpunktes.
•
Y2: Der vertikale Abstand zwischen der linken oberen Ecke des Bildes und der rechten
unteren Ecke des Bildschwerpunktes.
Abbildung 6 Bildschwerpunkt
Abbildung 6 zeigt ein Beispiel für einen Bildschwerpunkt und die daraus generierten Bildvarianten.
Das obere Bild des Eisbären zeigt das Ausgangsbild. Der Bildschwerpunkt ist durch den lila Rahmen
festgelegt. Unter dem Ausgangsbild werden verschiedene Bildvarianten dargestellt, in denen
ausgehend vom Bildschwerpunkt das für das Seitenverhältnis optimale Bild generiert. In den mit rotem
Rahmen gekennzeichneten Bildvarianten passt der Bildausschnitt nicht komplett in das Bildformat, so
dass nur ein Ausschnitt des Bildschwerpunktes dargestellt werden kann.
In NITF 3.0 XML gibt es kein Standardelement zur Repräsentation dieser Informationen, so dass dafür
das Element media-metadata verwendet wird. Das Attribut name hat den Wert image-fovearegion und im Attribut value werden die Parameter des Bildschwerpunktes im Format X1,Y1, X2,
Y2 repräsentiert. Befindet sich also die obere linke Ecke an Position 20,45 und die rechte untere Ecke
an Position 459,320, wird dies folgendermaßen repräsentiert:
<media-metadata name="image-fovia-region" value="20,45,459,320"/>
Diese Information kann von Kunden verwendet werden, um bessere Ergebnisse bei der Berechnung
eines individuellen Seitenverhältnisses zu erzielen. Ausgehend von dem Bild im Format Large sollte
der Kunde den Ausschnitt des Zielbildes so wählen, dass er einen möglichst großer Teil des mitgelieferten Bildschwerpunktes umfasst.
2.8.3 Beispiele
Bei der Integration der zusätzlichen Bildformate und der Repräsentation des Bildschwerpunktes in
NITF 3.0 XML liegt der Fokus auf größtmöglicher Abwärtskompatibilität zum bisherigen Format. Das
bedeutet konkret:
•
Wie bisher werden zunächst die Referenzen auf die Bildformate Thumbnail und Medium
repräsentiert. Referenzen auf die neuen Bildformate folgen erst anschließend.
•
Die existierenden Attribute für das Element media-reference werden weiterhin unterstützt,
ergänzt um das zusätzliche Attribut name zur Identifikation der Bildvariante. Die möglichen
Werte für das name-Attribut sind nach folgendem Schema aufgebaut:
<bildformat>_<horizontaler
Seitenverhältnis>
Wert
Seitenverhältnis>_<vertikaler
Wert
large_4_3 bezeichnet also das Bild im Format Large und mit dem Seitenverhältnis 4:3.
•
Zu beachten ist, dass bei der Verarbeitung des NITF-Formats keine Annahmen über die
Dateinamen und somit die Namensstruktur der referenzierten Bilder gemacht werden sollen.
Es wird zwar versucht, dass auch zukünftig thumbnail Teil des Namens bei der Referenz
auf das Bildformat Thumbnail und onlineBild Teil des Namens bei der Referenz auf das
Bildformat Small ist. Da sich dies in Zukunft aber potentiell ändern kann, sollten Kunden, die
diese Information bisher ausgewertet haben, stattdessen den Wert des Attributes name
auswerten, um auf Bildformat und Seitenverhältnis zu schließen.
•
Das Element media-metadata wird zusätzliche als erstes Element unterhalb des Elementes
media und somit vor dem ersten Element media-reference eingeführt.
Basierend auf diesen Regeln, werden Bilder mit einem bevorzugten Seitenverhältnis von 4:3
folgendermaßen repräsentiert:
<media media-type="image">
<media-metadata name="image-fovea-region" value="20,20,350,259"/>
<media-reference alternate-text="Praxis aus Protest geschlossen"
source="../dpa-Badenwuerttemberg-images/jpeg-1x6a4606-20060116img_10702788.thumbnail.jpg" mime-type="image/jpeg"
name="thumbnail_4_3" width="80" height="60" />
source="../dpa-Badenwuerttemberg-images/jpeg-1x6a4606-20060116img_10702788.onlineBild.jpg" mime-type="image/jpeg" name="medium_4_3"
width="400" height="300"/>
source="../dpa-Badenwuerttemberg-images/large/jpeg-1x6a4606-20060116img_10702788.large_4_3.jpg" mime-type="image/jpeg" name="large_4_3"
source="../dpa-Badenwuerttemberg-images/small/jpeg-1x6a4606-20060116img_10702788.small_4_3.jpg" mime-type="image/jpeg" name="small_4_3"
<media-caption><p>Der Arzt Michael Oertel klebt auf sein
Praxisschild in Stuttgart die Mitteilung, dass die Praxis geschlossen
ist.</p></media-caption>
</media>
Bilder mit einem bevorzugten Seitenverhältnis von 3:4 werden folgendermaßen repräsentiert:
source="../dpa-Badenwuerttemberg-images/jpeg-1x6a4606-20060116img_10702788.thumbnail.jpg" mime-type="image/jpeg"
source="../dpa-Badenwuerttemberg-images/jpeg-1x6a4606-20060116-
img_10702788.onlineBild.jpg" mime-type="image/jpeg" name="medium_3_4"
source="../dpa-Badenwuerttemberg-images/large/jpeg-1x6a4606-20060116img_10702788.large_3_4.jpg" mime-type="image/jpeg" name="large_3_4"
<media-caption><p>Der Arzt Michael Oertel klebt auf sein
Praxisschild in Stuttgart die Mitteilung, dass die Praxis geschlossen
ist.</p></media-caption>
</media>
2.8.4 Verknüpfung zwischen Texten und Bildern
Bei der Verknüpfung von Texten und Bildern innerhalb einer Meldung werden keine Positionierungen
von Bildern innerhalb des Textes vorgenommen. Bilder werden also nicht bestimmten Stellen
innerhalb des Textes zugewiesen, sondern es wird nur die absolute Beziehung zwischen einem Text
und ein oder mehreren Bildern sowie eine Reihenfolge der Bilder modelliert. Die Kunden können
damit frei entscheiden, wie sie Bilder auf ihrer Web-Site positionieren möchten und welche Bilder auf
welcher Seite wie dargestellt werden sollen. Z.B. können Bilder einzelnen Absätzen des Textes
zugeordnet werden oder in einer eigenen Bildleiste oberhalb, unterhalb oder seitlich vom Text
angeordnet werden. Zusätzlich ist es möglich, bei der Zuweisung von mehr als einem Bild
Bildergalerien zu generieren und mit dem Textdokument zu verknüpfen.
2.8.5 Bildergalerien
Bildergalerien gewinnen für die Kunden der dpa-infocom eine immer größere Bedeutung, da sie viele
zusätzliche ivw-relevante PageImpressions generieren. Zu diesem Zweck führt auch dpa-infocom
Bildergalerien in seinen Diensten ein.
2.8.5.1 Arten von Bildergalerien
Grundsätzlich wird bei dpa-infocom zwischen zwei Arten von Bildergalerien unterschieden –
eigenständige und integrierte Bildergalerien.
Eigenständige Bildergalerien
Eigenständige Bildergalerien werden in den Diensten in speziell ausgezeichneten dpa-Rubriken
gepflegt. In diesen Rubriken werden ausschließlich Bildergalerien bereitgestellt.
Es ist möglich, dass eine Bildergalerie zu einem definierten Zeitpunkt keine, eine oder mehrere
Bildergalerien enthält. Die Anzahl wie auch die Langlebigkeit einer Bildergalerie ist abhängig von der
Beschreibung der jeweiligen dpa-Rubrik. So wird es Rubriken wie die Bilder des Tages in der InfoLine
geben, in der jeden Tag eine neue Bildergalerie eingestellt wird. In anderen Rubriken können
Bildergalerien dagegen mehrere Tage (z.B. die Fotos des Bundesliga-Spieltages) oder Monate (z.B.
die Bilder der Formel1-Saison) stehen bleiben. In allen Fällen ist es aber möglich, dass sich die
einzelnen Bilder, die einer Bildergalerie zugeordnet werden, ändern können. D.h. sobald eine
Bildergalerie bereitgestellt worden ist, können neue Bilder hinzugefügt, bestehende Bilder aktualisiert
und bestehende Bilder gelöscht werden.
Eigenständige Bildergalerien zeichnen sich also dadurch aus, dass die Kunden sich auf bestimmte
Regeln für die Bestückung einstellen können. Das ermöglicht es ihnen, diese Bildergalerien an
prominenter Stelle auf der Web-Site zu positionieren.
Integrierte Bildergalerien
Diese Form von Bildergalerien kann in beliebigen dpa-Rubriken als Teil einer normalen Meldung
vorkommen. Liegen der dpa-infocom-Redaktion zu einer Meldung ausreichend viele Bilder vor und
stellen die Bilder eine interessante Ergänzung zur Meldung dar, publiziert die Redaktion Meldungen
mit integrierten Bildergalerien. Diese Form von Bildergalerien kann also in jeder beliebigen Meldung in
jeder beliebigen dpa-Rubrik als Teil normaler Meldungen vorkommen.
2.8.5.2 Technische Repräsentation
An der technischen Repräsentation von Bildern innerhalb von NITF-Dokumenten ändert sich durch die
Einführung von Bildergalerien nichts. Das hat folgende Gründe:
•
Jeder Kunde muss individuell für sich festlegen, ab welcher Anzahl Bilder in einer zusätzlichen
Bildergalerie dargestellt werden sollen. Manche Kunden legen 3 Bilder als Untergrenze fest,
andere 4 und wieder andere 5.
•
Die technische Umsetzung von Bildergalerien (z.B. Darstellung in einem Popup, Verlinkung
der Bilder zum Vorgänger und Nachfolger etc.) und die Integration in das Layout muss
kundenindividuell erfolgen. dpa-infocom kann lediglich die Kunden durch die Bereitstellung
einer ausreichenden Anzahl von Bildern zu einer Meldung in die Lage versetzen, diese als
Bildergalerien darzustellen.
Bildergalerien werden somit weder gesondert gekennzeichnet noch anders repräsentiert als
Meldungen mit nur einem oder zwei verlinkten Bildern.
Jedes einer Meldung zugeordnete Bild wird durch ein Element media repräsentiert. Innerhalb eines
media-Elementes werden die verschiedenen Bildvarianten (Formate und Größen) repräsentiert.
2.9
Videoinhalte
Die Verwendung von Videoinhalten in den Diensten der dpa-infocom ist wie für die Text- und
Bildinhalte auf eine optimale Nutzung für den jeweiligen Ausgabekanal – Internet, Mobil –
ausgerichtet.
2.9.1 Anwendungsszenarien
Im Internet finden sich derzeit primär zwei Anwendungsszenarien für Videoinhalte: Videogalerien
einerseits und Videos, die in einen Meldungskontext eingebettet sind, andererseits. Beide
Anwendungsszenarien können mit den durch dpa-infocom produzierten Videoinhalten umgesetzt
werden.
Abbildung 8 zeigt beispielhaft die Startseite einer fiktiven Nachrichtensite: Die Redaktion hat
insgesamt fünf Artikel und ein Video als Themencluster zur Berlinale auf die Aufmacherposition der
Übersichtsseite im Newsbereich gestellt. Das Video wird an dieser Stelle zweifach angeteasert:
Einmal über das redaktionelle Bild, das dpa-infocom mitliefert, und zum anderen über den
redaktionellen Text, den dpa-infocom ebenfalls mitliefert (Alternativ könnte an dieser Stelle auch die
Anmoderation eingesetzt werden, so wie das redaktionelle Bild durch eins der drei mitgelieferten
Videostills die visuelle Teaserfunktion übernehmen könnte).
Abbildung 7 Startseite mit Verlinkung zu Video und Videogalerie
Von der zentralen Startseite führen zwei Links - ebenfalls beispielhaft - zu den zwei
Anwendungsszenarien, zum Video im Meldungskontext und zur Videogalerie.
2.9.1.1 Anwendungsszenario Videogalerie
Bei Videogalerien liegt der Fokus auf den Videoinhalten. Es handelt sich um einen eigenen Bereich
einer Web-Site, in der Videos im Mittelpunkt stehen (s. Abbildung 8). Dieser Bereich kann ggf. noch
thematisch strukturiert sein, z.B. nach Ressorts. Eine Videogalerie bzw. eine Rubrik einer Videogalerie
besteht aus einer Menge von Videos. Jedes Video wird durch eine Reihe optionaler Komponenten
angeteasert:
•
eine Überschrift
•
eine kurze Anmoderation, sowie
•
ein oder mehrere Teaserbilder aus dem Video.
Abbildung 8 Beispielhaft umgesetzte Videogalerie
Wählt der User ein Video aus, wird das Video im gleichen oder in einem anderen Fenster gestartet.
Eine Videogalerie kann als HTML-Seite oder als Applikation, z.B. mittels Flash oder Silverlight
umgesetzt sein.
Ein Video, das in einer Videogalerie dargestellt wird, wird i.d.R. selten aktualisiert.
2.9.1.2 Anwendungszenario Videos im Meldungskontext
Bei diesem Anwendungsszenario steht das Nachrchtenthema (hier Berlinale) insgesamt im
Vordergrund. Das Video ist in einen nachrichtlichen Meldungskontext, hier im Ressort Unterhaltung,
eingebettet. Das Nachrichtenthema wird von mehreren, sich ergänzenden Komponenten gebildet.
Dies können ein (oder mehrere) Texte oder ein Bild (oder eine Bildergalerie) und eben ein Video sein.
Das Video kann bei Seitenaufruf selbststartend sein oder der User startet es manuell, entweder auf
der Seite direkt oder in einem eigenen Fenster. Begleitet wird es von der Anmoderation, einem
speziell auf die Inhalte des Videos formulierten Text-Teaser. Darunter folgt das redaktionelle Bild mit
Bildunterschrift. Daneben wurde der redaktionelle Text eingebunden. Der redaktionelle Text stellt
weitergehende Informationen aus der dpa-Nachrichentenwelt zum Thema des Videos bereit. Optional
kann zu der Textmeldung und dem Video noch eine Auswahl aus der Videogalerie dargestellt werden,
damit der User einfach zu anderen, bspw. aktuellen Tages-Videos gelangen kann.
Abbildung 9 Beispielhafte Umsetzung: Anwendungsszenario Video im Meldungskontext.
Auch in diesem Szenario wird das Video i.d.R. selten aktualisiert, während der Meldungstext durchaus
häufiger aktualisiert wird, um den Verlauf des Meldungsgeschehens zu illustrieren.
2.9.2 Komponenten
Ein Video selbst besteht bei dpa-infocom aus verschiedenen Komponenten:
•
Ein oder mehrere Videoformate mit Überschrift und Anmoderation
•
Mehrere (derzeit 3) Still-Bilder
2.9.2.1 Videoformate
Abbildung 10 Videoformat mit Metadaten
Einem Video können ein oder mehrere Videoformate zugewiesen werden, die jeweils den gleichen
Inhalt zeigen, aber für unterschiedliche Zwecke eingesetzt werden können, z.B.:
•
Unterschiedliche Größen für verschiedene Ausgabegeräte
•
Unterschiedliche Mime-Typen für unterschiedliche Abspielgeräte (Video-Player)
•
Unterschiedliche Komprimierung für unterschiedliche Bandbreiten
Zu jedem Videoformat werden eine Reihe von Metainformationen mitgeliefert (s. a. Abbildung 10):
•
Mime-Type (z.B. video/x-flv, video/mpeg, video/quicktime, …); in der ersten Ausbaustufe wird
lediglich video/x-flv ausgeliefert
•
Codec: In der ersten Ausbaustufe wird lediglich H263 als Codec ausgeliefert
•
Gesamte Bitrate
•
Mittlere Bitrate
•
Videobitrate
•
Audiobitrate
•
Frame-Rate
•
Länge in Sekunden
•
Breite
•
Höhe
Darüber hinaus werden zu jedem Videoformat folgende Textinformationen repräsentiert (s. Abbildung
11):
•
Überschrift: Die Überschrift kann als Teil des Teasers zu einem Videoformat oder als alternativer
Text dargestellt werden, wenn das Videoformat selbst beim Kunden nicht abgespielt werden
kann.
•
Anmoderation: Die Anmoderation ist ein Kurztext, der den User in das Video einführen soll.
Abbildung 11 Anmoderation eines Videos
Überschrift und Anmoderation werden in NITF XML 3.0 als Teil des Videoformats ausgeliefert.
Werden zu einem Video mehrere Videoformate ausgeliefert, sind Überschrift und Anmoderation für die
Videoformate meist identisch.
2.9.2.2 Still-Bilder
Abbildung 12 Videostills
Still-Bilder (s. Abbildung 12) sind einzelne, aus dem Video extrahierte Bilder. Still-Bilder werden mit
den gleichen Metainformationen und Inhalten ausgeliefert wie andere Bilder auch, erweitert um den
Offset, d.h. den Zeitpunkt des Still-Bildes innerhalb des Videos. Aktuell werden zu jedem Video drei
Still-Bilder mitgeliefert. Dies kann sich in Zukunft aber ändern.
2.9.3 Repräsentation
Videoinhalte können als eigenständige Videodokumente oder als Teil eines Textdokumentes
repräsentiert werden, das ein Video analog wie Bildern referenziert. In beiden Fällen ist die
Repräsentation der zu einem Video gehörenden Komponenten (s.o.) identisch.
2.9.3.1 Komponenten eines Videos
Die zum Video gehörenden Komponenten werden als block innerhalb des body.content
repräsentiert. Blöcke, die ein Video identifizieren werden mit dem Attribut class=“video“
ausgezeichnet. Innerhalb des Blocks wird jedes Videoformat und jedes Stillbild als eigenes mediaElement repräsentiert:
<block class="video">
<media media-type="video">
<media-metadata name="codec" value="H263"/>
<media-metadata name="totalbitrate" value="928"/>
<media-metadata name="averagebitrate" value="895"/>
<media-metadata name="videobitrate" value="800"/>
<media-metadata name="audiobitrate" value="128"/>
<media-metadata name="framerate" value="25.0"/>
<media-reference alternate-text="Video-Überschrift oder -Alt-Text"
source="../dpa-VideoLine-images/video/video-1.flv" mime-type="video/xflv" coding="H263" width="720" height="576" time="74" time-unit-ofmeasure="seconds"/>
<media-caption><p>Hier wird die Anmoderation zum Video
repräsentiert.</p></media-caption>
</media>
<media-metadata name="codec" value="VP6"/>
<media-reference alternate-text="Video-Überschrift oder -Alt-Text"
source="../dpa-VideoLine-images/video/video-1a.flv" mimetype="video/x-flv" coding="VP6" width="720" height="576" time="74"
time-unit-of-measure="seconds"/>
<media-caption><p>Hier wird die Anmoderation zum
Videorepräsentiert</p></media-caption>
</media>
<media-metadata name="offset" value="00:00:16:09"/>
<media-reference alternate-text="Immobilien-Gutachten"
source="../dpa-VideoLine-images/Eigenheim_14636768.thumbnail.jpg"
mime-type="image/jpeg" name="thumbnail_4_3" width="79" height="59" />
source="../dpa-VideoLine-images/Eigenheim_14636768.onlineBild.jpg"
mime-type="image/jpeg" name="medium_4_3" width="399" height="299" />
source="../dpa-VideoLineimages/small/Eigenheim_14636768.original.small-16-9-200-1867-12472067-1360.jpg" mime-type="image/jpeg" name="small_16_9" width="200"
height="112" />
height="133" />
height="200" />
height="150" />
height="200" />
source="../dpa-VideoLineimages/large/Eigenheim_14636768.original.large-4-3-800-1567-1004-23671604.jpg" mime-type="image/jpeg" name="large_4_3" width="800"
height="600" />
<media-caption><p>Hier kommt die Bildunterschrift vom Bild
hin.</p></media-caption>
</media>
</block>
Einige Erläuterungen zum Format:
•
Die zu einem Video gehörenden Videoformate werden als media-Elemente mit dem Attribut
media-type=“video“ repräsentiert.
•
Die Binärdaten eines Videoformats werden in einem eigenen Unterordner des Ordners für
Binärdaten repräsentiert, also z.B. dpa-VideoLine-images/video
•
Die zu einem Video gehörenden Still-Bilder werden als media-Elemente mit dem Attribut
media-type=“image“ repräsentiert.
•
Die Repräsentation eines Still-Bildes ist identisch mit der Repräsentation normaler Bilder,
ergänzt um den Offset. Der Offset wird im Element media-metadata mit dem Attribut
name="offset" im Attribut value mit dem Format <hh>:<mm>:<SS>:<ss> repräsentiert:
o
<hh>: Zwei Ziffern für die Stunden
o
<mm>: Zwei Ziffern für die Minuten
o
<SS>: Zwei Ziffern für die Sekunden
o
<ss>: Zwei Ziffern für die Millisekunden
2.9.3.2 Videos als eigenständige Dokumente
Werden Videos als eigenständige NITF-Dokumente repräsentiert, können sie als Teil einer
Videogalerie eingebunden werden. Für solche Videodokumente werden im Kopf des NITFDokumentes zusätzliche Metainformationen repräsentiert:
"nitf.dtd" -->
<nitf>
<head>
<title>Wien im Walzertakt</title>
<docdata>
<fixture fix-id="/videoline/service/"/>
<date.issue norm="20070531T090321+0200"/>
<key-list>
<keyword key="Stichwort1/Stichwort2/"/>
</key-list>
</docdata>
</head>
<body>
<body.content>
<media-reference alternate-text="Wien im Walzertakt" source="../dpaVideoLine-images/video/video-1.flv" mime-type="video/x-flv"
coding="H263" width="720" height="576" time="74" time-unit-ofmeasure="seconds"/>
<media-caption><p>Pomp und Prominenz in Wien. Mit dem
Eröffnungskommando “Alles Walzer” hat der 52. Wiener Opernball gestern
abend begonnen. Edelstripperin Dita von Teese schritt im silbergrauen
Ballkleid auf Einladung des Baulöwen Richard “Mörtel” Lugner in die
Staatsoper. Mit von der Partie waren außerdem Opernsängerin Anna
Netrebko und US-Schauspielerin Teri Hatcher.</p></media-caption>
</media>
<media-reference alternate-text=" Wien im Walzertakt "
</media>
<media-reference alternate-text=" Anna Netrebko " source="../dpaVideoLine-images/Eigenheim_14636768.thumbnail.jpg" mimetype="image/jpeg" name="thumbnail_4_3" width="79" height="59" />
<media-reference alternate-text=" Anna Netrebko " source="../dpaVideoLine-images/Eigenheim_14636768.onlineBild.jpg" mimetype="image/jpeg" name="medium_4_3" width="399" height="299" />
<media-reference alternate-text=" Anna Netrebko " source="../dpaVideoLine-images/small/Eigenheim_14636768.original.small-16-9-200Copyright © 2012 von dpa - Deutsche Presse-Agentur GmbH
1867-1247-2067-1360.jpg" mime-type="image/jpeg" name="small_16_9"
width="200" height="112" />
<media-reference alternate-text=" Anna Netrebko " source="../dpaVideoLine-images/small/Eigenheim_14636768.original.small-3-2-200-18671237-2067-1370.jpg" mime-type="image/jpeg" name="small_3_2"
<media-reference alternate-text=" Anna Netrebko " source="../dpaVideoLine-images/large/Eigenheim_14636768.original.large-4-3-800-15671004-2367-1604.jpg" mime-type="image/jpeg" name="large_4_3"
<media-caption><p> Anna Netrebko schaut interessiert</p></mediacaption>
</media>
</block>
</body.content>
</body>
</nitf>
2.9.3.3 Videos als Teil von Textmeldungen
Werden Videos als Teil von Textmeldungen repräsentiert, wird das Block-Element, welches das Video
repräsentiert, in das NITF-Dokument eingebunden, das den Meldungstext repräsentiert. Der Kunde
kann Videos in solchen Dokumenten jedoch für beide Anwendungsszenarien weiterverarbeiten:
•
Sollen lediglich die Videos in einer Video-Galerie repräsentiert werden, werden nur die im
Video-Block repräsentierten Inhalte für die Videogalerie übernommen.
•
Soll die Einbindung der Videos im Meldungskontext erfolgen, müssen die gesamten
Informationen des NITF-Dokumentes ausgewertet werden.
Eine Textmeldung kann mehr als ein Video referenzieren. Darüber hinaus können auch weitere
Binärinhalte – Bilder und Audioinhalte – repräsentiert werden, die nicht Teil des Videos sind. Die
Repräsentation dieser Binärinhalte erfolgt wie in den entsprechenden Abschnitten beschrieben.
Folgendes Beispiel zeigt eine Textmeldung mit je einem referenzierten Bild und Video. Das Video
selbst referenziert wiederum ein Videoformat sowie 3 Stillbilder zum Video:
<!DOCTYPE nitf PUBLIC "-//IPTC-NAA//DTD NITF-XML 3.0//EN"
"nitf.dtd">
<head>
<title>Edelstripperin und Fußball beim Wiener Opernball</title>
<meta name="copyright" content="dpa - Deutsche Presse-Agentur
GmbH"/>
<meta name="variant" content="3498933434"/>
<tobject>
tobject.subject.code="ACE"/>
</tobject>
<docdata>
<evloc iso-cc="EST"/>
<fixture fix-id="/eol/general"/>
<date.issue norm="20010513T193050+0200"/>
<doc-scope scope="x"/>
<key-list>
<keyword key="Culture/Eurovision/"/>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline>
<hl1>Edelstripperin und Fußball beim Wiener Opernball</hl1>
</hedline>
<byline>
</byline>
</body.head>
<body.content>
<p>Wien (dpa) – Nach dem Eröffnungskommando “Alles Walzer” haben sich
am Donnerstagabend Pomp, Prominenz und Debütanten auf dem Wiener
Opernball im Dreivierteltakt gedreht.</p>
<p>Vor allem runde Formen dominierten in diesem Jahr die 52. Ausgabe
des Walzerspektakels: Edelstripperin Dita von Teese schritt im
silbergrauen Ballkleid auf Einladung des Baulöwen Richard “Mörtel”
Lugner in die Staatsoper, im Showprogramm drehte sich vieles um die in
Österreich stattfindende Fußball-Europameisterschaft.</p>
<media-reference alternate-text="Dita von Teese und Richard Lugner"
source="../dpa-VideoLine-images/jpeg-1x6a4606-20060116img_10702788.thumbnail.jpg" mime-type="image/jpeg"
source="../dpa-VideoLine-images/jpeg-1x6a4606-20060116img_10702788.onlineBild.jpg" mime-type="image/jpeg" name="medium_4_3"
source="../dpa-VideoLine-images/large/jpeg-1x6a4606-20060116img_10702788.large_4_3.jpg" mime-type="image/jpeg" name="large_4_3"
source="../dpa-VideoLine-images/small/jpeg-1x6a4606-20060116img_10702788.small_4_3.jpg" mime-type="image/jpeg" name="small_4_3"
<media-caption><p>Dita von Teese und Richard Lugner</p></mediacaption>
</media>
<media-reference alternate-text="Wien im Walzertakt" source="../dpaVideoLine-images/video/video-1.flv" mime-type="video/x-flv"
coding="H263" width="720" height="576" time="74" time-unit-ofmeasure="seconds"/>
</media>
<media-reference alternate-text=" Wien im Walzertakt "
</media>
<media-reference alternate-text="Anna Netrebko" source="../dpaVideoLine-images/netrebko_14636768.thumbnail.jpg" mimetype="image/jpeg" name="thumbnail_4_3" width="79" height="59" />
<media-reference alternate-text="Anna Netrebko" source="../dpaVideoLine-images/netrebko_14636768.onlineBild.jpg" mimetype="image/jpeg" name="medium_
4_3" width="399" height="299" />
<media-reference alternate-text="Anna Netrebko" source="../dpaVideoLine-images/small/netrebko_14636768.original.small-16-9-200-18671247-2067-1360.jp
g" mime-type="image/jpeg" name="small_16_9" width="200" height="112"
/>
<media-reference alternate-text="Anna Netrebko" source="../dpaVideoLine-images/small/netrebko_14636768.original.small-3-2-200-18671237-2067-1370.jpg
" mime-type="image/jpeg" name="small_3_2" width="200" height="133" />
<media-reference alternate-text="Anna Netrebko" source="../dpaVideoLine-images/large/netrebko_14636768.original.large-4-3-800-15671004-2367-1604.jpg
" mime-type="image/jpeg" name="large_4_3" width="800" height="600" />
<media-caption><p>Anna Netrebko schaut interessiert</p></mediacaption>
</media>
</block>
</body.content>
<body.end/>
</body>
</nitf>
2.10 Verzeichnisstrukturen
Die Anlieferung der Inhalte erfolgt in einer fest vorgegebenen Verzeichnisstruktur. Dabei hat jeder
Dienst ein eigenes Basisverzeichnis, das den Dienst eindeutig identifiziert. Ausgehend von diesem
Basisverzeichnis gibt es vier Unterverzeichnisse:
•
Index-Verzeichnis: In diesem Verzeichnis werden alle Reihenfolgedokumente bereitgestellt.
Für jede Rubrik gibt es ein eigenes Reihenfolgedokument mit den Referenzen auf die
eigentlichen Inhaltsdokumente.
•
XML-Verzeichnis für Inhaltsdokumente: In diesem Verzeichnis werden die eigentlichen
Inhaltsdokumente abgelegt. Diese Inhaltsdokumente können ggf. Referenzen auf Binärdokumente enthalten.
•
Binär-Verzeichnis: In diesem Verzeichnis werden Binärdateien bereitgestellt, die aus den
Inhaltsdokumenten verlinkt werden.
•
Berichtigungsverzeichnis:
bereitgestellt.
In
diesem
Verzeichnis
werden
Berichtigungsdokumente
Mit Ausnahme des Binärverzeichnisses enthalten diese vier Unterverzeichnisse selbst keine weiteren
Unterverzeichnisse. Dies bedeutet insbesondere auch, dass die Rubrikstruktur nicht durch eine
entsprechende Verzeichnisstruktur abgebildet wird, sondern ausschließlich innerhalb der Reihenfolgeund Inhaltsdokumente abgebildet wird.
Im Binär-Verzeichnis gibt es anders als in den anderen Verzeichnissen weitere Unterverzeichnisse:
•
Aus historischen Gründen werden direkt im Binärverzeichnis die Bildformate Thumbnail und
Medium sowie die Audio-Dokumente repräsentiert.
•
Die Bildformate Small und Large werden dagegen in eigenen Unterverzeichnissen small
und large repräsentiert.
•
Binärdaten für Videoformate werden im Unterverzeichnis video repräsentiert.
Standardmäßig werden nur die Daten aus dem Basisverzeichnis ausgeliefert. Die Daten aus den
Unterverzeichnissen können in Absprache zwischen dpa und dem Kunden flexibel zusätzlich
aufgeschaltet werden. Benötigt ein Kunde eine der Bildvarianten im Format small, wird das
Unterverzeichnis zusätzlich mit allen Bildvarianten im Format small ausgeliefert. Dies hat den
Hintergrund, dass durch die zusätzlichen Bildformate ein erhöhter Datentraffic für die Auslieferung
anfällt. Das kann einerseits bei einer reduzierten Internetanbindung des Kunden zu Verzögerungen in
der Anlieferung führen. Andererseits haben viele Kunden volumenbasierte Anbindungen, so dass die
Übertragung überflüssiger Daten zusätzliche Kosten verursachen würde.
Mit Ausnahme der dpa-InfoLine folgt die Bezeichnung des Basisverzeichnisses und der
Unterverzeichnisse bestimmten Regeln. Für einen Dienst dpa-<Dienstname> wird folgende
Verzeichnisstruktur angelegt:
•
<Dienstname>/dpa-<Dienstname>-index: Index-Verzeichnis
•
<Dienstname>/dpa-<Dienstname>: XML-Verzeichnis für Inhaltsdokumente
•
<Dienstname>/dpa-<Dienstname>-images: Binär-Verzeichnis
•
<Dienstname>/dpa-<Dienstname>-correction: Berichtigungsverzeichnis
3 Die dpa-Meldung im erweiterten “NITF 3.0 XML”-Format
In diesem Kapitel wird auf die von der dpa-infocom zur Zeit verwendeten Elemente und Attribute von
“NITF 3.0 XML” eingegangen. Zudem wird erläutert, an welcher Stelle jeweils die Elemente im XMLDokument stehen können. Die genauen Definitionen für die Elemente und deren Positionen im NITFDokument müssen der “NITF 3.0 XML”-DTD entnommen werden. (Siehe auch Anhang F. Erweiterte
DTD "NITF 3.0 XML") Zu berücksichtigen ist schließlich, dass dpa-infocom eine gegenüber dem
Standard der IPTC erweiterte DTD einsetzt, da aus historischen Gründen zusätzlich das Element b
verwendet wird. (Siehe auch den Abschnitt 3.49)
3.1
Kodierung und verwendete Zeichensätze
Die “NITF 3.0 XML”-Dokumente benutzen die Kodierung UTF-8. Dabei werden durch die dpa zur Zeit
Zeichen aus den Zeichensätzen Basic Latin, Latin-1 Supplement, Latin Extenced-A und Currency
Symbols verwendet (Änderungen sind vorbehalten). (Siehe auch Anhang D. Verwendete Zeichen)
3.2
Das Wurzelelement nitf
Elementname: nitf
Beispiel:
<nitf>
...
</nitf>
Erklärung:
Das Wurzelelement aller NITF-Dokumente ist nitf. Es umfasst alle Meldungsdaten. Im Moment
werden keine Attribute dieses Elementes verwendet. (Siehe auch DTD-Element nitf)
3.3
Der Dokumentenkopf head
Elementname: head
Beispiel:
<nitf>
<head>
...
</head>
...
</nitf>
Erklärung:
Der Dokumentenkopf enthält einen Großteil der Metainformationen. Das Element head ist ein KindElement von nitf. (Siehe auch DTD-Element head)
3.4
Der Titel title
Elementname: title
Beispiel:
<head>
<title>Estonians stage jubilant welcome to European song fest
victors</title>
</head>
Erklärung:
Der Titel eines “NITF 3.0 XML”-Dokuments wird meist für Kurzübersichten verwendet und hat
meistens den gleichen Inhalt wie die Meldungsüberschrift. Das Element title ist ein Kind-Element
von head. (Siehe auch DTD-Element title)
3.5
Die META-Elemente meta
Element:
meta
Attribute:
name: der Name des Metaelementes
content: der Wert des Metaelementes
Beispiel:
<head>
...
<meta
<meta
GmbH"/>
<meta
<meta
...
</head>
name="origin" content="dpa - Deutsche Presse-Agentur GmbH"/>
name="copyright" content="dpa - Deutsche Presse-Agentur
name="generator" content="CoreMedia 3.3"/>
name="variant" content="4711" />
Erklärung:
Das Element meta ist ein Kind-Element von head und kann Angaben zum Ursprung, zum Copyright,
zur Versionskennung und zur internen Information haben.
•
Ursprung
Der Ursprung des Produktes, dem das Dokument angehört, wird mit dem name-Attribut
origin angegeben.
•
Copyright
Die Copyright-Bemerkung zum Produkt, dem das Dokument angehört, wird mit dem nameAttribut copyright angegeben.
•
Variantenkennung
Die Variantenkennung wird mit dem name-Attribut variant angegeben (Siehe auchden
Abschnitt Varianten)
•
Interna
Zur Zeit wird zur internen Information das META-Element <meta name="generator"
content="CoreMedia"/> verwendet.
(Siehe auch DTD-Element meta)
3.6
Der Subject-Code tobject.subject
Elementname: tobject.subject
Attribute:
tobject.subject.refnum: 8-ziffrige Referenznummer des Subject-Codes
tobject.subject.code: dreibuchstabiger Code für den Subject-Type
Beispiel:
<head>
...
<tobject>
</tobject>
...
</head>
Erklärung:
Die Subject-Codes können für eine inhaltliche Sortierung der Meldungen herangezogen werden. Bei
den Subject-Codes handelt es sich um eine Standardisierung der IPTC, der für den internationalen
Meldungsaustausch von Agenturen gedacht ist. Jeder Code besteht aus einer achtstelligen Zahl, die
mehrere Themenebenen repräsentiert. Die dpa-infocom verwendet bei den meisten Diensten jedoch
derzeit nur die oberste Themenebene, das sogenannte Subject, für das es 17 mögliche Codes gibt. In
Zukunft ist aber geplant, in allen Diensten alle Themenebenen zu unterstützen. Eine Liste möglicher
Subject-Codes gibt es im Anhang B. Subject-Codes. Die Codes ermöglichen bei Verwendung der
obersten Themenebene eine grobe, bei Verwendung aller Themenebenen eine feine thematische
Kategorisierung des Meldungsmaterials. (Siehe auch DTD-Element tobject.subject)
Zu beachten ist, dass dieses Element optional ist, da nicht jede von dpa-infocom gelieferte Meldung
einen Subect-Code zugewiesen bekommt. Außerdem können einem Dokument potentiell auch
mehrere Subject-Codes zugeordnet werden.
3.7
Die Dokument-Metadaten docdata
Elementname: docdata
Beispiel:
<head>
...
<docdata>
...
</docdata>
...
</head>
Erklärung:
Das Element docdata ist ein Kind-Element von head und enthält Metadaten des entsprechenden
Dokuments. (Siehe auch DTD-Element docdata)
3.8
Die Länderkennung evloc
Elementname: evloc
Attribute:
iso-cc: die dreistellige Länderkennung
Beispiel:
<docdata>
<evloc iso-cc=“GER“ />
</docdata>
Erklärung:
Das Element evloc ist ein Kind-Element von docdata. Es repräsentiert das Herkunftsland in Form
einer dreistelligen Länderkennung, die der Norm ISO-3166, erweitert um dpa-spezifische
Länderkennungen, entspricht, Die Repräsentation der Länderkennung erfolgt im Attribug iso-cc.
Eine aktuelle Liste befindet sich im Anhang C Länderkennung. (Siehe auch DTD-Element evloc)
Die Länderkennung kann zu einer zusätzlichen Kategorisierung nach dem Herkunftsland verwendet
werden.
Dieses Element ist optional. Von dpa-infocom wird nicht garantiert, dass jede Meldung mit einer
Länderkennung versehen ist.
3.9
Die UID doc-id
Elementname: doc-id
Attribute:
reg-src: die vergebende Instanz
id-string: die Identifikation und die Versionsnummer getrennt durch ein ‚:’
Beispiel:
<docdata>
<doc-id reg-src=“dpa-infocom“ id-string=“6841086:1096355229000“ \>
</docdata>
Erklärung:
Das Element doc-id ist ein Kind-Element von docdata zur Repräsentation der UID. (Siehe auch
DTD-Element doc-id).
3.10 Die redaktionelle Information ed-msg
Element:
ed-msg
Attribute:
info
Beispiel:
<docdata>
<ed-msg info=“Das Zitat von xxx darf nicht mehr verwendet werden.“
/>
</docdata>
Erklärung:
Bei Berichtigungsdokumenten liefert die Redaktion der dpa-infocom einen Hinweis zum Grund der
Berichtigung, der in diesem Element repräsentiert wird.
3.11 Die Priorität urgency
Element:
urgency
Attribute:
ed-urg
Beispiel:
<docdata>
<urgency ed-urg=“4“ />
</docdata>
Erklärung:
Die Dringlichkeit von Agenturmeldungen wird durch Prioritäten gesteuert. Sehr wichtige Ereignisse
werden mit hohen Prioritäten (kleine Ziffer) gekennzeichnet, Randereignisse durch niedrige Prioritäten
(hohe Ziffern). Diese Prioritäten werden von den Redakteuren der dpa-infocom vergeben und können
nach Bedarf ausgewertet werden. Das Prioritäts-Element urgency ist ein Kind-Element von
docdata. Die Priorität wird im Attribut ed-urg angegeben und liegt im Gegensatz zur “NITF 3.0
DTD” zwischen 1 und 6. Dabei entspricht die Ziffer 1 der höchsten und die Ziffer 6 der kleinsten
Priorität. Üblicherweise werden dpa-Meldungen mit der Priorität 3 oder 4 gesendet. (Siehe auch DTDElement urgency)
3.12 Die dpa-Rubrik fixture
Element:
fixture
Attribute:
fix-id: die dpa-Rubrik
Beispiel:
<docdata>
<fixture fix-id=“/sportsline/fussball/bundesliga1/news“ />
</docdata>
Erklärung:
Das wichtigste Rubrizierungskriterium in den Diensten der dpa-infocom ist die dpa-Rubrik (Siehe auch
den Abschnitt dpa-Rubriken und Nachrichtenmanagement). Die Zuordnung zu einer Rubrik wird durch
das Attribut fix-id im Element fixture beschrieben, einem Kind-Element von docdata. (Siehe
auch DTD-Element fixture)
In allen Diensten beginnt die dpa-Rubrik mit dem Dienstnamen (z.B. sportsline für die dpaSportsLine oder starline für die dpa-StarLine).
3.13 Datum der Meldung date.issue
Elementname: date.issue
Attribute:
norm: das Publikationsdatum nach ISO-8601
Beispiel:
<docdata>
<date.issue norm=“20011107T111500+0100“ />
</docdata>
Erklärung:
Die Publikationszeit der Meldung ist im Element date.issue enthalten. Dieses Element ist aus
redaktioneller Sicht wichtig, um z.B. als Sortierkriterium der Nachrichten auf Basis der Aktualität zu
dienen. Die Publikationszeit kann von der Dateizeit (Uhrzeit der letzten Speicherung) des NITFDokumentes abweichen. Die Dateizeit spielt aus technischer Sicht eine Rolle, um festzustellen, wann
ein NITF-Dokument aktualisiert worden ist.
Das Publikationszeit-Element date.issue ist ein Kind-Element von docdata. Das
Publikationsdatum wird nach der ISO-8601 im Attribut norm angegeben (Siehe auch DTD-Element
date.issue).
3.14 Das Ressort doc-scope
Elementname: doc-scope
Attribute:
scope: das Ressort
Beispiel:
<docdata>
<doc-scope scope=“pl“ />
</docdata>
Erklärung:
Für eine inhaltliche Sortierung können auch die fünf klassischen Ressorts herangezogen werden:
Ressort
Kürzel
Politik
pl
Vermischtes vm
Wirtschaft
wi
Kultur
ku
Sport
sp
Tabelle 1: Ressorts
Diese Ressorts können nützlich sein, um eine Mischrubrik zu gestalten. Beispielsweise kann die
Mischrubrik “/infoline/brennpunkte” der dpa-Infoline in die klassischen Ressorts Politik und
Vermischtes aufgespaltet werden. Das Ressort-Element doc-scope ist ein Kind-Element von
docdata. Das Ressort wird im Attribut scope angegeben. (Siehe auch DTD-Element doc-scope)
3.15 Die Stichwortliste key-list
Elementname: key-list
Beispiel:
<docdata>
<key-list><keyword key=“Kultur/Eurovision/“ />
</docdata>
Erläuterung:
Für eine weitergehende thematische Kategorisierung können die mehr als 200 Stichwörter hilfreich
sein. Dokumente können mehrere, durch „/“ getrennte Stichworte enthalten. Zu beachten ist, dass
lediglich das Erststichwort aus einer fest definierten Liste von Stichworten stammt. Weiter Stichwörter
können durch die Redakteure frei gewählt werden und eignen sich somit nicht für eine
Kategorisierung. Das Element keylist ist ein Kind-Element von docdata. Die Stichwörter werden
im Attribut key des Kind-Elementes keyword angegeben. (Siehe auch DTD-Element key-list)
3.16 Identifizierte Entitäten identified-content
Elementname: identified-content
Beispiel:
<org idsrc="ISIN" value="SE0000108656">ERICSSON(L.M.)(TELEF</org>
Erläuterung:
In Meldungen können identifizierbare Entitäten wie z.B. Personen oder Organisationen enthalten sein.
Solche Entitäten werden innerhalb dieses Elementes aufgelistet. Derzeit werden allerdings
ausschließlich Organisationen innerhalb der dpa-AFXLine repräsentiert.
3.17 Organisationen org
Elementname: org
Attribute:
idsrc: Die Taxonomie, auf der der Wert des Attributes beruht. Derzeit wird als Taxonomie
ausschließlich die ISIN repräsentiert.
value: Der Wert, der die Organisation identifiziert.
Beispiel:
<org idsrc="ISIN" value="SE0000108656">ERICSSON(L.M.)</org>
Erläuterung:
Organisationen werden bei dpa-infocom über die ISIN identifiziert. Zusätzlich wird innerhalb des
Elementes der Name der Organisation in Großbuchstaben repräsentiert.
3.18 Klassifizierungen classifier
Elementname: classifier
Attribute:
idsrc: Die Taxonomie, auf der der Wert des Attributes beruht. Derzeit werden als Taxonomien
UPC, ISBN13 und IATA repräsentiert.
value: Der Wert, der Klassifikation identifiziert.
Beispiel:
<classifier idsrc="UPC" value="4711">Der Name des
Produkts</classifier>
<classifier idsrc="ISBN13" value="1232452342352">Der Name des
Buchs</classifier>
<classifier idsrc="IATA" value="HAM">Der Name des
Flughafens</classifier>
Erläuterung:
dpa-infocom unterstützt verschiedene Klassifizierungen, um Inhalte mit Affiliate-Programme über
Fremdschlüssel verknüpfen zu können.
3.19 Orte location
Elementname: location
Attribute:
class: Zur Unterscheidung von Orten der Meldung (scope) und Orten in der Meldung
(address)
Beispiel:
<location class=”scope”>
</location>
<location class=”address”>
</location>
Erläuterung:
Orte werden bei der dpa-infocom innerhalb von identified-content repräsentiert und nach
Hierarchieebenen strukturiert.
3.20 Länder country
Elementname: country
Attribute:
iso-cc: Dreibuchstabiges Länderkürzel nach ISO-3166-1
Beispiel:
<location class=”address”>
<country iso-cc=”DEU”>Deutschland</country>
</location>
Erläuterung:
Länder bilden die oberste Ebene der Ortshierarchie. Bei Orten der Meldung umfasst der Inhalt des
Elementes optional auch eine Geocodierung.
3.21 Staaten state
Elementname: state
Attribute:
state-code: Länderspezifischer Code zur Identifikation des Staates / Bundeslandes.
code-source: Die verwendete Taxonomie für den state-code. In Deutschland wird der
Amtliche Gemeindeschlüssel (AGS) verwendet.
Beispiel:
<state state-code=”05000000” code-source=”AGS”>NordrheinWestfalen</country>
</location>
Erläuterung:
Staaten / Bundesländer bilden die zweite Ebene der Ortshierarchie. Bei Orten der Meldung umfasst
der Inhalt des Elementes optional auch eine Geocodierung.
3.22 Regionen region
Elementname: region
Attribute:
region-code: Optional länderspezifischer Code zur Identifikation der Region.
code-source: Die verwendete Taxonomie für den region-code. In Deutschland wird der
Amtliche Gemeindeschlüssel (AGS) verwendet. Nur, wenn auch ein region-code
angegeben ist.
Beispiel:
<region region-code=”05354000” code-source=”AGS”>Aachen</country>
</location>
Erläuterung:
Regionen bilden die dritte Ebene der Ortshierarchie. In Deutschland sind dies die Kreise / Kreisfreien
Städte. Bei Orten der Meldung umfasst der Inhalt des Elementes optional auch eine Geocodierung.
3.23 Städte city
Elementname: city
Attribute:
city-code: Optional länderspezifischer Code zur Identifikation der Stadt.
code-source: Die verwendete Taxonomie für den city-code. In Deutschland wird der
Amtliche Gemeindeschlüssel (AGS) verwendet. Nur, wenn auch ein city-code angegeben
ist.
Beispiel:
<city city-code=”05354000” code-source=”AGS”>Aachen</country>
</location>
Erläuterung:
Städte bilden die vierte Ebene der Ortshierarchie. Bei Orten der Meldung umfasst der Inhalt des
Elementes optional auch eine Geocodierung.
3.24 Die Meldung body
Elementname: body
Beispiel:
<nitf>
<head>
...
</head>
<body>
...
</body>
</nitf>
Erklärung:
Das Element body ist ein Kind-Element von nitf. Innerhalb dieses Elementes befinden sich der
Meldungskopf, der Meldungsinhalt und der Meldungsfuß. (Siehe auch DTD-Element body)
3.25 Der Meldungskopf body.head
Elementname: body.head
Beispiel:
<body>
<body.head>
...
</body.head>
...
</body>
Erklärung:
Das Element body.head ist ein Kind-Element von body und kann Informationen wie Überschrift und
Autor enthalten. (Siehe auch DTD-Element body.head)
3.26 Der Überschriftenbereich hedline
Elementname: hedline
Beispiel:
<body.head>
<hedline>
...
</hedline>
</body.head>
Erklärung:
Das Element hedline ist ein Kind-Element von body.head. Innerhalb dieses Elementes werden alle
Informationen zu Überschriften abgelegt. Dazu gehören z.B. die Überschriften, Unter-Überschriften
und der Verfasser der Meldung. (Siehe auch DTD-Element hedline)
3.27 Die Überschrift hl1
Elementname: hl1
Beispiel:
<hedline>
<hl1>Estonische Gruppe gewinnt Grand Prix</hl1>
</hedline>
Erklärung:
Das Element hl1 ist ein Kind-Element von hedline und enthält die Hauptüberschrift. Die Überschrift
der Meldung kann potentiell auch Kind-Elemente enthalten, obwohl dies zur Zeit nicht vorkommt. Die
genaue Syntax kann der DTD für “NITF 3.0 XML” entnommen werden. (Siehe auch DTD-Element hl1)
3.28 Die Unter-Überschriften hl2
Elementname: hl2
Beispiel:
<hedline>
<hl2>Ãœberraschender Gewinner</hl2>
</hedline>
Erklärung:
Das Element hl2 ist ein Kind-Element von hedline und dient der Repräsentation von
Unterüberschriften. Potentiell kann es eine Reihe von Unter-Überschriften geben. (Siehe auch DTDElement hl2)
3.29 Die Autoren-Zeile byline
Elementname: byline
Beispiel:
<body.head>
<byline>von Christoph Dernbach</byline>
</body.head>
Erklärung:
Das Element byline ist ein Kind-Element von body.head. Die Autoren-Zeile enthält den Verfasser
der Meldung.
Im Gegensatz zu den meisten Meldungen tragen einige Berichte Autorennamen. Diese detaillierten
Berichte werden Korrespondentenberichte genannt. Der Name des Verfassers befindet sich in diesem
Falle innerhalb des byline-Elementes. (Siehe auch DTD-Element byline)
Dieses Element ist optional.
3.30 Meldungsinhalt body.content
Elementname: body.content
Beispiel:
<body>
...
<body.content>
...
</body.content>
...
</body>
Erklärung:
Das Element body.content ist ein Kind-Element von body. Es enthält den eigentlichen
Meldungsinhalt. (Siehe auch DTD-Element body.content)
3.31 Text p
Elementname: p
Beispiel:
<body.content><p>Tallinn (dpa) - Tens of thousands of people gave the
Estonian winners of the Grand Prix Eurovision song festival a
triumphal welcome when they returned home on Sunday evening. Fans
awaited singers Tanel Padar and Dave Benton at the airport and at the
market place, the historical centre of the capital Tallinn. Observers
said Estonia did not seen such fanfare even when its olympical gold
medal winners returned home. The gathered masses stopped traffic,
waving banners with "Estonia" and the names of the new pop
heroes.</p></body.content>
Erklärung:
Einfacher Text wird in Absätze gegliedert. Jeder einzelne Absatz einer Meldung wird durch das
Element p umschlossen. Auf diese Weise kann zum Beispiel der erste Absatz, der von den dpaRedakteuren knapp gehalten wird, als “Lead” auf einer Übersichtsseite ausgelesen werden.
Es darf kein einfacher Text direkt im Element body.content vorkommen. Der Meldungstext muss
mindestens in einen Paragraphen eingebettet sein. Diese Paragraphen werden mit p eingeschlossen.
Innerhalb des p-Elementes können, zusätzlich zum einfachen Text, auch Hyperlinks, Zeilenumbrüche
und Betonungen enthalten sein. (Siehe auch DTD-Element p)
3.32 Tabellen table
Elementname: table
Atribute:
id: optional dokumentenweit eindeutige Identifikation
Beispiel:
<body.content>
<table>
<thead>..</thead>
<tfoot> </tfoot>
<tbody>..</tbody>
</table>
</body.content>
Erklärung:
Das Element table dient der Repräsentation von Tabellen und kommt innerhalb des body.content
vor. Tabellen bestehen analog zur Repräsentation in HTML aus einem Tabellenkopf thead, einem
Tabellenfuß tfoot und dem Tabelleninhalt tbody. Die Tabelle kann das Attribut id enthalten. Der
Tabellenkopf und der Tabellenfuß werden optional benutzt. (Siehe auch DTD-Element table)table
3.33 Tabellenkopf thead
Elementname: thead
Atribute:
keine
Beispiel:
<table>
<thead>
<tr><th>..</th><th>..</th></tr>
</thead>
</table>
Erklärung:
Das Element thead dient der Repräsentation von Spaltenüberschriften und kommt innerhalb des
table vor. Der Tabellenkopf besteht aus ein oder mehreren Tabellenzeilen tr, die wiederum aus
einer Reihe von Tabellenheadern th bestehen. (Siehe auch DTD-Element thead)
3.34 Tabellenende tfoot
Elementname: tfoot
Atribute:
keine
Beispiel:
<table>
<tfoot>
<tr><td>..</td><td>..</td></tr>
</tfoot>
</table>
Erklärung:
Das Element tfoot dient der Repräsentation des Tabellenendes und kommt innerhalb des table
vor. Das Tabellenende besteht aus ein oder mehreren Tabellenzeilen tr, die wiederum aus einer
Reihe von Tabellenspalten td bestehen. (Siehe auch DTD-Element tfoot)
3.35 Tabelleninhalt tbody
Elementname: tbody
Atribute:
keine
Beispiel:
<table>
<tbody>
<tr><td>..</td><td>..</td></tr>
</tbody>
</table>
Erklärung:
Das Element tbody dient der Repräsentation des Tabelleninhalts und kommt innerhalb des table
vor. Der Tabelleninhalt besteht aus ein oder mehreren Tabellenzeilen tr, die wiederum aus einer
Reihe von Tabellenspalten td bestehen. (Siehe auch DTD-Element tbody)
3.36 Tabellenzeile tr
Elementname: tr
Atribute:
keine
Beispiel:
<table>
<tbody>
<tr><td>..</td><td>..</td></tr>
</tbody>
</table>
Erklärung:
Das Element tr dient der Repräsentation einer Tabellenzeile und kommt innerhalb des thead,
tbody oder tfoot vor. Die Tabellenzeile besteht aus ein oder mehreren Tabellenheadern th oder
Tabellenzellen td. (Siehe auch DTD-Element tr)
3.37 Tabellenheader th
Elementname: th
Atribute:
keine
Beispiel:
<table>
<tbody>
<tr>
<th>Heimm</th>
<th>Guest</th>
</tr>
</tbody>
</table>
Erklärung:
Das Element th dient der Repräsentation von Tabellenheadern bzw. Spaltenüberschriften innerhalb
des Tabellenkopfes. Der Inhalt besteht aus unstrukturiertem Text. (Siehe auch DTD-Element th)
3.38 Tabellenzelle td
Elementname: td
Atribute:
keine
Beispiel:
<table>
<tbody>
<tr>
<td>Bayern München</td>
<td>VfB Stuttgart</td>
</tr>
</tbody>
</table>
Erklärung:
Das Element td dient der Repräsentation von Tabellenzellen innerhalb des Tabelleninhaltes oder
Tabellenendes. Der Inhalt besteht entweder aus unstrukturiertem Text oder aus einer beliebigen
Kombination von Paragraphen und Listen, die wiederum zusätzlich zum einfachen Text, auch
Hyperlinks, Zeilenumbrüche und Betonungen enthalten können. (Siehe auch DTD-Element td)
3.39 Multimedia-Objekte media
Elementname: media
Attribute:
media-type: die Art des Multimedia-Objektes
Beispiel:
<body.content>
<media type=“image“>...</media>
</body.content>
Erklärung:
Das Element media kann direkt im body.content und vorkommen. Im Multimedia-Element können
Bilder, Ton, Videos usw. verlinkt werden. Die Art des Multimedia-Objektes hängt vom Attribut mediatype ab. (Siehe auch DTD-Element media)
3.40 Multimedia-Metadaten media-metadata
Elementname: media-metadata
Attribute:
name: Der Name des betroffenen Metadatums.
value: Der Wert des durch das Attribut name identifizierten Metadatums.
Beispiel:
Derzeit werden folgende Metadaten für Medien unterstützt:
Medientyp
Name
Value
Beschreibung
Bild
image-fovea-region
$X1$,$Y1$,$X2$,$Y2$
Dieses
Metadatum
legt
den
Bildschwerpunkt eines Bildes fest. Die
Werte beschreiben die Entfernung von
der linken oberen Ecke des Bildes zur
linken oberen ($X1$, $Y1$) und zur
rechten unteren Ecke ($X2$,$Y2$) des
Bildschwerpunktes.
3.41 Multimedia-Referenz media-reference
Elementname: media-reference
Attribute:
mime-type: MIME-Type des referenzierten Objektes
alternate-text: Alternativtext zur Anzeige anstelle des Medienobjektes
source: Die (File-)Referenz auf die Binärdaten
height: Bildhöhe bei Bildern
width: Bildbreite bei Bildern
name: Identifiziert bei Bildern die Bildvariante im Format $Bildformat$_$X$_$Y$
time: Bei Audioinhalten die Länge des Audios
time-unit-of-measures: Bei Audioinhalten die Zeiteinheit zu dem im Attribut time
angegebenen Wert. Standardmäßig wird hier der Wert seconds angegeben.
copyright: Bei Audioinhalten die Copyright-Information.
Für das Attribut name werden derzeit die folgenden Bildvarianten unterschieden:
Bildvariante
Beschreibung
thumbnail_4_3
Bildformat Thumbnail im Seitenverhältnis 4:3
thumbnail_3_4
Bildformat Thumbnail im Seitenverhältnis 3:4
small_4_3
Bildformat Small im Seitenverhältnis 4:3
small_3_4
small_1_1
small_16_9
small_3_2
medium_4_3
Bildformat Medium im Seitenverhältnis 4:3
medium_3_4
Bildformat Medium im Seitenverhältnis 3:4
large_4:3
Bildformat Large im Seitenverhältnis 4:3
large_3_4
Bildformat Large im Seitenverhältnis 3:4
Beispiel:
<media type=“image“>
<media-reference mime-type=“image/jpeg“
alternate-text=“Boris Becker“
source=“../publishedPictures/image.jpg“
height=“400“ width=“320“ name=”medium_4_3”/>
</media>
Das Element media-reference enthält eine Referenz auf die Binärdaten des Multimedia-Objektes.
Im Element ist stets der passende MIME-Type im Attribut mime-type enthalten. Der Alternativ-Text
(alternate-text) und die Quellreferenz (source) sind optional.
Bei Bildern werden zusätzlich die Bildhöhe (height) und die Bildbreite (weight) repräsentiert.
Außerdem erscheint dieses Element bei Bildern mehrfache, d.h. für jede Bildvariante (siehe auch den
Abschnitt 2.7.4).
Das Element kommt direkt im Element media vor. (Siehe auch DTD-Element media-reference)
3.42 Beschreibungstext Multimedia-Objekte media-caption
Elementname: media-caption
Beispiel:
<media type=“image“>
<media-caption><p>Boris Becker wÃ¤hrend des Gerichtsauftritts in
Miami</p></media-caption>
</media>
Erklärung:
Das Element media-caption kann direkt im Element media nach dem Element mediareference vorkommen. In ihm wird Beschreibungstext zum Multimedia-Objekt repräsentiert. (Siehe
auch DTD-Element media-caption)
3.43 Unsortierte Listen ul
Elementname: ul
Beispiel:
<body.content>
<ul>
<li>Erster Listeneintrag</li>
<li>Zweiter Listeneintrag</li>
</ul>
</body.content>
Erklärung:
Das Element ul kann direkt im body.content oder in einer Tabellenzelle td stehen. Eine
unsortierte Liste besteht aus einer Liste von Listeneinträgen li. Diese Listeneinträge können neben
einfachem Text auch Hyperlinks, Betonungen, Absätze, Tabellen und Listen jeglicher Art beinhalten.
(Siehe auch DTD-Element ul)
3.44 Sortierte Listen ol
Elementname: ol
Beispiel:
<body.content>
<ol>
<li>Erster Listeneintrag</li>
<li>Zweiter Listeneintrag</li>
</ol>
</body.content>
Erklärung:
Das Element ol kann direkt im body.content oder in einer Tabellenzelle td stehen. Eine sortierte
Liste besteht aus einer Liste von Listeneinträgen li. Diese Listeneinträge können neben einfachem
Text auch Hyperlinks, Betonungen, Absätze, Tabellen, und Listen jeglicher Art beinhalten. (Siehe
auch DTD-Element ol)
3.45 Der Textblock block
Elementname: block
Attribute:
style: legt den Typ des Blocks fest
code: kennzeichnet bei MMS-Diensten Opener- und Closer-Slides
Beispiel:
<body.content>
...
</block>
</body.content>
Ein Textblock schließt mehrere zusammengehörige Teile einer Meldung zusammen. Das Element
block darf direkt im body.content vorkommen. Innerhalb eines Blocks dürfen Hyperlinks,
Betonungen, Absätze, Tabellen, Multimedia-Objekte und Listen jeglicher Art vorkommen. (Siehe auch
DTD-Element block)
Zur Zeit gibt es außer bei MMS-Diensten optional einen Textblock mit dem style EXTERNALLINKS. In diesem Block sind Referenzen auf externe Web-Sites enthalten. Jede externe Referenz
wird in einem eigenen Paragraphen p repräsentiert, der wiederum Text sowie den Link im Element a
enthalten kann. Zukünftig kann es sein, dass weitere Blocks mit fest definierten Werten im Attribut
style verwendet werden.
In MMS-Diensten werden Blöcke zur Strukturierung von Meldungen in einzelne Slides verwendet.
Dazu wird das Attribut style mit dem Wert slide ausgezeichnet. Außerdem gibt es optional
ausgezeichnete Slides für Opener und Closer. Diese Slides enthalten nur ein Grafik, wobei der
Opener als erster und der Closer als letzter Slide repräsentiert wird. Um diese Slides von anderen
Slides zu unterscheiden, wird bei diesen Slides das Element block mit einem Attribut class
ausgezeichnet, das für den Opener den Wert opener und für den Closer den Wert closer erhält.
3.46 Hyperlinks a
Elementname: a
Attribute:
href: die referenzierte URL
Beispiel:
<p><a href=“www.test.de“>Stiftung Warentest</a></p>
Erklärung:
Ein Hyperlink kann nur dort verwendet werden, wo auch einfacher Text erlaubt ist. Zur Zeit wird nur
das Attribut href verwendet, das eine URL als Wert enthält. Der Text, der von a eingeschlossen ist,
wird als Referenzanker verwendet. Normalerweise werden Hyperlinks nur im Block für externe Links
repräsentiert. In Ausnahmefällen können Hyperlinks aber auch im normalen Text vorkommen. (Siehe
auch DTD-Element a).
3.47 Betonungen em
Elementname: em
Beispiel:
<p><em>Boris Becker<em> macht in seinem Urlaub auf Mallorca einen
entspannten Eindruck.</p>
Erklärung:
Der Text innerhalb dieses Elementes soll in der Darstellung besonders betont werden. Das Element
em wird nur dort verwendet, wo einfacher Text benutzt wird. Es wird bei NITF nicht zwischen “fett”
oder “kursiv” unterschieden. (Siehe auch DTD-Element em)
3.48 Fettung b
In Ergänzung zur offiziellen DTD von NITF 3.0 wird aus historischen Gründen noch das Element b zur
Fettung von Text verwendet. Es kann an den gleichen Stellen wie das Element em eingesetzt werden
und hat die gleiche Semantik wie das Element b in HTML. Um Konformität zur DTD von NITF wieder
herzustellen, plant dpa-infocom aber in Zukunft, das Element b nicht mehr zu verwenden und durch
das in NITF für diese Zwecke vorgesehene Element em zu ersetzen.
3.49 Kurzübersicht der Dokumentstruktur
In diesem Abschnitt wird eine kurze Übersicht der Struktur des “NITF 3.0 XML”-Formats vorgestellt.
•
XML-Kopf
<!DOCTYPE nitf PUBLIC "-//IPTC-NAA//DTD NITF-XML 3.0//EN" "nitf.dtd">
•
<nitf>
•
<head>
•
<title>
•
<meta name="" content="" >
•
<tobject>
•
•
<tobject.subject tobject.subject.refnum=""
tobject.subject.code="" >
<docdata>
•
<evloc iso-cc="" >
•
<doc-id regsrc="" id-string="" >
•
<urgency ed-urg="" >
•
<fixture fix-id >
•
<date.issue norm="" >
•
<doc-scope scope="" >
•
<key-list>
•
•
<keyword key="" >
•
•
<org idsrc="" value=”” >
<body>
•
<body.head>
•
•
•
<hedline>
•
<hl1>
•
<hl2>
<byline>
<body.content>
•
•
<p>
•
<a href="" >
•
<br>
•
<em>
<table id="" >
•
<thead>
•
•
•
<th
align=""
rowspan="" >
valign=""
colspan=""
•
<td
align=""
rowspan="" >
valign=""
colspan=""
<tfoot>
•
•
<tr align="" valign="" >
•
<th
align=""
rowspan="" >
valign=""
colspan=""
•
<td
align=""
rowspan="" >
valign=""
colspan=""
<tbody>
•
•
•
<th
align=""
rowspan="" >
valign=""
colspan=""
•
<td
align=""
rowspan="" >
valign=""
colspan=""
•
<media-metadata name="" value="" >
•
<media-reference name="" data-location="" source=""
mime-type="" alternate-text="" height="" width="" >
<ul>
<li>
<ol>
•
•
•
<media media-type="" >
•
•
<li>
•
<p>
...
4 Beispiele von Meldungen im “NITF 3.0 XML”-Format
4.1
Eine “NITF 3.0 XML”-Textmeldung
Beispiel: Eine Textmeldung mit externen Links in “NITF 3.0 XML”-Format
"nitf.dtd">
<nitf>
<head>
victors</title>
GmbH"/>
<tobject>
</tobject>
<docdata>
<date.issue norm="20010513T193050+0200"/>
<key-list>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline>
<hl1>Estonians stage jubilant welcome to European song fest
victors</hl1>
</hedline>
<byline>
</byline>
</body.head>
<body.content>
<p>Tallinn (dpa) - Tens of thousands of people gave the Estonian
winners of the Grand Prix Eurovision song festival a triumphal welcome
when they returned home on Sunday evening. Fans awaited singers Tanel
Padar and Dave Benton at the airport and at the market place, the
historical centre of the capital Tallinn. Observers said Estonia did
not seen such fanfare even when its olympical gold medal winners
returned home. The gathered masses stopped traffic, waving banners
with
"Estonia" and the names of the new pop heroes.</p>
<p>Information about <a href="https://www.victimsestonien.de">victims</a> of the catastrophy</p>
<p><a href="http://www.estonien.de">Homepage Estonien</a></p>
</block>
</body.content>
</body>
</nitf>
4.2
Eine “NITF 3.0 XML”-Textmeldung mit Bildern
Beispiel: Eine Textmeldung mit Bildern im “NITF 3.0 XML”-Format
"nitf.dtd">
<head>
victors</title>
GmbH"/>
<tobject>
</tobject>
<docdata>
<date.issue norm="20010513T193050+0200"/>
<key-list>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline>
victors</hl1>
</hedline>
<byline>
</byline>
</body.head>
<body.content>
with "Estonia" and the names of the new pop heroes.</p>
<media-metadata name="media-id" value="dpa-4711:153783039"/>
<media-reference alternate-text=" The Grand Prix Eurovision song
festival " source="../dpa-Badenwuerttemberg-images/jpeg-1x6a460620060116-img_10702788.thumbnail.jpg" mime-type="image/jpeg"
festival " source="../dpa-Badenwuerttemberg-images/jpeg-1x6a460620060116-img_10702788.onlineBild.jpg" mime-type="image/jpeg"
name="medium_4_3" width="400" height="300"/>
festival " source="../dpa-Badenwuerttemberg-images/large/jpeg1x6a4606-20060116-img_10702788.large_4_3.jpg" mime-type="image/jpeg"
name="large_4_3" width="800" height="600"/>
festival " source="../dpa-Badenwuerttemberg-images/small/jpeg1x6a4606-20060116-img_10702788.small_4_3.jpg" mime-type="image/jpeg"
name="small_4_3" width="200" height="150"/>
<media-caption><p> The Estonian winners of the Grand Prix Eurovision
song festival in 2001</p></media-caption>
</media>
</body.content>
<body.end/>
</body>
</nitf>
4.3
Ein „NITF 3.0 XML“ Textmeldung mit Audio
Beispiel: Eine Textmeldung mit Audio im „NITF 3.0 XML“-Format
"nitf.dtd">
<head>
victors</title>
GmbH"/>
<tobject>
</tobject>
<docdata>
<date.issue norm="20010513T193050+0200"/>
<key-list>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline>
victors</hl1>
</hedline>
<byline>
</byline>
</body.head>
<body.content>
with
<media media-type="audio">
<media-reference alternate-text="" copyright="dpa-info.com GmbH" mimetype="audio/x-wav" source="../dpa-AudioWeb-audio-images/buli16audio_10443108.Daten.wav" time="60" time-unit-of-measure="seconds"/>
<media-caption><p> The Estonian winners of the Grand Prix Eurovision
song festival in 2001</p></media-caption>
</media>
</body.content>
<body.end/>
</body>
</nitf>
4.4
Ein „NITF 3.0 XML“ Textmeldung mit Video
Beispiel: Eine Textmeldung mit Video im „NITF 3.0 XML“-Format
"nitf.dtd">
<head>
victors</title>
GmbH"/>
<tobject>
</tobject>
<docdata>
<date.issue norm="20010513T193050+0200"/>
<key-list>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline>
victors</hl1>
</hedline>
<byline>
</byline>
</body.head>
<body.content>
with
<media-reference alternate-text="Überschrift oder Alt-Text"
<media-caption><p>Estonian people celebrating the
triumph.</p></media-caption>
</media>
<media-caption><p> Estonian people celebrating the
triumph.</p></media-caption>
</media>
<media-reference alternate-text="Estonia" source="../dpa-VideoLineimages/Estonia_14636768.thumbnail.jpg" mime-type="image/jpeg"
name="thumbnai
l_4_3" width="79" height="59" />
<media-reference alternate-text="Estonia" source="../dpa-VideoLineimages/Estonia_14636768.onlineBild.jpg" mime-type="image/jpeg"
name="medium_
4_3" width="399" height="299" />
<media-reference alternate-text="Estonia" source="../dpa-VideoLineimages/small/Estonia_14636768.original.small-16-9-200-1867-1247-20671360.jp
g" mime-type="image/jpeg" name="small_16_9" width="200" height="112"
/>
<media-reference alternate-text="Estonia" source="../dpa-VideoLineimages/small/Estonia_14636768.original.small-3-2-200-1867-1237-20671370.jpg
<media-reference alternate-text="Estonia" source="../dpa-VideoLineimages/large/Estonia_14636768.original.large-4-3-800-1567-1004-23671604.jpg
" mime-type="image/jpeg" name="large_4_3" width="800" height="600" />
<media-caption><p>The Estonian crowd.</p></media-caption>
</media>
</block>
</body.content>
<body.end/>
</body>
</nitf>
4.5
Eine „NITF 3.0 XML“ Textmeldung mit Tabelle
Beispiel: Eine Textmeldung mit Tabelle im “NITF 3.0 XML”-Format
"nitf.dtd">
<head>
<title>Devisenkurse Frankfurt</title>
GmbH"/>
<tobject>
tobject.subject.code="WIR"/>
</tobject>
<docdata>
<fixture fix-id="/wirtschaft/devisen"/>
<date.issue norm="20010513T193050+0200"/>
<doc-scope scope="wi"/>
<key-list>
<keyword key="WÃ¤hrung/Kurse"/>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline>
<hl1>Sorten und Devisenkurse vom 07. November 2001</hl1>
</hedline>
</body.head>
<body.content>
<p>Hamburg (dpa/tk) -</p>
<table id=“DEVISEN“>
<thead>
<tr>
<th>Land</th>
<th>Währung</th>
<th>Aktuell</th>
<th>Vortag</th>
</tr>
</thead>
<tbody>
<tr>
<td>USA</td>
<td>1 USD</td>
<td>2,114</td>
<td>2,261</td>
</tr>
<tr>
<td align=“left“>GroÃŸbritanien</td>
<td align=“center“>1 GBP</td>
<td align=“right“>3,066</td>
<td align=“right“>3,298</td>
</tr>
</tbody>
</table>
</body.content>
</body>
</nitf>
4.6
Eine „NITF 3.0 XML“-Bildmeldung
In ausgewählten Rubriken ist es möglich, dass Bilder ohne den Kontext einer Textmeldung bereit
gestellt werden. In solchen Rubriken werden in einem NITF-Dokument ausschließlich das Bild
betreffende Informationen repräsentiert.
Beispiel: Eine Bildmeldung im „NITF 3.0 XML“-Format
"nitf.dtd" -->
<nitf>
<head>
<title>Telekom-Logo</title>
<meta name="variant" content="8904226@1117016548375"/>
<docdata>
<fixture fix-id="/juniorline/bildergalerie/"/>
<date.issue norm="20070320T145538+0100"/>
<key-list>
<keyword key="Telekommunikation/"/>
</key-list>
</docdata>
</head>
<body>
<body.content>
<media-reference alternate-text="Telekom-Logo" source="../dpaJuniorLine-images/telekom4_10983232.thumbnail.jpg" mimetype="image/jpeg" width="80" height="60" />
<media-reference alternate-text="Telekom-Logo" source="../dpaJuniorLine-images/telekom4_10983232.onlineBild.jpg" mimetype="image/jpeg" width="400" height="300"/>
<media-caption><p>Die Telekom und ver.di haben ihre GesprÃ¤che Ã¼ber
den geplanten massiven Stellenabbau wieder aufgenommen. </p></mediacaption></media>
</body.content>
</body>
</nitf>
4.7
Eine „NITF 3.0 XML“-Audiomeldung
In ausgewählten Rubriken ist es möglich, dass Audio-Inhalte ohne den Kontext einer Textmeldung
bereit gestellt werden. In solchen Rubriken werden in einem NITF-Dokument ausschließlich das Audio
Beispiel: Eine Audiomeldung im „NITF 3.0 XML“-Format
"nitf.dtd" -->
<nitf>
<head>
<title>Spielbericht</title>
<meta name="variant" content="10377868@1133365856093"/>
<docdata>
<fixture fix-id="/audioweb/audio/sport/fussball/topnews/"/>
<date.issue norm="20060116T170025+0100"/>
<doc-scope scope="sp"/>
<key-list>
<keyword key="Fussball/"/>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline><hl1>Spielbericht</hl1></hedline>
</body.head>
<body.content>
<media media-type="audio" class="O-Ton">
<media-reference alternate-text="" copyright="dpa-info.com GmbH" mimetype="audio/x-wav" source="../dpa-AudioWeb-audio-images/buli16audio_10443108.Daten.wav" time="60" time-unit-of-measure="seconds"/>
<media-caption><p>Fussball</p></media-caption>
</media>
</body.content>
<body.end/>
</body>
</nitf>
4.8
Eine „NITF 3.0 XML“-Videomeldung
In ausgewählten Rubriken ist es möglich, dass Video-Inhalte ohne den Kontext einer Textmeldung
bereit gestellt werden. In solchen Rubriken werden in einem NITF-Dokument ausschließlich das Video
Beispiel: Eine Videomeldung im „NITF 3.0 XML“-Format
"nitf.dtd" -->
<nitf>
<head>
<title>Hier erscheint die Überschrift des Videodokumentes</title>
<docdata>
<fixture fix-id="/videoline/service/"/>
<date.issue norm="20070531T090321+0200"/>
<key-list>
<keyword key="Stichwort1/Stichwort2/"/>
</key-list>
</docdata>
</head>
<body>
<body.content>
<media-caption><p>Hier kommt die Kurzbeschreibung des Videos
</media>
<media-caption><p>Hier kommt die Kurzbeschreibung des Videos
</media>
source="../dpa-VideoLine-images/Eigenheim_14636768.thumbnail.jpg"
mime-type="image/jpeg" name="thumbnail_4_3" width="79" height="59" />
source="../dpa-VideoLine-images/Eigenheim_14636768.onlineBild.jpg"
mime-type="image/jpeg" name="medium_4_3" width="399" height="299" />
height="112" />
height="133" />
height="200" />
height="150" />
height="200" />
source="../dpa-VideoLineimages/large/Eigenheim_14636768.original.large-4-3-800-1567-1004-23671604.jpg" mime-type="image/jpeg" name="large_4_3" width="800"
height="600" />
<media-caption><p>Hier kommt die Bildunterschrift vom Bild
</media>
</block>
</body.content>
</body>
</nitf>
4.9
Eine “NITF 3.0 XML”-Mobilmeldung
Beispiel: Eine Mobilmeldung im “NITF 3.0 XML”-Format
"nitf.dtd">
<nitf>
<head>
<title>dpa-kurz 526</title>
GmbH"/>
<tobject>
tobject.subject.code="POL"/>
</tobject><docdata>
<fixture fix-id="/mobil/news/politik"/>
<date.issue norm="20010531T060705+0200"/>
<doc-scope scope="pl"/>
<key-list>
<keyword key="Deutschland/Atom/Parteien/GrÃ¼ne/"/>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline>
<hl1>dpa-kurz 526</hl1>
</hedline>
<byline>
</byline>
</body.head>
<body.content>
<p>dpa: GrÃ¼nen-Spitze trifft Kernkraftgegner - Meeting in LÃ¼chow
Schlichtungsversuch - Castor-Transporte entzweien die alten
Bundesgenossen</p>
</body.content>
<body.end/>
</body>
</nitf>
4.10 Ein “NITF 3.0 XML”-Reihenfolgedokument
Beispiel: Ein Reihenfolgedokument im “NITF 3.0 XML”-Format
"nitf.dtd" -->
<nitf>
<head>
<docdata>
<fixture fix-id="$dpa-Rubric$"/>
<date.issue norm="20040827T160330+0200"/>
</docdata>
</head>
<body>
<body.content>
</media>
</media>
<media-reference source="$referenzn$" mime-type="text/xml" />
</media>
</body.content>
<body.end/>
</body>
</nitf>
4.11 Ein “NITF 3.0 XML”-Berichtigungsdokument
Beispiel: Ein Berichtigungsdokument im “NITF 3.0 XML”-Format
"nitf.dtd" -->
<nitf>
<head>
<docdata management-doc-idref="6790038:1091973643000"
management-idref-status="canceled"/>
</head>
</nitf>
5 MMS-Dienste
MMS-Dienste unterscheiden sich von anderen Diensten, insbesondere denen für das Web:
•
MMS-Dokumente sind beschränkt in Ihrer Größe.
•
MMS-Dokumente werden in so genannte Slides unterteilt. Der Enduser sieht dann jeweils nur den
Inhalt eines Slides, kann aber innerhalb eines Slides wie auch zwischen den Slides navigieren.
•
Tabellen können in MMS-Dokumenten nicht strukturiert repräsentiert werden.
•
MMS-Dienste werden i.d.R. kundenspezifisch produziert und zusammengestellt.
Um diese Unterschiede zu berücksichtigen, unterscheidet sich das NITF 3.0 XML Format für MMSDienste von dem für andere Zielmedien.
5.1
Dienststruktur und Arten von Kanälen
Jeder Dienst wird in Kanäle unterteilt, die analog zu Web-Diensten durch dpa-Rubriken repräsentiert
werden. Zu jedem Kanal werden Inhalt, Art, Umfang und Sendetermine des Angebotes individuell
festgelegt. Dabei werden drei Arten von Angeboten unterschieden:
•
Alert-Kanäle: bei besonders wichtigen Ereignissen (z.B. Brennpunkte Politik, Brennpunkte
Wirtschaft) wird eine MMS bestehend aus Meldungstext, Bildern und optional Audio produziert
und versendet. Mit dem jeweiligen Kunden ist die durchschnittliche Anzahl zu versendender
MMS pro Woche abgesprochen.
•
Live-Kanäle: zu ausgewählten Ereignissen (z.B. Fußball, Formel1) werden eine mit dem
jeweiligen Kunden vereinbarte Anzahl von MMS mit Meldungstext und Bildern zu definierten
Live-Events versendet.
•
Bulletin-Kanäle: zu fest definierten Zeitpunkten (Wochentag und Uhrzeit) wird eine MMS
bestehend aus einer fest definierten Anzahl von Textmeldungen, Bildern und Audio-Inhalten
produziert (z.B. 6 Textmeldungen mit insgesamt 3 Bildern für die Topnews des Tages oder 6
Bilder für die Bilder des Tages)
5.2
Struktur der Dokumente
Eine MMS ist in folgende Ebenen untergliedert:
•
Jede MMS besteht aus einer Reihe von Slides. Der mobile Anwender sieht jeweils einen Slide
auf seinem Gerät. Er kann innerhalb des Slides scrollen oder zwischen den einzelnen Slides
vor- und zurückwechseln. Manche Endgeräte bieten zusätzlich einen Abspielmodus, in dem in
einer Art Diashow automatisch durch die Slides navigiert wird.
•
Innerhalb eines Slides können Text, Bild, Audio und Video kombiniert werden. Diese Formate
können aber innerhalb eines Slides nicht beliebig kombiniert werden, sondern werden jeweils
in eigenen Blöcken zusammen gefasst, die im mobilen Endgerät untereinander dargestellt
werden.
Zur Repräsentierung von Slides wird der body.content in block-Elemente mit dem Attribut
style="slide" unterteilt. Jeder Block entspricht dabei einem Slide. Innerhalb eines Blocks wird
maximal ein Text, ausgezeichnet durch das Element p und ein Bild, ausgezeichnet durch das Element
media repräsentiert. Außerdem gibt es optional ausgezeichnete Slides für Opener und Closer.
Opener-Slides enthalten nur eine Grafik und optional Text, Closer-Slides ausschließlich Text. Der
Opener-Slide wird als erster, der Closer-Slide als letzter Block repräsentiert. Um diese Slides von
anderen Slides zu unterscheiden, wird das Element block mit einem Attribut class ausgezeichnet,
das für den Opener den Wert opener und für den Closer den Wert closer erhält.
5.3
Tabellen
Da es in MMS keine Möglichkeit zur Repräsentation von Tabellen gibt, werden Tabellen so
umgewandelt, dass jede Tabellenzeile in einer Zeile dargestellt wird und je zwei Zellen durch das
Element br getrennt werden. Tabellenzellen werden durch ein Leerzeichen getrennt. Alle anderen
Elemente werden entfernt.
"nitf.dtd" -->
<nitf>
<head>
<title> </title>
<tobject>
tobject.subject.code="SPO" />
</tobject>
<docdata>
<evloc iso-cc="DEU"/>
<doc-id regsrc="dpa" id-string="hfk"/>
<fixture fix-id="/mobilemms/sport/fussball/topnews/"/>
<date.issue norm="20021029T101957+0100"/>
<doc-scope scope="sp"/>
<key-list>
<keyword key="Fussball/Bundesliga/"/>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline><hl1>Fussball-News</hl1></hedline>
<byline></byline>
</body.head>
<body.content>
<block style=“slide“>
<media-reference alternate-text="" source="../dpa-MobileMMSimages/jpeg1a0c2427-20021028_2830952.thumbnail.jpg" mimetype="image/jpeg" width="80" height="59" />
<media-reference alternate-text="" source="../dpa-MobileMMSimages/jpeg-1a0c2427-20021028_2830952.onlineBild.jpg" mimetype="image/jpeg" width="400" height="297"/>
<media-caption><p>Scholl bejubelt seinen Siegtreffer gegen
Hannover</p></media-caption>
</media>
<p>Jerusalem (dpa) - Vertreter der israelischen Arbeitspartei und
der Likud-Partei von MinisterprÃ¤sident Ariel Scharon haben eine
Â«grundsÃ¤tzliche EinigungÂ» in der Frage der Finanzierung jÃ¼discher
Siedlungen in den palÃ¤stinensischen Gebieten erzielt. Damit haben sie
mÃ¶glicherweise den Zusammenbruch der seit MÃ¤rz 2001 amtierenden
Koalitionsregierung in letzter Minute verhindert.<br/>
Ergebnisse<br/>
Bayern - Leverkusen 2:1<br/>
Bremen – Dortmund 1:4<br/>
Tabelle<br/>
1. Bayern 14 P.<br/>
2. Dortmund 13<br/>
</p>
</block>
</body.content>
<body.end/>
</body>
</nitf>
5.4
Beispiele
In diesem Abschnitt wird die Repräsentation von MMS-Dokumenten anhand von Beispielen
vorgestellt.
5.4.1 Alert- / Live-MMS
Bei dieser Art von MMS wird der body.content in mehrere Blöcke aufgeteilt, die jeweils aus einem
Text und Bild bestehen. Im ersten Block befindet sich der Meldungstext mit dem ersten Bild. In den
weiteren Blöcken wird jeweils ein Bild mit Referenzen auf die beiden Bildobjekte repräsentiert sowie
ein Textbaustein mit dem Bildtext im ersten Paragraphen.
Beispiel:
"nitf.dtd" -->
<nitf>
<head>
<title>Brennpunkte 10:15 Uhr</title>
<meta name="generator" content="CoreMedia 3.3"/>
<tobject>
tobject.subject.code="KKK" />
</tobject>
<docdata>
<evloc iso-cc="RUS"/>
<doc-id regsrc="dpa-infocom" id-string="iptc-hfk-20021104_2589043"/>
<fixture fix-id="/mobilemms/news/brennpunkte/"/>
<date.issue norm="20021029T101957+0100"/>
<doc-scope scope="pl"/>
<key-list>
<keyword key="Terrorismus/Kaukasus/Russland/"/>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline><hl1>Brennpunkte 10:15 Uhr</hl1></hedline>
<byline></byline>
</body.head>
<body.content>
<block style="slide">
<media-caption><p>Doch 45 Geisel in Moskau durch SchÃ¼sse ums Leben
gekommen.</p></media-caption>
</media>
<p>Moskau (dpa) - Von den 117 getÃ¶teten Geiseln in Moskau sind nach
Angaben der russischen Justiz doch 45 durch Schussverletzungen
umgekommen. Der Moskauer Staatsanwalt Michail Awdjukow sagte heute, es
mÃ¼sse noch geklÃ¤rt werden, ob die Kugeln jeweils aus den Waffen der
Terroristen oder der Eingreiftruppen stammten. Bislang hatten Ã^Ärzte
erklÃ¤rt, bis auf zwei seien alle Geiseln an dem bei der ErstÃ¼rmung
des Theater-GebÃ¤udes eingesetzten Gas gestorben. Die beiden deutschen
Opfer der Geiselnahme sind inzwischen aus der Klinik in MÃ¼nchen
entlassen worden.</p>
</block>
<media-caption><p>Eine tote Terroristin im Zuschauerraum des MusicalTheaters.</p></media-caption>
</media>
<p>Eine tote Terroristin im Zuschauerraum des Musical-Theaters.</p>
</block>
</body.content>
<body.end/>
</body>
</nitf>
5.4.2 Bulletin-MMS
Bulletin-MMS bestehen aus mehreren Meldungen, die jeweils eigene Überschriften, Texte und Bilder
haben. Dabei wird jede Meldung mindestens einem eigenen Slide zugeordnet. Dabei werden im
ersten Slide der Meldungstext und optional das erste Bild repräsentiert. Ist einer Meldung mehr als ein
Bild zugeordnet, wird jedes weitere Bild in einem eigenen Slide zusammen mit der Bildunterschrift
repräsentiert. Jedem block-Element ist ein Attribut style mit dem Wert slide zugeordnet.
Beispiel:
"nitf.dtd" -->
<nitf>
<head>
<title>Topnews</title>
<docdata>
<doc-id regsrc="dpa-infocom" id-string="topnews_2034589"/>
<fixture fix-id="/mobilemms/news/topnews/ueberblick/"/>
<date.issue norm="20021029T101957+0100"/>
</docdata>
</head>
<body>
<body.head>
<hedline><hl1>Topnews</hl1></hedline>
<byline></byline>
</body.head>
<body.content>
<media-caption><p>Doch 45 Geisel in Moskau durch SchÃ¼sse ums Leben
gekommen.</p></media-caption>
</media>
<p>Moskau (dpa) - Von den 117 getÃ¶teten Geiseln in Moskau sind nach
Angaben der russischen Justiz doch 45 durch Schussverletzungen
umgekommen. Der Moskauer Staatsanwalt Michail Awdjukow sagte heute, es
mÃ¼sse noch geklÃ¤rt werden, ob die Kugeln jeweils aus den Waffen der
Terroristen oder der Eingreiftruppen stammten. Bislang hatten Ã^Ärzte
erklÃ¤rt, bis auf zwei seien alle Geiseln an dem bei der ErstÃ¼rmung
des Theater-GebÃ¤udes eingesetzten Gas gestorben. Die beiden deutschen
Opfer der Geiselnahme sind inzwischen aus der Klinik in MÃ¼nchen
entlassen worden.</p>
</block>
<p>Jerusalem (dpa) - Vertreter der israelischen Arbeitspartei und
der Likud-Partei von MinisterprÃ¤sident Ariel Scharon haben eine
Â«grundsÃ¤tzliche EinigungÂ» in der Frage der Finanzierung jÃ¼discher
Siedlungen in den palÃ¤stinensischen Gebieten erzielt. Damit haben sie
mÃ¶glicherweise den Zusammenbruch der seit MÃ¤rz 2001 amtierenden
Koalitionsregierung in letzter Minute verhindert.</p>
</block>
</body.content>
<body.end/>
</body>
</nitf>
5.4.3 Beispielmeldung mit Opener und Closer
Opener und Closer sind wie oben beschrieben ausgezeichnete Blöcke mit einer speziellen
Bedeutung. Opener und Closer gibt es nicht zu jedem Dokument und es ist auch möglich,
ausschließlich einen Opener oder einen Closer in einem MMS-Dokument zu repräsentieren.
Beispiel:
"nitf.dtd" -->
<nitf>
<head>
<title>Brennpunkte</title>
<meta name="copyright" content="dpa - Deutsche Presse-Agentur GmbH"/>
<tobject>
tobject.subject.code="SOZ" />
</tobject>
<docdata>
<doc-id regsrc="dpa-infocom" id-string="iptc-bdt-20030304-441dpa_2436680"/>
<fixture fix-id="/mobilemms/wirtschaft/brennpunkte/"/>
<date.issue norm="20030310T124907+0100"/>
<doc-scope scope="wi"/>
<key-list>
<keyword key="Tarife/Bahn/"/>
</key-list>
</docdata>
</head>
<body>
<body.head>
<hedline><hl1>Brennpunkte</hl1></hedline>
<byline></byline>
</body.head>
<body.content>
<block style="slide" class="opener">
<media-reference alternate-text="" source="../dpa-MobileMMSimages/Opener_2436770.thumbnail.jpg" mime-type="image/jpeg" width="80"
height="60" />
<media-reference alternate-text="" source="../dpa-MobileMMSimages/Opener_2436770.onlineBild.jpg" mime-type="image/jpeg"
</media>
</block>
<media-reference alternate-text="" source="../dpa-MobileMMSimages/jpeg-1cek4048-20030304_2436676.thumbnail.jpg" mimetype="image/jpeg" width="80" height="52" />
<media-reference alternate-text="" source="../dpa-MobileMMSimages/jpeg-1cek4048-20030304_2436676.onlineBild.jpg" mimetype="image/jpeg" width="400" height="262"/>
<media-caption><p>Warnstreiks in NÃ¼rnberg, Regensburg und MÃ¼nchen
behinderten am Morgen den Berufsverkehr.</p></media-caption>
</media>
<p>Berlin (dpa) - Im Tarifkonflikt der Deutschen Bahn wollen die
LokfÃ¼hrer am Donnerstagmorgen den Berufsverkehr flÃ¤chendeckend fÃ¼r
knapp eine Stunde lahm legen. Wie es heute bei der
LokfÃ¼hrergewerkschaft GdL weiter hieÃŸ, soll am Donnerstagmorgen in
ganz Deutschland fÃ¼r etwa 45 Minuten kein Zug mehr fahren. Damit
greift die LokfÃ¼hrergewerkschaft erstmals in den laufenden
Tarifkonflikt ein. Heute gab es bereits Warnstreiks in MÃ¼nchen,
NÃ¼rnberg und Regensburg. Auch die S-Bahn-Verbindung zum MÃ¼nchner
Flughafen wurde unterbrochen. </p>
</block>
<media-reference alternate-text="" source="../dpa-MobileMMSimages/jpeg-1cel2936-20030304_2436678.thumbnail.jpg" mimetype="image/jpeg" width="79" height="52" />
<media-reference alternate-text="" source="../dpa-MobileMMSimages/jpeg-1cel2936-20030304_2436678.onlineBild.jpg" mimetype="image/jpeg" width="400" height="261"/>
<media-caption><p>Der Leipziger Hauptbahnhof in der sÃ¤chsischen
Messemetropole.</p></media-caption>
</media>
<p>Der Leipziger Hauptbahnhof in der sÃ¤chsischen Messemetropole.</p>
</block>
<block style="slide" class="closer">
<media-reference alternate-text="" source="../dpa-MobileMMSimages/closer_2436810.thumbnail.jpg" mime-type="image/jpeg" width="80"
height="60" />
<media-reference alternate-text="" source="../dpa-MobileMMSimages/closer_2436810.onlineBild.jpg" mime-type="image/jpeg"
</media>
</block>
</body.content>
<body.end/>
</body>
</nitf>
6 Validierung von “NITF 3.0 XML”-Dokumenten
Aus historischen Gründen können Dokumente im Format NITF 3.0 XML von dpa-infocom in
Erweiterung zur offiziellen DTD zusätzlich das Element b für Fettmarkierung eines Textes enthalten.
Dieses Element kann an gleicher Position innerhalb des NITF-Dokumentes verwendet werden wie das
Element em (Siehe auch den Abschnitt Fettung b). Gegen diese erweiterte DTD werden alle von dpainfocom produzierten Dokumente validiert. Es werden nur gültige Dokumente publiziert. Es werden
vorläufig nur eine Teilmenge der Elemente und Attribute von NITF verwendet.
7 Unterschiede zu vorhergehenden Versionen
In diesem Kapitel werden Unterschiede zu vorhergehenden NITF-Versionen beschrieben.
7.1
Unterschiede zu NITF 2.5 XML
„NITF 3.0 XML“ ist die Nachfolgeversion von „NITF 2.5 XML“, die übergangsweise von der dpainfocom unterstützt wurde.
7.1.1 Encoding
In „NITF 3.0 XML“ wird UTF-8 statt ISO-8859-1 als Encoding verwendet.
7.1.2 Repräsentation von Bildern
Ab der Version „NITF 3.0 XML“ werden textuelle Informationen zu Bildern nicht mehr in einem eigenen
NITF-Dokument repräsentiert. Stattdessen erfolgt eine Repräsentation innerhalb des Textdokumentes,
das das entsprechende Bild referenziert. Die Binärdaten werden jedoch weiterhin in separaten
Dokumenten repräsentiert. Dadurch entfällt in NITF-Textdokumenten die Verwendung von Tabellen
mit der id REFERENCED-IMAGES. Stattdessen werden textuelle Informationen zu referenzierten
Bildern innerhalb des Elementes media repräsentiert. Darüberhinaus gibt es folgende Änderungen
bei der Repräsentation der textuellen Informationen zu Bildern:
•
Alle Informationen zu einem referenzierten Bild werden statt in zwei Elementen media (eins für
das Thumbnail und eins für das große Bild) in einem Element media referenziert.
•
Die Binärdaten der beiden Bildversionen eines Bildes werden jeweils in einem eigenen Element
media-reference innerhalb des Elementes media repräsentiert.
•
Im Element media-reference entfallen die Attribute name und data-location.
•
Der Bildtext wird im Element media-caption repräsentiert.
Bei der Implementierung des durch die dpa vorgegebenen Nachrichtenmanagements sind folgende
Aspekte zu berücksichtigen:
•
Binärdaten können von mehr als einem NITF-Dokument referenziert werden. Wird ein
referenzierendes NITF-Dokument gelöscht, dürfen die referenzierten Binärdaten somit nur
gelöscht werden, wenn kein weiteres NITF-Dokument die Binärdaten referenziert.
•
In unterschiedlichen Versionen eines NITF-Dokumentes können unterschiedliche Binärdaten
referenziert werden. So kann ein NITF-Dokument in Version 1 ohne referenzierte Binärdaten, in
Version 2 mit Referenzen auf die Binärdaten eines oder mehrerer Bilder und in Version 3 mit
Referenzen die Binärdaten von z.T. anderen Bildern geliefert werden.
7.1.3 Externe Links
Ab NITF 3.0 XML werden Links auf externe Web-Sites getrennt vom eigentlichen Meldungstext
repräsentiert. Dazu wird mittels des Elementes block ein eigener Block mit dem Attribut
style=“EXTERNAL-LINKS“ definiert, in dem die Links repräsentiert werden.
Anhang A. Verwendete Stichwörter <key-list>
Hinweis: Die Liste verwendeter Stichwörter ist häufigen Änderungen unterworfen, so dass eine
Auflistung innerhalb dieses Dokumentes nicht sinnvoll ist. Auch sei noch einmal darauf hingewiesen,
dass die Auswertung der Stichworte mit einem gewissen Risiko verbunden ist. Interessiert sich ein
Kunde trotzdem für eine aktuelle Liste, möge er sich bitte an die Technik der dpa-infocom wenden.
Anhang B. Subject-Codes
Hinweis: Zur Zeit werden nur die 17 Subject Codes 01000000 – 17000000 der ersten Ebene
verwendet, bei denen lediglich die ersten beiden Ziffern gesetzt sind. Eine weitergehende Nutzung ist
in zukünftigen Ausbaustufen aber geplant. Dabei basiert die Liste auf dem Standard der IPTC,
erweitert um dpa-spezifische Subject-Codes.
Tabelle B.1. Subject Codes
Subject-Name
Arts, Culture & Entertainment
Crime, Law & Justice
Referenz-Nr.
Subject Name
01000000
01001000
Archaeology
01002000
Architecture
01003000
Bullfighting
01004000
Festive Events (including Carnivals)
01005000
Cinema
01006000
Dance
01007000
Fashion
01008000
Language
01009000
Libraries & Museums
01010000
Literature
01011000
Music
01012000
Painting
01013000
Photography
01014000
Radio
01015000
Sculpture
01016000
Television
01017000
Theatre
01018000
Monuments & Heritage Sites
01019000
Customs & Traditions
01020000
Arts (general)
01021000
Entertainment (general
01022000
Culture (general)
01023000
Nightclubs
02000000
02001000
Crime
02002000
Judiciary (system of justice)
Disasters & Accidents
02003000
Police
02004000
Punishment
02005000
Prison
02006000
Laws
02007000
Justice & Rights
02008000
Trials
03000000
03001000
Drought
03002000
Earthquake
03003000
Famine
03004000
Fire
03005000
Flood
03006000
Industrial accident
03007000
Meteorological disaster
03008000
Nuclear accident
03009000
Pollution
03010000
Transport accident
03011000
Volcanic eruption
03012000
Relief & Aid Organisations
03013000
Accidents (general)
03014000
Emergency Incidents
03015000
Disasters (general)
03016000
Emergency Planning
Economy, Business & Finance 04000000
04001000
Agriculture
04002000
Chemicals
04003000
Computing & Information Technology
04004000
Construction & Property
04005000
Energy & Resources
04006000
Financial & Business Services
04007000
Consumer Goods
04008000
Macro Economics
04009000
Markets & Exchanges
04010000
Media
04011000
Metal Goods & Engineering
04012000
Metals & Minerals
Education
Environmental Issues
Health
04013000
Process Industries
04014000
Tourism & Leisure
04015000
Transport
04016000
Company Information
05000000
05001000
Adult Education
05002000
Further Education
05003000
Parent Organisations
05004000
Preschooling
05005000
Schools
05006000
Teachers Unions
05007000
University
05008000
Upbringing
06000000
06001000
Alternative Energy
06002000
Conservation
06003000
Energy Savings
06004000
Environmental Politics
06005000
Environmental pollution
06006000
Natural resources
06007000
Nature
06008000
Population
06009000
Waste
06010000
Water Supplies
07000000
07001000
Diseases
07002000
Epidemic & Plague
07003000
Health treatment
07004000
Health organisations
07005000
Medical research
07006000
Medical staff
07007000
Medicines
07008000
Preventative medicine
07009000
Injuries
07010000
Hospitals & Clinics
Human Interest
Labour
Lifestyle & Leisure
08000000
08001000
Animals
08002000
Curiosities
08003000
People
08004000
Mysteries
08005000
Society
09000000
09001000
Apprentices
09002000
Collective contracts
09003000
Employment
09004000
Labour dispute
09005000
Labour legislation
09006000
Retirement
09007000
Retraining
09008000
Strike
09009000
Unemployment
09010000
Unions
09011000
Wages & Pensions
09012000
Work Relations
09013000
Health & Safety at Work
09014000
Advanced Training
09015000
Employers
10000000
10001000
Games
10002000
Gaming & Lotteries
10003000
Gastronomy
10004000
Hobbies
10005000
Holidays or vacations
10006000
Tourism
10007000
Travel & Commuting
10008000
Clubs & Associations
10009000
Lifestyle (House & Home)
10010000
Leisure (general)
10011000
Public Holidays
Politics
Religion & Belief
Science & Technology
11000000
11001000
Defence
11002000
Diplomacy
11003000
Elections
11004000
Espionage & Intelligence
11005000
Foreign Aid
11006000
Government
11007000
Human Rights
11008000
Local authorities
11009000
Parliament
11010000
Parties
11011000
Refugees
11012000
Regional authorities
11013000
State Budget
11014000
Treaties & Organisations
11015000
Constitution
11016000
Interior Policies
11017000
Migration
11018000
Citizens Initiative
11019000
Referenda
11020000
Nuclear Policies
12000000
12001000
Cults & sects
12002000
Belief (Faith)
12003000
Free masonry
12004000
Religions
12005000
Churches (organisations)
13000000
13001000
Applied Sciences
13002000
Engineering
13003000
Human Sciences
13004000
Natural Sciences
13005000
Philosophical Sciences
13006000
Research
13007000
Scientific exploration
13008000
Space programmes
Social Issues
Sport
13009000
Science (general)
13010000
Technology (general)
14000000
14001000
Addiction
14002000
Charity
14003000
Demographics
14004000
Disabled
14005000
Euthanasia (also includes Assisted Suicide)
14006000
Family
14007000
Family planning
14008000
Health insurance
14009000
Homelessness
14010000
Minority groups
14011000
Pornography
14012000
Poverty
14013000
Prostitution
14014000
Racism
14015000
Welfare
14016000
Abortion
14017000
Missing persons
14018000
Long Term Care
15000000
15001000
Aero and Aviation Sports
15002000
Alpine Skiing
15003000
American Football
15004000
Archery
15005000
Athletics, Track & Field
15006000
Badminton
15007000
Baseball
15008000
Basketball
15009000
Biathlon
15010000
Billiards, Snooker and Pool
15011000
Bobsleigh
15012000
Bowling
15013000
Bowls & Petanque
15014000
Boxing
15015000
Canoeing & Kayaking
15016000
Climbing
15017000
Cricket
15018000
Curling
15019000
Cycling
15020000
Dancing
15021000
Diving
15022000
Equestrian
15023000
Fencing
15024000
Field Hockey
15025000
Figure Skating
15026000
Freestyle Skiing
15027000
Golf
15028000
Gymnastics
15029000
Handball (Team)
15030000
Horse Racing, Harness Racing
15031000
Ice Hockey
15032000
Jai Alai (Pelota)
15033000
Judo
15034000
Karate
15035000
Lacrosse
15036000
Luge
15037000
Marathon
15038000
Modern Pentathlon
15039000
Motor Racing
15040000
Motor Rallying
15041000
Motorcycling
15042000
Netball
15043000
Nordic Skiing
15044000
Orienteering
15045000
Polo
15046000
Power Boating
15047000
Rowing
15048000
Rugby League
15049000
Rugby Union
15050000
Sailing
15051000
Shooting
15052000
Ski Jumping
Unrest, Conflicts & War
Weather
15053000
Snow Boarding
15054000
Soccer
15055000
Softball
15056000
Speed Skating
15057000
Speedway
15058000
Sports Organisations
15059000
Squash
15060000
Sumo Wrestling
15061000
Surfing
15062000
Swimming
15063000
Table Tennis
15064000
Taekwon-Do
15065000
Tennis
15066000
Triathlon
15067000
Volleyball
15068000
Water Polo
15069000
Water Skiing
15070000
Weightlifting
15071000
Windsurfing
15072000
Wrestling
15073000
Sports Events
16000000
16001000
Acts of terror
16002000
Armed conflict
16003000
Civil unrest
16004000
Coup d'Etat
16005000
Guerrilla activities
16006000
Massacre
16007000
Riots
16008000
Violent demonstrations
16009000
War
16010000
Conflicts (general)
16011000
Crisis
17000000
17001000
Forecasts
17002000
Global change
17003000
Reports
17004000
Statistics
17005000
Warnings
Anhang C. Länderkennung - ISO-3166 und dpa-Erweiterung
In der folgenden Tabelle sind die möglichen Bezeichnungen zu den Länderkürzeln aufgelistet. Es
können mehrere Bezeichnungen für das gleiche Länderkürzel gemeint sein. Wird eine Bezeichnung
mit “(f.)” gekennzeichnet, wird darauf hingewiesen, dass es sich um eine weibliche Form handelt.
Dementsprechend wird mit “(m.)” explizit darauf hingewiesen, dass es sich beim Bezeichner um eine
männliche Form handelt. In einigen Fällen wird mit “(Pl.)” die Plural-Form des Bezeichners
angegeben. Falls die Bezeichner in Deutschland, Österreich oder in der Schweiz anders benutzt
werden, so wird dies durch “(AT)” für Österreich, “(CH)” für die Schweiz und “(DE)” für Deutschland
gekennzeichnet.
Diese Liste ist vom Stand Februar 2001 und erhebt keinen Anspruch auf Vollständigkeit. Für
weiterführende und aktuelle Informationen sollten
•
für Deutschland:
Auswärtiges Amt (Hrsg.): Länderverzeichnis für den amtlichen
Bundesrepublik Deutschland. Berlin 1999 (sowie spätere Ergänzungen);
•
Gebrauch
in
der
für Österreich:
Bundesministerium für auswärtige Angelegenheiten (Hrsg.): Liste der Staatennamen und
deren Ableitungen in den vom Bundesministerium für auswärtige Angelegenheiten
verwendeten Formen. Wien 1999 (sowie spätere Ergänzungen);
•
für die Schweiz:
Eidgenössisches Departement für Auswärtige Angelegenheiten (Hrsg.):
Staatenbezeichnungen. Bern, Stand 1.3.1996. (sowie spätere Ergänzungen);
Liste
der
herangezogen werden.
Tabelle C.1. Länderkürzel
Länderkennung
mögliche Bezeichnung
ABW
Aruba
AFG
Afghanistan
AGO
Angola
AIA
Anguilla
ALB
Albanien
AND
Andorra
ANT
Niederländische Antillen
ARE
Vereinigte Arabische Emirate (Pl.)
ARG
Argentinien
ARM
Armenien
ASM
Amerikanisch-Samoa
ATA
Antarktis
ATF
Französische Süd- und Antarktisgebiete
ATG
Antigua und Barbuda
AUS
Australien
AUT
Österreich
AZE
Aserbaidschan
BDI
Burundi
BEL
Belgien
BEN
Benin
BFA
Burkina Faso
BGD
Bangladesch (AT,DE) Bangladesh (CH)
BGR
Bulgarien
BHR
Bahrain
BHS
Bahamas (Pl.)
BIH
Bosnien und Herzegowina
BLR
Weißrussland (DE) Belarus (AT, CH, DE)
BLZ
Belize
BMU
Bermuda
BOL
Bolivien
BRA
Brasilien
BRB
Barbados
BRN
Brunei Darussalam (AT, DE) Brunei (CH)
BTN
Bhutan
BVT
Bouvetinsel
BWA
Botsuana (AT, DE) Botswana (CH)
CAF
Zentralafrikanische Republik (f.)
CAN
Kanada
CCK
Kokosinseln
CHE
Schweiz (f.)
CHL
Chile
CHL
Osterinsel
CHN
China
CIV
Côte d’Ivoire
CMR
Kamerun
COD
Kongo, Demo- kratische Republik
COG
Kongo (auch m.)
COK
Cookinseln
COL
Kolumbien
COM
Komoren (Pl.)
CPV
Kap Verde (AT, DE) Kapverden (CH) (Pl.)
CRI
Costa Rica
CUB
Kuba
CXR
Weihnachtsinsel
CYM
Kaimaninseln
CYP
Zypern
CZE
Tschechische Republik (f.)
DEU
Deutschland
DJI
Dschibuti (AT, DE) Djibouti (CH)
DMA
Domenica
DNK
Dänemark
DOM
Dominikanische Republik (f.)
DZA
Algerien
ECU
Ecuador
ECU
Galápagosinseln
EGY
Ägypten
ERI
Eritrea
ESP
Kanarische Inseln
ESP
Spanien
EST
Estland
ETH
Äthiopien
FIN
Finnland
FJI
Fidschi
FLK
Falklandinseln (Malwinen)
FRA
Frankreich
FRO
Färöer
FSM
Mikronesien, Föderierte Staaten von (CH, DE) (Pl.) Mikronesien (AT)
GAB
Gabun
GBR
Insel Man
GBR
Kanalinseln
GBR
Vereinigtes Königreich (AT, DE) Grossbritannien (CH) nicht: England
GEO
Georgien
GHA
Ghana
GIB
Gibraltar
GIN
Guinea
GLP
Guadeloupe
GMB
Gambia
GNB
Guinea-Bissau
GNQ
Äquatorialguinea
GRC
Griechenland
GRD
Grenada
GRL
Grönland
GTM
Guatemala
GUF
Französisch-Guayana
GUM
Guam
GUY
Guyana
HMD
Heard und McDonaldinseln
HND
Honduras
HRV
Kroatien
HTI
Haiti
HUN
Ungarn
IDN
Indonesien
IND
Indien
IOT
Britisches Territorium im Indischen Ozean
IRL
Irland
IRN
Iran (CH) (meist m.) Iran, IslamischeRepublik (AT, DE) (f.) nicht: Persien
IRQ
Irak (meist m.)
ISL
Island
ISR
Israel
ITA
Italien
JAM
Jamaika
JOR
Jordanien
JPN
Japan
KAZ
Kasachstan
KEN
Kenia
KGZ
Kirgisistan
KHM
Kambodscha
KIR
Kiribati
KNA
St . Kitts und Nevis
KOR
Korea, Republik
KWT
Kuwait
LAO
Laos , Demokratische Volksrepublik (f.) (AT, DE) Laos (CH)
LBN
Libanon (meist m.)
LBR
Liberia
LBY
Libysch-Arabische Dschamahirija (f.) (AT, DE) Libyen (CH)
LCA
St. Lucia
LIE
Liechtenstein
LKA
Sri Lanka nicht: Ceylon
LSO
Lesotho
LTU
Litauen
LUX
Luxemburg
LVA
Lettland
MAR
Marokko
MCO
Monaco
MDA
Moldau (AT)
MDG
Madagaskar
MDV
Malediven (Pl.)
MEX
Mexiko
MHL
Marshallinseln (AT,DE) Marshall-Inseln (CH) (Pl.)
MKD
Mazedonien (CH) die ehemalige jugoslawische Republik Mazedonien (AT, DE)
MLI
Mali
MLT
Malta
MMR
Myanmar
MNG
Mongolei (f.)
MNP
Nördliche Marianen
MOZ
Mosambik
MRT
Mauretanien
MSR
Montserrat
MTQ
Martinique
MUS
Mauritius
MWI
Malawi
MYS
Malaysia
MYT
Mayotte
NAM
Namibia
NCL
Neukaledonien
NER
Niger
NFK
Norfolkinsel
NGA
Nigeria
NIC
Nicaragua
NIL
Keine explizite Länderangabe
NIU
Niue
NLD
Niederlande (Pl.) nicht: Holland
NOR
Norwegen
NPL
Nepal
NRU
Nauru
NZL
Antipoden
NZL
Aucklandinseln
NZL
Bountyinseln
NZL
Campbellinsel
NZL
Chathaminseln
NZL
Neuseeland
OMN
Oman
PAK
Pakistan
PAN
Panama
PCN
Pitcairninseln
PER
Peru
PHL
Philippinen (Pl.)
PLW
Palau
PNG
Papua-Neuguinea
POL
Polen
PRI
Puerto Rico
PRK
Korea, Demokratische Volksrepublik
PRT
Azoren
PRT
Madeira
PRT
Portugal
PRY
Paraguay
PYF
Französisch-Polynesien
QAT
Katar
REU
Réunion
ROU
Rumänien
RUS
Russische Föderation (AT, DE) (f.) Russland (CH)
RWA
Ruanda (AT, DE) Rwanda (CH)
SAU
Saudi-Arabien
SDN
Sudan (m.)
SEN
Senegal
SRB
Serbien
SGP
Singapur
SGS
Südgeorgien und die Südlichen Sandwichinseln
SHN
Ascension
SHN
St. Helena
SHN
Tristan da Cunha
SJM
Bäreninsel
SJM
Svalbard und Jan Mayen
SLB
Salomonen (AT, DE) Salomon-Inseln (CH) (Pl.)
SLE
Sierra Leone
SLV
El Salvador
SMR
San Marino
SOM
Somalia
SPM
St. Pierre und Miquelon
STP
São Tomé und Príncipe (AT, DE) Sao Tomé und Principe (CH)
SUR
Suriname
SVK
Slowakei (f.)
SVN
Slowenien
SWE
Schweden
SWZ
Swasiland
SYC
Seychellen (Pl.)
SYR
Syrien, Arabische Republik (AT, DE) (f.) Syrien (CH)
TCA
Turks- und Caicosinseln
TCD
Tschad
TGO
Togo
THA
Thailand
TJK
Tadschikistan
TKL
Tokelau
TKM
Turkmenistan
TON
Tonga
TTO
Trinidad und Tobago
TUN
Tunesien
TUR
Türkei (f.)
TUV
Tuvalu
TWN
Taiwan
TWN
Taiwan, siehe: China
TZA
Tansania, Vereinigte Republik (AT, DE) (f.) Tansania (CH)
UGA
Uganda
UKR
Ukraine (f.)
UMI
Amerikanisch-Ozeanien
URY
Uruguay
USA
Guant ánamo-Bucht
USA
Hawaii
USA
Navassa
USA
Vereinigte Staaten (Pl.)
UZB
Usbekistan
VAT
Vatikanstadt (f.)
VCT
St. Vincent und die Grenadinen
VEN
Venezuela
VGB
Britische Jungferninseln
VIR
Amerikanische Jungferninseln
VNM
Vietnam
VUT
Vanuatu
WLF
Wallis und Futuna
WSM
Samoa
YEM
Jemen (auch m.)
ZAF
Südafrika
ZMB
Sambia
ZWE
Simbabwe (AT, DE) Zimbabwe (CH)
Anhang D. Verwendete Zeichen
In der folgenden Tabelle sind die möglichen Zeichen aufgelistet, die von der dpa-infocom zur Zeit
verwendet werden. Diese Liste kann allerdings erweitert werden. Deshalb sollte bei der
Implementierung darauf geachtet werden, dass auch andere Zeichen potentiell verarbeitet werden
können.
Zeichensatz
Dezimal
Hex
UTF-8
Basic Latin
32
0020
SP
Symbol Name
SP
Space
Basic Latin
33
0021
!
!
Exclamation Mark
Basic Latin
34
0022
"
"
Quotation Mark
Basic Latin
35
0023
#
#
Number Sign
Basic Latin
36
0024
$
$
Dollar Sign
Basic Latin
37
0025
%
%
Percent Sign
Basic Latin
38
0026
&
%
Ampersand
Basic Latin
39
0027
'
'
Apostrophe
Basic Latin
40
0028
(
(
Left Parenthesis
Basic Latin
41
0029
)
)
Right Parenthesis
Basic Latin
42
002A
*
*
Asterisk
Basic Latin
43
002B
+
+
Plus Sign
Basic Latin
44
002C
,
,
Comma
Basic Latin
45
002D
-
-
Hyphen-Minus
Basic Latin
46
002E
.
.
Full Stop
Basic Latin
47
002F
/
/
Solidus
Basic Latin
48
0030
0
0
Digit Zero
Basic Latin
49
0031
1
1
Digit One
Basic Latin
50
0032
2
2
Digit Two
Basic Latin
51
0033
3
3
Digit Three
Basic Latin
52
0034
4
4
Digit Four
Basic Latin
53
0035
5
5
Digit Five
Basic Latin
54
0036
6
6
Digit Six
Basic Latin
55
0037
7
7
Digit Seven
Basic Latin
56
0038
8
8
Digit Eight
Basic Latin
57
0039
9
9
Digit Nine
Basic Latin
58
003A
:
:
Colon
Basic Latin
59
003B
;
;
Semicolon
Basic Latin
60
003C
<
<
Less-Than Sign
Basic Latin
61
003D
=
=
Equals Sign
Basic Latin
62
003E
>
>
Greater-Than Sign
Basic Latin
63
003F
?
?
Question Mark
Basic Latin
64
0040
@
@
Commercial AT
Basic Latin
65
0041
A
A
Latin Capital Letter A
Basic Latin
66
0042
B
B
Latin Capital Letter B
Basic Latin
67
0043
C
C
Latin Capital Letter C
Basic Latin
68
0044
D
D
Latin Capital Letter D
Basic Latin
69
0045
E
E
Latin Capital Letter E
Basic Latin
70
0046
F
F
Latin Capital Letter F
Basic Latin
71
0047
G
G
Latin Capital Letter G
Basic Latin
72
0048
H
H
Latin Capital Letter H
Basic Latin
73
0049
I
I
Latin Capital Letter I
Basic Latin
74
004A
J
J
Latin Capital Letter J
Basic Latin
75
004B
K
K
Latin Capital Letter K
Basic Latin
76
004C
L
L
Latin Capital Letter L
Basic Latin
77
004D
M
M
Latin Capital Letter M
Basic Latin
78
004E
N
N
Latin Capital Letter N
Basic Latin
79
004F
O
O
Latin Capital Letter O
Basic Latin
80
0050
P
P
Latin Capital Letter P
Basic Latin
81
0051
Q
Q
Latin Capital Letter Q
Basic Latin
82
0052
R
R
Latin Capital Letter R
Basic Latin
83
0053
S
S
Latin Capital Letter S
Basic Latin
84
0054
T
T
Latin Capital Letter T
Basic Latin
85
0055
U
U
Latin Capital Letter U
Basic Latin
86
0056
V
V
Latin Capital Letter V
Basic Latin
87
0057
W
W
Latin Capital Letter W
Basic Latin
88
0058
X
X
Latin Capital Letter X
Basic Latin
89
0059
Y
Y
Latin Capital Letter Y
Basic Latin
90
005A
Z
Z
Latin Capital Letter Z
Basic Latin
91
005B
[
[
Left Square Bracket
Basic Latin
92
005C
\
\
Reverse Solidus
Basic Latin
93
005D
]
]
Right Square Bracket
Basic Latin
94
005E
^
^
Circumflex Accent
Basic Latin
95
005F
_
_
Low Line
Basic Latin
96
0060
`
`
Grave Accent
Basic Latin
97
0061
a
a
Latin Small Letter a
Basic Latin
98
0062
b
b
Latin Small Letter b
Basic Latin
99
0063
c
c
Latin Small Letter c
Basic Latin
100
0064
d
d
Latin Small Letter d
Basic Latin
101
0065
e
e
Latin Small Letter e
Basic Latin
102
0066
f
f
Latin Small Letter f
Basic Latin
103
0067
g
g
Latin Small Letter g
Basic Latin
104
0068
h
h
Latin Small Letter h
Basic Latin
105
0069
i
i
Latin Small Letter i
Basic Latin
106
006A
j
j
Latin Small Letter j
Basic Latin
107
006B
k
k
Latin Small Letter k
Basic Latin
108
006C
l
l
Latin Small Letter l
Basic Latin
109
006D
m
m
Latin Small Letter m
Basic Latin
110
006E
n
n
Latin Small Letter n
Basic Latin
111
006F
o
o
Latin Small Letter o
Basic Latin
112
0070
p
p
Latin Small Letter p
Basic Latin
113
0071
q
q
Latin Small Letter q
Basic Latin
114
0072
r
r
Latin Small Letter r
Basic Latin
115
0073
s
s
Latin Small Letter s
Basic Latin
116
0074
t
t
Latin Small Letter t
Basic Latin
117
0075
u
u
Latin Small Letter u
Basic Latin
118
0076
v
v
Latin Small Letter v
Basic Latin
119
0077
w
w
Latin Small Letter w
Basic Latin
120
0078
x
x
Latin Small Letter x
Basic Latin
121
0079
y
y
Latin Small Letter y
Basic Latin
122
007A
z
z
Latin Small Letter z
Basic Latin
123
007B
{
{
Left Curly Bracket
Basic Latin
124
007C
|
|
Vertical Line
Basic Latin
125
007D
}
}
Right Curly Bracket
Basic Latin
126
007E
~
~
Tilde
Latin-1 Supplement
160
00A0
Â
No-Break Space
Latin-1 Supplement
161
00A1
Â
NBSP
¡
Â¢
¢
Cent Sign
Â£
£
Pound Sign
Â¥
¥
Yen Sign
Â§
§
Section Sign
Â©
©
Copyright Sign
Âª
ª
Feminine Ordinal Indicator
Â«
«
Left Ptg.Double Angle Quotation Mark
Not Sign
Latin-1 Supplement
Latin-1 Supplement
Latin-1 Supplement
Latin-1 Supplement
Latin-1 Supplement
Latin-1 Supplement
Latin-1 Supplement
162
163
165
167
169
170
171
00A2
00A3
00A5
00A7
00A9
00AA
00AB
Inverted Exclamation Mark
Latin-1 Supplement
172
00AC
Â¬
¬
Latin-1 Supplement
173
00AD
Â
Soft Hyphen
Latin-1 Supplement
174
00AE
Â®

®
Â¯
¯
Macron
Â°
°
Degree Sign
Â±
±
Plus-Minus Sign
Â²
²
Superscript Two
Â³
³
Superscript Three
Âµ
µ
Micro Sign
Latin-1 Supplement
Latin-1 Supplement
Latin-1 Supplement
Latin-1 Supplement
Latin-1 Supplement
Latin-1 Supplement
175
176
177
178
179
181
00AF
00B0
00B1
00B2
00B3
00B5
Registered Sign
- Seite 100 von 120 -
Latin-1 Supplement
182
00B6
Â¶
¶
Pilcrow Sign
Latin-1 Supplement
183
00B7
·
Middle Dot
Latin-1 Supplement
185
00B9
Â¹
Â·
¹
Âº
º
Masculine Ordinal Indicator
Â»
»
Right-Ptg. Double Angle Quotation Mark
Inverted Questionmark
Latin-1 Supplement
Latin-1 Supplement
186
187
00BA
00BB
Superscript One
Latin-1 Supplement
191
00BF
Â¿
¿
Latin-1 Supplement
192
00C0
Ã€
À
Latin Capital Letter A with Grave
Latin-1 Supplement
193
00C1
Ã
Á
Latin Capital Letter A with Acute
Latin-1 Supplement
194
00C2
Ã‚
Â
Latin Capital Letter A with Circumflex
Latin-1 Supplement
195
00C3
Ãƒ
Ã
Latin Capital Letter A with Tilde
Latin-1 Supplement
196
00C4
Ã„
Latin Capital Letter A with Diaeresis
Latin-1 Supplement
197
00C5
Ã…
Ä
Å
Latin-1 Supplement
198
00C6
Ã†
Æ
Latin Capital Letter AE
Latin-1 Supplement
199
00C7
Ã‡
Ç
Latin Capital Letter C with Cedilla
Latin-1 Supplement
200
00C8
Ãˆ
È
Latin Capital Letter E with Grave
Latin-1 Supplement
201
00C9
Ã‰
É
Latin Capital Letter E with Acute
Latin-1 Supplement
202
00CA
ÃŠ
Ê
Latin Capital Letter E with Circumflex
Latin-1 Supplement
203
00CB
Ã‹
Ë
Latin Capital Letter E with Diaeresis
Latin-1 Supplement
204
00CC
ÃŒ
Ì
Latin Capital Letter I with Grave
Latin-1 Supplement
205
00CD
Ã
Í
Latin Capital Letter I with Acute
Latin-1 Supplement
206
00CE
ÃŽ
Î
Latin Capital Letter I with Circumflex
Latin-1 Supplement
207
00CF
Ã
Ï
Latin Capital Letter I with Diaeresis
Latin-1 Supplement
208
00D0
Ã
Ð
Latin Capital Letter ETH
Latin-1 Supplement
209
00D1
Ã‘
Ñ
Latin Capital Letter N with Tilde
Latin-1 Supplement
210
00D2
Ã’
Ò
Latin Capital Letter O with Grave
Latin-1 Supplement
211
00D3
Ã“
Ó
Latin Capital Letter O with Acute
Latin-1 Supplement
212
00D4
Ã”
Ô
Latin Capital Letter O with Circumflex
Latin-1 Supplement
213
00D5
Ã•
Õ
Latin Capital Letter O with Tilde
Latin-1 Supplement
214
00D6
Ã–
Ö
Latin Capital Letter O with Diaeresis
Latin-1 Supplement
215
00D7
Ã—
×
Multiplication Sign
Latin-1 Supplement
216
00D8
Ã˜
Ø
Latin Capital Letter O with Stroke
Latin-1 Supplement
217
00D9
Ã™
Ù
Latin Capital Letter U with Grave
Latin-1 Supplement
218
00DA
Ãš
Ú
Latin Capital Letter U with Acute
Latin-1 Supplement
219
00DB
Ã›
Û
Latin Capital Letter U with Circumflex
Latin-1 Supplement
220
00DC
Ãœ
Ü
Latin Capital Letter U with Diaeresis
Latin-1 Supplement
221
00DD
Ã
Ý
Latin Capital Letter Y with Acute
Latin-1 Supplement
222
00DE
Ãž
Þ
Latin Capital Letter Thorn
Latin-1 Supplement
223
00DF
ÃŸ
ß
Latin Small Letter Sharp s
Latin-1 Supplement
224
00E0
Ã
à
Latin Small Letter a with Grave
Latin-1 Supplement
225
00E1
Ã¡
á
Latin Small Letter a with Acute
Latin-1 Supplement
226
00E2
Ã¢
â
Latin Small Letter a with Circumflex
Latin-1 Supplement
227
00E3
Ã£
ã
Latin Small Letter a with Tilde
Latin-1 Supplement
228
00E4
Ã¤
ä
Latin Small Letter a with Diaeresis
Latin-1 Supplement
229
00E5
Ã¥
å
Latin Small Letter a with Ring above
Latin Capital Letter A with Ring above
- Seite 101 von 120 -
Latin-1 Supplement
230
00E6
Ã¦
Æ
Latin Small Letter ae
Latin-1 Supplement
231
00E7
Ã§
ç
Latin Small Letter c with Cedilla
Latin-1 Supplement
232
00E8
Ã¨
è
Latin Small Letter e with Grave
Latin-1 Supplement
233
00E9
Ã©
é
Latin Small Letter e with Acute
Latin-1 Supplement
234
00EA
Ãª
ê
Latin Small Letter e with Circumflex
Latin-1 Supplement
235
00EB
Ã«
ë
Latin Small Letter e with Diaeresis
Latin-1 Supplement
236
00EC
Ã¬
ì
Latin Small Letter i with Grave
Latin-1 Supplement
237
00ED
Ã
í
Latin Small Letter i with Acute
Latin-1 Supplement
238
00EE
Ã®
î
Latin Small Letter i with Circumflex
Latin-1 Supplement
239
00EF
Ã¯
ï
Latin Small Letter i with Diaeresis
Latin-1 Supplement
240
00F0
Ã°
ð
Latin Small Letter ETH
Latin-1 Supplement
241
00F1
Ã±
ñ
Latin Small Letter n with Tilde
Latin-1 Supplement
242
00F2
Ã²
ò
Latin Small Letter o with Grave
Latin-1 Supplement
243
00F3
Ã³
ó
Latin Small Letter o with Acute
Latin-1 Supplement
244
00F4
Ã´
ô
Latin Small Letter o with Circumflex
Latin-1 Supplement
245
00F5
Ãµ
õ
Latin Small Letter o with Tilde
Latin-1 Supplement
246
00F6
Ã¶
ö
Latin Small Letter o with Diaeresis
Latin-1 Supplement
247
00F7
Ã·
÷
Division Sign
Latin-1 Supplement
248
00F8
Ã¸
ø
Latin Small Letter o with Stroke
Latin-1 Supplement
249
00F9
Ã¹
ù
Latin Small Letter u with Grave
Latin-1 Supplement
250
00FA
Ãº
ú
Latin Small Letter u with Acute
Latin-1 Supplement
251
00FB
Ã»
û
Latin Small Letter u with Circumflex
Latin-1 Supplement
252
00FC
Ã¼
Latin Small Letter u with Diaeresis
Latin-1 Supplement
253
00FD
Ã½
ü
ý
Latin-1 Supplement
254
00FE
Ã¾
þ
Latin Small Letter Thorn
Latin-1 Supplement
255
00FF
Ã¿
ÿ
Latin Small Letter y with Diaeresis
Latin Extended-A
338
0152
Å’
Œ
Latin Capital Ligature OE
Latin Extended-A
339
0153
Å“
œ
Latin Small Ligature oe
Latin Extended-A
352
0160
Å
Š
Latin Capital Letter S with Caron
Latin Extended-A
353
0161
Å¡
š
Latin Small Letter s with Caron
Latin Extended-A
376
0178
Å¸
Ÿ
Latin Capital Letter Y with Diaeresis
Latin Extended-A
381
017D
Å½
Ž
Latin Capital Letter Z with Caron
Latin Extended-A
382
017E
Å¾
ž
Latin Small Letter z with Caron
Currency Symbols
8364
20AC
â‚¬
€
Euro Sign
Latin Small Letter y with Acute
Anhang E. Datumsformat - ISO-8601
Der Standard ISO-8601 „Data elements and interchange formats – Information interchange –
Representation of dates and times“ standardisiert die Repräsentation von Datums- und
Uhrzeitangaben. In NITF 3.0 werden Datums- und Uhrzeitangaben gemäß ISO-8601 im Format
CCYYMMDDThhmmss±hhmm
angegeben:
•
C repräsentiert eine Ziffer, die innerhalb der Tausender- und Hunderterkomponente des
Zeitelementes „Jahr“ verwendet wird.
•
Y repräsentiert eine Ziffer, die innerhalb der Zehner und Einheintskomponente des Zeitelements
„Jahr“ verwendet wird.
- Seite 102 von 120 -
•
M repräsentiert eine Ziffer, die für das Zeitelement „Monat“ verwendet wird.
•
D repräsentiert eine Ziffer, die für das Zeitelement „Tag“ verwendet wird.
•
T wird als Zeitbezeichner verwendet, um den Start der Repräsentation der Uhrzeit eines Tages in
kombinierten Datums- und Uhrzeitangaben anzuzeigen.
•
h repräsentiert ein Ziffer, die für das Zeitelement „Stunde“ verwendet wird.
•
m repräsentiert eine Ziffer, die für das Zeitelement „Minute“ verwendet wird.
•
s repräsentiert eine Ziffer, die für das Zeitelement „Sekunde“ verwendet wird.
Das Datum besteht somit aus drei Komponenten:
•
Das Datum.
•
Die Uhrzeit an dem angegebenen Datum.
•
Der Offset in Relation zur Coordinated Universal Time (UTC). Bei allen Meldungen der gelieferten
Dienste wird die Uhrzeit in Mitteleuropäischer Zeit (MEZ), d.h. mit einem Offset von +0100, oder in
Mitteleuropäischer Sommerzeit (MESZ), d.h. mit einem Offset von +0200 angegeben. Soll bei der
Verarbeitung die Uhrzeit ebenfalls in MEZ bzw. MESZ dargestellt werden, braucht der Offset
somit nicht interpretiert werden. Soll die Uhrzeit dagegen in einer anderen Zeitzone dargestellt
werden, muss die Uhrzeit unter Verwendung der Offset-Informationen entsprechend umgerechnet
werden.
Beispiele:
20020218T122510+0100: Repräsentiert den 18. Februar 2002 um 12 Uhr 25 Minuten und 10
Sekunden in MEZ.
20020618T122510+0200: Repräsentiert den 18. Juni 2002 um 12 Uhr 25 Minuten und 10 Sekunden
in MESZ.
Anhang F. Erweiterte DTD von “NITF 3.0 XML”
<!-News Industry Text Format
Document Type Definition - Version 3.0
June 8, 2001
http://www.nitf.org
Copyright (c) 2001. All Rights Reserved.
International Press Telecommunications Council
http://www.iptc.org
For the list of modifications from previous releases, see:
http://www.nitf.org/recent-modifications.html
For the list of proposed modifications, see:
http://www.nitf.org/proposed-changes.html
-->
<!ENTITY % enriched-text '
#PCDATA
| chron
| classifier
| copyrite
| event
| function
| location
| money
- Seite 103 von 120 -
| num
| object.title
| org
| person
| postaddr
| virtloc
| a
| br
| em
| b
| lang
| pronounce
| q
'>
<!ENTITY % block.start "tobject?, key-list?, classifier*, byline?,
dateline?, copyrite?, abstract?">
<!ENTITY % block.content "p | hl2 | table | nitf-table | media | ol |
ul | dl | bq | fn | note | pre | hr">
<!ENTITY % block.end "datasource?">
<!ENTITY % global-attributes '
id
ID
'>
#IMPLIED
<!ENTITY % common-attributes '
id
ID
#IMPLIED
class
NMTOKENS
#IMPLIED
style
CDATA
#IMPLIED
'>
<!ENTITY % cell.align '
align
(left | center | right | justify | char) #IMPLIED
char CDATA
#IMPLIED
charoff CDATA
#IMPLIED
'>
<!ENTITY % cell.valign '
valign
(top | middle | bottom | baseline)
#IMPLIED
'>
<!ENTITY % boolean '(true | false)'>
<!ELEMENT nitf (head?, body)>
<!ATTLIST nitf
%global-attributes;
uno
CDATA
version
CDATA
NITF-XML 3.0//EN"
change.date
CDATA
2001"
change.time
CDATA
baselang
CDATA
class
NMTOKENS
>
#IMPLIED
#FIXED
#FIXED
#FIXED
#IMPLIED
#IMPLIED
"-//IPTC-NAA//DTD
"12 October
"1600"
<!ELEMENT head (title?, meta*, tobject?, iim?, docdata?, pubdata*,
revision-history*)>
<!ATTLIST head
%global-attributes;
>
- Seite 104 von 120 -
<!ELEMENT title (#PCDATA)>
<!ATTLIST title
%global-attributes;
type (
main
| subtitle
| parttitle
| alternate
| abbrev
| other
)
#IMPLIED
>
<!ELEMENT meta EMPTY>
<!ATTLIST meta
%global-attributes;
http-equiv NMTOKEN
name
NMTOKEN
content
CDATA
>
#IMPLIED
#IMPLIED
#REQUIRED
<!ELEMENT tobject (tobject.property*, tobject.subject*)>
<!ATTLIST tobject
%global-attributes;
tobject.type
CDATA
"news"
>
<!ELEMENT tobject.property EMPTY>
<!ATTLIST tobject.property
%global-attributes;
tobject.property.type
CDATA
>
<!ELEMENT tobject.subject EMPTY>
<!ATTLIST tobject.subject
%global-attributes;
tobject.subject.ipr
tobject.subject.refnum
tobject.subject.code
tobject.subject.type
tobject.subject.matter
tobject.subject.detail
>
"current"
CDATA
NMTOKEN
CDATA
CDATA
CDATA
CDATA
"IPTC"
#REQUIRED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
<!ELEMENT iim (ds*)>
<!ATTLIST iim
%global-attributes;
ver
NMTOKEN
#IMPLIED
>
<!ELEMENT ds EMPTY>
<!ATTLIST ds
%global-attributes;
num
NMTOKEN
#REQUIRED
value
CDATA
>
#IMPLIED
<!ELEMENT docdata (
correction
| evloc
| doc-id
- Seite 105 von 120 -
| del-list
| urgency
| fixture
| date.issue
| date.release
| date.expire
| doc-scope
| series
| ed-msg
| du-key
| doc.copyright
| doc.rights
| key-list
| identified-content
)*>
<!ATTLIST docdata
%global-attributes;
>
<!ELEMENT correction EMPTY>
<!ATTLIST correction
%global-attributes;
info
CDATA
id-string
CDATA
regsrc
CDATA
>
#IMPLIED
#IMPLIED
#IMPLIED
<!ELEMENT evloc EMPTY>
<!ATTLIST evloc
%global-attributes;
iso-cc
CDATA
#IMPLIED
state-prov CDATA
#IMPLIED
county-dist
CDATA
#IMPLIED
city
CDATA
#IMPLIED
>
<!ELEMENT doc-id EMPTY>
<!ATTLIST doc-id
%global-attributes;
regsrc
CDATA
#IMPLIED
id-string
CDATA
#IMPLIED
>
<!ELEMENT del-list (from-src)*>
<!ATTLIST del-list
%global-attributes;
>
<!ELEMENT from-src EMPTY>
<!ATTLIST from-src
%global-attributes;
src-name
CDATA
#IMPLIED
level-number
CDATA
#IMPLIED
>
<!ELEMENT urgency EMPTY>
<!ATTLIST urgency
%global-attributes;
ed-urg
NMTOKEN
>
#IMPLIED
<!ELEMENT fixture EMPTY>
- Seite 106 von 120 -
<!ATTLIST fixture
%global-attributes;
fix-id
CDATA
>
<!ELEMENT date.issue EMPTY>
<!ATTLIST date.issue
%global-attributes;
norm
CDATA
>
#IMPLIED
#IMPLIED
<!ELEMENT date.release EMPTY>
<!ATTLIST date.release
%global-attributes;
norm
CDATA
#IMPLIED
>
<!ELEMENT date.expire EMPTY>
<!ATTLIST date.expire
%global-attributes;
norm
CDATA
#IMPLIED
>
<!ELEMENT doc-scope EMPTY>
<!ATTLIST doc-scope
%global-attributes;
scope
CDATA
>
#IMPLIED
<!ELEMENT series EMPTY>
<!ATTLIST series
%global-attributes;
series.name
CDATA
series.part
NMTOKEN
series.totalpart NMTOKEN
"0"
>
<!ELEMENT ed-msg EMPTY>
<!ATTLIST ed-msg
%global-attributes;
msg-type
CDATA
info
CDATA
>
<!ELEMENT du-key EMPTY>
<!ATTLIST du-key
%global-attributes;
generation NMTOKEN
part
NMTOKEN
version
NMTOKEN
key
CDATA
>
#IMPLIED
"0"
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
<!ELEMENT doc.copyright EMPTY>
<!ATTLIST doc.copyright
%global-attributes;
year
NMTOKEN
#IMPLIED
holder
CDATA
>
#IMPLIED
<!ELEMENT doc.rights EMPTY>
<!ATTLIST doc.rights
- Seite 107 von 120 -
%global-attributes;
owner
CDATA
startdate
CDATA
enddate
CDATA
agent
CDATA
geography
CDATA
location-code
CDATA
code-source
CDATA
type
CDATA
limitations
CDATA
>
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
<!ELEMENT key-list (keyword)*>
<!ATTLIST key-list
%global-attributes;
>
<!ELEMENT keyword EMPTY>
<!ATTLIST keyword
%global-attributes;
key
CDATA
>
#IMPLIED
<!ELEMENT identified-content (
person
| org
| location
| event
| function
| object.title
| virtloc
| classifier
)*>
<!ATTLIST identified-content
%global-attributes;
>
<!ELEMENT pubdata EMPTY>
<!ATTLIST pubdata
%global-attributes;
type
(
print
| audio
| video
| web
| appliance
| other
)
#IMPLIED
item-length
CDATA
#IMPLIED
unit-of-measure
(
word
| character
| byte
| inch
| pica
| cm
| hour
| minute
| second
| other
)
#IMPLIED
date.publication CDATA
#IMPLIED
- Seite 108 von 120 -
name
CDATA
issn
CDATA
volume
CDATA
number
CDATA
issue
CDATA
edition.name
CDATA
edition.area
CDATA
position.section CDATA
position.sequence
CDATA
ex-ref
CDATA
>
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
<!ELEMENT revision-history EMPTY>
<!ATTLIST revision-history
%global-attributes;
name
CDATA
#IMPLIED
function
(
writer-author
| editor
| producer
| archivist
| videographer
| graphic-artist
| photographer
| statistician
| other
)
#IMPLIED
norm
CDATA
#IMPLIED
comment
CDATA
#IMPLIED
>
<!ELEMENT body (body.head?, body.content*, body.end?)>
<!ATTLIST body
%common-attributes;
>
<!ELEMENT body.head (
hedline?,
note*,
rights?,
byline*,
distributor?,
dateline*,
abstract?,
series?
)>
<!ATTLIST body.head
%global-attributes;
>
<!ELEMENT hedline (hl1, hl2*)>
<!ATTLIST hedline
%common-attributes;
>
<!ELEMENT hl1 (%enriched-text;)*>
<!ATTLIST hl1 %common-attributes;>
<!ELEMENT hl2 (%enriched-text;)*>
<!ATTLIST hl2 %common-attributes;>
- Seite 109 von 120 -
<!ELEMENT note (body.content)+>
<!ATTLIST note
%common-attributes;
noteclass
(
cpyrt
| end
| hd
| editorsnote
| trademk
| undef
)
type
(std | pa | npa)
>
#IMPLIED
"std"
<!ELEMENT rights (
#PCDATA
| rights.owner
| rights.startdate
| rights.enddate
| rights.agent
| rights.geography
| rights.type
| rights.limitations
)*>
<!ATTLIST rights
%global-attributes;
>
<!ELEMENT rights.owner (#PCDATA)>
<!ATTLIST rights.owner
%global-attributes;
contact
CDATA
#IMPLIED
>
<!ELEMENT rights.startdate (#PCDATA)>
<!ATTLIST rights.startdate
%global-attributes;
norm
CDATA
#IMPLIED
>
<!ELEMENT rights.enddate (#PCDATA)>
<!ATTLIST rights.enddate
%global-attributes;
norm
CDATA
#IMPLIED
>
<!ELEMENT rights.agent (#PCDATA)>
<!ATTLIST rights.agent
%global-attributes;
contact
CDATA
#IMPLIED
>
<!ELEMENT rights.geography (#PCDATA)>
<!ATTLIST rights.geography
%global-attributes;
location-code
CDATA
#IMPLIED
code-source
CDATA
#IMPLIED
>
<!ELEMENT rights.type (#PCDATA)>
<!ATTLIST rights.type
- Seite 110 von 120 -
%global-attributes;
>
<!ELEMENT rights.limitations (#PCDATA)>
<!ATTLIST rights.limitations
%global-attributes;
>
<!ELEMENT byline (#PCDATA | person | byttl | location | virtloc)*>
<!ATTLIST byline
%common-attributes;
>
<!ELEMENT byttl (#PCDATA | org )*>
<!ATTLIST byttl
%global-attributes;
>
<!ELEMENT distributor (#PCDATA | org)*>
<!ATTLIST distributor
%global-attributes;
>
<!ELEMENT dateline (#PCDATA | location | story.date)*>
<!ATTLIST dateline %common-attributes;>
<!ELEMENT story.date (#PCDATA)>
<!ATTLIST story.date
%global-attributes;
norm
CDATA
#IMPLIED
>
<!ELEMENT abstract (%block.content;)+>
<!ATTLIST abstract
%global-attributes;
>
<!ELEMENT copyrite (#PCDATA | copyrite.year | copyrite.holder)*>
<!ATTLIST copyrite
%global-attributes;
>
<!ELEMENT copyrite.year (#PCDATA)>
<!ATTLIST copyrite.year
%global-attributes;
>
<!ELEMENT copyrite.holder (#PCDATA)>
<!ATTLIST copyrite.holder
%global-attributes;
>
<!ELEMENT body.content (block | %block.content;)*>
<!ATTLIST body.content
%global-attributes;
>
<!ELEMENT block ((%block.start;)?, (%block.content;)*,
(%block.end;)?)>
<!ATTLIST block %common-attributes;>
- Seite 111 von 120 -
<!ELEMENT p (%enriched-text;)*>
<!ATTLIST p
%common-attributes;
lede
%boolean;
#IMPLIED
summary
%boolean;
#IMPLIED
optional-text
%boolean;
#IMPLIED
>
<!ELEMENT table (caption?,
| tr+))>
<!ATTLIST table
%common-attributes;
tabletype
ENTITY
align
(
left
| center
| right
)
width
CDATA
cols
NMTOKEN
border
CDATA
frame
(
void
| above
| below
| hsides
| lhs
| rhs
| vsides
| box
| border
)
rules
(
none
| basic
| rows
| cols
| all
)
cellspacing
CDATA
cellpadding
CDATA
>
(col* | colgroup*), thead?, tfoot?, (tbody+
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
<!ELEMENT media (media-metadata*, (media-reference, media-object?)+,
media-caption*, media-producer?)>
<!ATTLIST media
%common-attributes;
media-type (
text
| audio
| image
| video
| data
| application
| other
)
#REQUIRED
>
<!ELEMENT media-reference (#PCDATA)>
<!ATTLIST media-reference
- Seite 112 von 120 -
%global-attributes;
source
name
CDATA
mime-type
CDATA
coding
time
CDATA
time-unit-of-measure
outcue
source-credit
copyright
CDATA
alternate-text
height
width
units
imagemap
CDATA
noflow
>
CDATA
CDATA
CDATA
CDATA
CDATA
CDATA
NMTOKEN
NMTOKEN
(pixels)
(noflow)
<!ELEMENT media-metadata EMPTY>
<!ATTLIST media-metadata
%global-attributes;
name
CDATA
value
CDATA
>
#IMPLIED
#IMPLIED
#REQUIRED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
"pixels"
#IMPLIED
#IMPLIED
#REQUIRED
#IMPLIED
<!ELEMENT media-object (#PCDATA)>
<!ATTLIST media-object
%common-attributes;
encoding
CDATA
#REQUIRED
>
<!ELEMENT media-caption (%enriched-text; | %block.content;)*>
<!ATTLIST media-caption
%common-attributes;
>
<!ELEMENT media-producer (%enriched-text;)*>
<!ATTLIST media-producer
%common-attributes;
>
<!ELEMENT ol (li)+>
<!ATTLIST ol
%common-attributes;
seqnum
NMTOKEN
>
#IMPLIED
<!ELEMENT ul (li)+>
<!ATTLIST ul
%common-attributes;
>
<!ELEMENT li (%enriched-text; | %block.content;)*>
<!ATTLIST li
%common-attributes;
>
<!ELEMENT dl (dt | dd)+>
<!ATTLIST dl %common-attributes;>
<!ELEMENT dt (%enriched-text;)*>
<!ATTLIST dt %common-attributes;>
- Seite 113 von 120 -
<!ELEMENT dd (block)*>
<!ATTLIST dd %common-attributes;>
<!ELEMENT bq (block+, credit?)*>
<!ATTLIST bq
%common-attributes;
nowrap
(nowrap)
#IMPLIED
quote-source
CDATA
#IMPLIED
>
<!ELEMENT credit (%enriched-text;)*>
<!ATTLIST credit %common-attributes;>
<!ELEMENT fn (body.content)+>
<!ATTLIST fn %common-attributes;>
<!ELEMENT pre (#PCDATA)>
<!ATTLIST pre
%global-attributes;
>
<!ELEMENT hr EMPTY>
<!ATTLIST hr
%common-attributes;
>
<!ELEMENT datasource (#PCDATA)>
<!ATTLIST datasource
%global-attributes;
>
<!ELEMENT caption (%enriched-text; | %block.content;)*>
<!ATTLIST caption
%common-attributes;
align
(
top
| bottom
| left
| right
)
#IMPLIED
>
<!ELEMENT col EMPTY>
<!ATTLIST col
%common-attributes;
span
NMTOKEN
"1"
width
CDATA
%cell.align;
%cell.valign;
>
#IMPLIED
<!ELEMENT colgroup (col+)>
<!ATTLIST colgroup
%common-attributes;
%cell.align;
%cell.valign;
>
- Seite 114 von 120 -
<!ELEMENT thead (tr+)>
<!ATTLIST thead
%common-attributes;
%cell.align;
%cell.valign;
>
<!ELEMENT tbody (tr+)>
<!ATTLIST tbody
%common-attributes;
%cell.align;
%cell.valign;
>
<!ELEMENT tfoot (tr+)>
<!ATTLIST tfoot
%common-attributes;
%cell.align;
%cell.valign;
>
<!ELEMENT tr (th | td)+>
<!ATTLIST tr
%common-attributes;
%cell.align;
%cell.valign;
>
<!ELEMENT th (%enriched-text; | %block.content;)*>
<!ATTLIST th
%common-attributes;
axis
CDATA
#IMPLIED
axes
CDATA
#IMPLIED
nowrap
(nowrap)
#IMPLIED
rowspan
NMTOKEN
"1"
colspan
NMTOKEN
"1"
%cell.align;
%cell.valign;
>
<!ELEMENT td (%enriched-text; | %block.content;)*>
<!ATTLIST td
%common-attributes;
axis
CDATA
#IMPLIED
axes
CDATA
#IMPLIED
nowrap
(nowrap)
#IMPLIED
rowspan
NMTOKEN
"1"
colspan
NMTOKEN
"1"
%cell.align;
%cell.valign;
>
<!ELEMENT chron (#PCDATA)>
<!ATTLIST chron
%common-attributes;
norm
CDATA
#IMPLIED
>
<!ELEMENT event (#PCDATA | alt-code)*>
- Seite 115 von 120 -
<!ATTLIST event
%common-attributes;
start-date CDATA
end-date
CDATA
idsrc
CDATA
value
CDATA
>
#IMPLIED
#IMPLIED
#IMPLIED
#IMPLIED
<!ELEMENT function (#PCDATA | alt-code)*>
<!ATTLIST function
%global-attributes;
idsrc
CDATA
#IMPLIED
value
CDATA
#IMPLIED
>
<!ELEMENT location (#PCDATA | sublocation | city | state | region |
country | alt-code)*>
<!ATTLIST location
%common-attributes;
location-code
CDATA
#IMPLIED
code-source
CDATA
#IMPLIED
>
<!ELEMENT sublocation (#PCDATA | alt-code)*>
<!ATTLIST sublocation
%common-attributes;
location-code
CDATA
#IMPLIED
code-source
CDATA
#IMPLIED
>
<!ELEMENT city (#PCDATA | alt-code)*>
<!ATTLIST city
%common-attributes;
city-code
CDATA
#IMPLIED
code-source
CDATA
#IMPLIED
>
<!ELEMENT state (#PCDATA | alt-code)*>
<!ATTLIST state
%common-attributes;
state-code CDATA
#IMPLIED
code-source
CDATA
#IMPLIED
>
<!ELEMENT region (#PCDATA | alt-code)*>
<!ATTLIST region
%common-attributes;
region-code
CDATA
#IMPLIED
code-source
CDATA
#IMPLIED
>
<!ELEMENT country (#PCDATA | alt-code)*>
<!ATTLIST country
%common-attributes;
iso-cc
CDATA
#IMPLIED
>
<!ELEMENT money (#PCDATA)>
<!ATTLIST money
%common-attributes;
unit
CDATA
#IMPLIED
date
CDATA
#IMPLIED
- Seite 116 von 120 -
>
<!ELEMENT num (#PCDATA | frac | sub | sup)*>
<!ATTLIST num
%common-attributes;
units
CDATA
#IMPLIED
decimal-ch CDATA
#IMPLIED
thousands-ch
CDATA
#IMPLIED
>
<!ELEMENT frac (numer, frac-sep?, denom)>
<!ATTLIST frac
%common-attributes;
>
<!ELEMENT numer (#PCDATA)>
<!ATTLIST numer
%global-attributes;
>
<!ELEMENT frac-sep (#PCDATA)>
<!ATTLIST frac-sep
%global-attributes;
>
<!ELEMENT denom (#PCDATA)>
<!ATTLIST denom
%global-attributes;
>
<!ELEMENT sub (#PCDATA)>
<!ATTLIST sub %common-attributes;>
<!ELEMENT sup (#PCDATA)>
<!ATTLIST sup %common-attributes;>
<!ELEMENT object.title (#PCDATA | alt-code)*>
<!ATTLIST object.title
%common-attributes;
idsrc
CDATA
#IMPLIED
value
CDATA
#IMPLIED
>
<!ELEMENT org (#PCDATA | alt-code)*>
<!ATTLIST org
%global-attributes;
idsrc
CDATA
#IMPLIED
value
CDATA
#IMPLIED
>
<!ELEMENT alt-code EMPTY>
<!ATTLIST alt-code
%global-attributes;
idsrc
CDATA
value
CDATA
>
#REQUIRED
#REQUIRED
<!ELEMENT person (#PCDATA | name.given | name.family | function | altcode)*>
<!ATTLIST person
%global-attributes;
idsrc
CDATA
#IMPLIED
- Seite 117 von 120 -
value
>
CDATA
#IMPLIED
<!ELEMENT name.given (#PCDATA)>
<!ATTLIST name.given
%global-attributes;
>
<!ELEMENT name.family (#PCDATA)>
<!ATTLIST name.family
%global-attributes;
>
<!ELEMENT postaddr (addressee, delivery.point?, (postcode |
delivery.office | region | country)*)>
<!ATTLIST postaddr
%global-attributes;
>
<!ELEMENT virtloc (#PCDATA | alt-code)*>
<!ATTLIST virtloc
%common-attributes;
idsrc
CDATA
#IMPLIED
value
CDATA
#IMPLIED
>
<!ELEMENT a (%enriched-text;)*>
<!ATTLIST a
%common-attributes;
href
CDATA
#IMPLIED
name
CDATA
#IMPLIED
rel
NMTOKEN
#IMPLIED
rev
NMTOKEN
#IMPLIED
title
CDATA
#IMPLIED
>
<!ELEMENT br EMPTY>
<!ATTLIST br
%global-attributes;
>
<!ELEMENT em (%enriched-text;)*>
<!ATTLIST em %common-attributes;>
<!ELEMENT b (%enriched-text;)*>
<!ATTLIST b %common-attributes;>
<!ELEMENT lang (%enriched-text;)*>
<!ATTLIST lang %common-attributes;>
<!ELEMENT pronounce (%enriched-text;)*>
<!ATTLIST pronounce
%global-attributes;
guide
CDATA
#IMPLIED
phonetic
CDATA
#IMPLIED
>
<!ELEMENT q (%enriched-text;)*>
<!ATTLIST q
%common-attributes;
quote-source
CDATA
>
#IMPLIED
- Seite 118 von 120 -
<!ELEMENT addressee (person, function?, care.of?)>
<!ATTLIST addressee
%global-attributes;
>
<!ELEMENT care.of (#PCDATA)>
<!ATTLIST care.of
%global-attributes;
>
<!ELEMENT delivery.point (#PCDATA | br)*>
<!ATTLIST delivery.point
%global-attributes;
point-code CDATA
#IMPLIED
code-source
CDATA
#IMPLIED
>
<!ELEMENT postcode (#PCDATA)>
<!ATTLIST postcode
%global-attributes;
code-source
CDATA
>
#IMPLIED
<!ELEMENT delivery.office (#PCDATA | br)*>
<!ATTLIST delivery.office
%global-attributes;
office-code
CDATA
#IMPLIED
code-source
CDATA
#IMPLIED
>
<!ELEMENT body.end (tagline?, bibliography?)>
<!ATTLIST body.end
%global-attributes;
>
<!ELEMENT tagline (%enriched-text;)*>
<!ATTLIST tagline
%common-attributes;
type
(std | pa | npa) "std"
>
<!ELEMENT bibliography (#PCDATA)>
<!ATTLIST bibliography
%common-attributes;
>
<!ELEMENT classifier (#PCDATA | alt-code)*>
<!ATTLIST classifier
%global-attributes;
type CDATA
#IMPLIED
idsrc
CDATA
#IMPLIED
value
CDATA
#IMPLIED
>
<!ELEMENT nitf-table (
nitf-table-metadata,
(table | custom-table | table-reference+)
- Seite 119 von 120 -
)>
<!ATTLIST nitf-table
%global-attributes;
>
<!ELEMENT custom-table (#PCDATA)>
<!ATTLIST custom-table
%common-attributes;
>
<!ELEMENT table-reference EMPTY>
<!ATTLIST table-reference
%global-attributes;
idref
CDATA #REQUIRED
>
<!ELEMENT nitf-table-metadata (nitf-table-summary?, (nitf-colgroup
| nitf-col)+)>
<!ATTLIST nitf-table-metadata
%common-attributes;
subclass
CDATA
#IMPLIED
idsrc
CDATA
#IMPLIED
value
CDATA
#IMPLIED
status
(pre | snap-shot | interim | final |
official)
#IMPLIED
column-count
CDATA
#IMPLIED
row-count
CDATA
#IMPLIED
>
<!ELEMENT nitf-table-summary (p*)>
<!ATTLIST nitf-table-summary
%common-attributes;
>
<!ELEMENT nitf-colgroup (nitf-col)+>
<!ATTLIST nitf-colgroup
%global-attributes;
occurrences
CDATA
#IMPLIED
>
<!ELEMENT nitf-col EMPTY>
<!ATTLIST nitf-col
%global-attributes;
order
idsrc
value
occurrences
data-type
(text
data-format
>
CDATA
#IMPLIED
CDATA
#IMPLIED
CDATA
#IMPLIED
CDATA
#IMPLIED
| number | graphic | other)
#IMPLIED
CDATA
#IMPLIED
Anhang G. Referenzen
[1] dpa-infocom – Datenlieferung
- Seite 120 von 120 -