Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17-Projekten

Doch gibt es hier auch noch andere Kodierungsmöglichkeiten, die nicht im engeren Konzept von Strukturdaten, wohl aber virtuellen Inhaltsverzeichnissen bzw. -registern liegen, die ja auch dem hier verfolgten Zweck der besseren Navigation dienen.

Der andere Fall ist, dass das LABEL-Attribut echten Text-Content enthält. Hier ist das Ignorieren des type Attributs auch unter Viewergesichtspunkten problematisch. Z.B. findet sich eine Überschrift, type=structMD_chapter, und LABEL="Die schöne Melusine...". Da hier nur das Label ausgegeben und nicht weiter qualifiziert wird, sieht der Nutzer nicht, worum es sich handelt. Ist diese eine Überschrift eine Section, ein Kapitel, ein Titelblatt, eine Beischrift zu einer Illustration, ein Kolophon etc. Unschön wird es, wenn sich Struktur und Inhaltsdaten mischen, also "Kapitel", capitula (in der Überschrift), etc.

-----Ursprüngliche Nachricht----- Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg- viewer.de] Im Auftrag von Dr. Thomas Staecker Gesendet: Montag, 23. Februar 2009 12:33 An: dv-technik(a)dfg-viewer.de Betreff: Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17- Projekten Lieber Herr Meyer, liebe Kollegen, ich kann Ihrem Wunsch nach Einfachheit im Prinzip nur zustimmen. Dennoch beunruhigen mich Probleme wie die komplexeren Daten von Frau Federbusch. Weniger für den Viewer, mehr für ein Harvesting. Nun könnte man zwar argumentieren, dass uns das für den Viewer nicht interssiern muss, jedoch prejudizieren wir durch bestimmte Kodierungen Verfahrenswege, die aus meiner Sicht "unterflexibel" sind. Ich möchte daher noch einmal abstrakt rekapitulieren: Wir haben ein Tag für das sozusagen Markup (=type) und ein Tag für den Content (=Label). Der ersten Fall ist der, dass in Type bisher die XML-Form der Strukturdatenliste, z.B. title_page, in LABEL die Umsetzung, z.B. Titelblatt, kodiert wird. Soweit so gut; theoretisch könnte man auch Mehrsprachigkeit auf der Basis des type-Attributes, das ja eigentlich eine Ansetzungsform oder gleichsam Nummer ist, generieren. Doch gibt es hier auch noch andere Kodierungsmöglichkeiten, die nicht im engeren Konzept von Strukturdaten, wohl aber virtuellen Inhaltsverzeichnissen bzw. -registern liegen, die ja auch dem hier verfolgten Zweck der besseren Navigation dienen. Z.B. wenn ich einen Personennamen (hier kommt eine bestimmte Person vor) im Sinne eines virtuellen Personennamenregisters anzeigen möchte, wäre analog eine Kodierung type=[PND-Nummer] Lable=Ansetzungsform zu wählen. In type selber muss dann aber, um Äquivokationen zu vermeiden, ein Schlüssel mitgegeben werden, z.B. type="pnd_1234567". Entsprechend wäre es dann auch ratsam, die Strukturdatenliste - sie mag nun auch HSS-Elemente enthalten oder nicht - mit structMD oder ählichem zu versehen type="structMD_title_page". Wie gesagt, für die Anzeige, die sich aus dem LABEL Attribut speist (wenn denn Mehrsprachigkeit kein Thema ist), ist das erst einmal nebensächlich, für das Harvesting aber zentral. Der andere Fall ist, dass das LABEL-Attribut echten Text-Content enthält. Hier ist das Ignorieren des type Attributs auch unter Viewergesichtspunkten problematisch. Z.B. findet sich eine Überschrift, type=structMD_chapter, und LABEL="Die schöne Melusine...". Da hier nur das Label ausgegeben und nicht weiter qualifiziert wird, sieht der Nutzer nicht, worum es sich handelt. Ist diese eine Überschrift eine Section, ein Kapitel, ein Titelblatt, eine Beischrift zu einer Illustration, ein Kolophon etc. Unschön wird es, wenn sich Struktur und Inhaltsdaten mischen, also "Kapitel", capitula (in der Überschrift), etc. In die selbe Kategorie gehört Volltext oder Teilen daraus. Will der Viewer Voll- oder Teiltranskriptionen zu etwa Handschriften nicht mit anzeigen, wenn sie denn vorliegen? Genau darauf zielte mein Vorschlag, es mit FContent zu versuchen. Herr Heiligenhaus hat den Sachverhalt benannt: "Every div node in the structural map hierarchy may be connected (via subsidiary mptr or fptr elements) to content files which represent that div's portion of the whole document." aber noch nicht in diesem Sinne interpretiert. Mit einem schnellen Hüftschuss kommen wir sicher sofort zur Ver. 2, verbauen uns aber möglicherweise weitere Entwicklungsmöglichkeiten, deswegen wollte ich noch einmal nackhaken, ohne jetzt sicher zu wissen, was genau die Alternative wäre und ob wir das System nicht hypertroph machen. Zumindest ist es nicht unproblematisch die type-label Struktur für alle diese Aspekte verwenden zu wollen. Ein Trffen in Dresden würde ich sehr begrüßen. Bitte aber nicht vor dem 9.3. Viele Grüße, Ihr Th. Stäcker Meyer, Sebastian schrieb: auch schlicht eröffnen. ist dann unter ich geeinigt, ich habe es lediglich noch nicht umgesetzt. dem der Viewer künftig auch noch eine Vielzahl verschiedener Strukturdatensets unterstützen soll. Das wäre aus meiner Sicht auch nicht besonders zielführend: müsste erst wieder ein Standard geschaffen werden, wie solche Listen auszusehen haben. Wir müssten uns auf Format und Übertragungsweg einigen und auch wieder alle Eventualitäten beachten. Wie soll der Viewer beispielsweise reagieren, wenn die Liste nicht erreichbar ist oder in einem ungültigen Format vorliegt? eigenes Strukturdatenset anfertigen und in den eigenen METS-Dateien verlinken kann. Das würde zwar die Abstraktion des Viewers erhöhen, umgekehrt aber auch jede Bemühung um ein standardisiertes Strukturdatenset zunichte machen. Medientypen jeweils eigene Strukturdatensets zu pflegen, sondern nur genau _ein_ Set zu unterstützen, dass jedoch passende Strukturdaten für verschiedene Medientypen enthält. Statt also für Handschriften ein eigenes Strukturdatenset zu erstellen, würde ich lieber dem vorhandenen einige handschriften-spezifische Strukturdaten hinzufügen. (Zumal es ohnehin eine Schnittmenge zwischen beiden Sets gäbe.) Das hätte den Vorteil, dass der Viewer nicht auch noch vor der Darstellung der Strukturdaten erst anhand irgendwelcher Kriterien eine Auswahl des passenden Sets treffen müsste. aber, genannt des 2.1 enthält noch einige weitere Punkte, die ich in den nächsten 1-2 Wochen umsetzen werde. Anschließend würde sich ein weiteres Treffen zur Diskussion des Arbeitsstands und der nächsten Schritte anbieten. Ein Termin in der zweiten Märzhälfte wäre mir sehr recht. Ich werde einmal schauen, wann hier entsprechende Räumlichkeiten frei wären und mache dann auch konkretere Terminvorschläge. bounces@dfg- von sollte type- wird daß "contentids") angewandte der Strukturdatenvergabe im stehen, III. englischsprachigen ist auch schlicht eröffnen. ist dann unter ich http://digitale.bibliothek.uni- halle.de/oai/?verb=GetRecord&metadataPrefix=mets&identifier=692944"/> Aus Rede." daher ;) mangels technisch werden sicher kontrolliertes Stelle treffen Mir >> fehlt >>> hier einfach noch ein Baustein. aber, genannt des -- Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung) Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel Tel. +49(0)5331/808-119 - email: staecker(a)hab.de