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

Lieber Herr Staecker, diese Informationen haben aus meiner Sicht aber nichts in der logischen structMap zu suchen. Dort sollen logische Strukturen kodiert werden, aber nicht deren Inhalte. Hier kann also beispielsweise ein Personenregister verzeichnet sein, aber nicht sämtliche Einträge des Registers (bzw. solche wären als "entry" zu kennzeichnen und nicht mit einer PND-ID o.ä. zu qualifizieren). Darüber hinausgehende Informationen sollten in entsprechenden verknüpften Sektionen abgelegt werden. Für Volltexte und Transskriptionen bietet sich da beispielsweise das TEI-P5-Format an (entweder in FContent oder einer eigenständigen Datei). PND-IDs von Personeneinträgen eines Registers gehören meiner Ansicht nach in eine Metadatensektion und nicht in die Strukturdaten. Das Problem werden Sie aber immer haben. Wir könnten jetzt natürlich festlegen, dass der Viewer die Navigation stets nach dem Muster "Type: Label" aufbaut, dann ergibt das aber für ihr Kapitel/capitula-Beispiel unschöne Ergebnisse. Lassen wir es dagegen so wie es ist (nur "Label" bzw. künftig wahlweise auch nur "Type", wenn kein Label vorhanden ist), dann besteht das Problem der fehlenden Qualifizierung des Typs. Da sehe ich allerdings die Datenerzeuger in der Verantwortung und nicht den Viewer: das Label-Attribut bezeichnet in meinem Verständnis eben gerade die gewünschte Anzeigeform und nicht eine exakte Transskription des Originals. Wenn der Datenlieferant also der Bezeichnung also den Typ des Strukturelements voran- oder hintenanstellen möchte, sollte er das im Label-Attribut auch so vermerken. Das ist auch der Grund, weshalb ich in einem älteren Beispiel einmal die Kapitelüberschriften jeweils in ein eigenes title-Feld einer MODS-Sektion gesteckt hatte - dabei handelte es sich dann um die exakte Transskription von der Vorlage, während im Label-Attribut teilweise davon abweichende (meist gekürzte) Anzeigeformen standen. Damals wurde ich darauf hingewiesen, dass es sich bei Kapitelüberschriften nicht um Titel handelt und sie deshalb nicht in das title-Feld von MODS geschrieben werden dürfen. Prinzipiell würde ich diesen Ansatz jedoch auch weiterhin bevorzugen und nicht das Label-Attribut ausschließlich Transskriptionen vorbehalten wollen. Viele Grüße Sebastian Meyer -- Sebastian Meyer Projekt-Mitarbeiter Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Tel.: +49 351 4677-206 Fax: +49 351 4677-711 http://www.slub-dresden.de/ > -----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. > 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: > > Liebe Kollegen, > > > >> Hintergrund des Problems ist > >> aus meiner Sicht, daß wir aktuell _gezwungen_ sind, für jedes DIV > auch > >> ein LABEL-Attribut zu liefern - der Viewer interessiert sich > schlicht > >> nicht für das TYPE-Attribut. Damit gehen aber alle Möglichkeiten > >> verloren, die die Verwendung eines kontrollierten Vokabulars > eröffnen. > >> Konzept war und muß aus meiner Sicht hier sein: Das TYPE-Attribut > ist > >> verpflichtend, das LABEL-Attribut ist optional. Wenn ein LABEL > >> vorhanden ist, wird dies ohne Berücksichtigung des aktuellen > >> Sprachmodus des Viewers angezeigt. Wenn kein LABEL vorhanden ist, > dann > >> wird TYPE ausgewertet und entsprechend unserer abgestimmten Liste > unter > >> > >> http://dfg-viewer.de/strukturdatenset/ > >> > >> in der jeweils im Viewer gewählten Sprache angezeigt. Am besten - um > >> das voneinander abzuheben - in eckigen Klammern. So jeweils hatte > ich > >> den letzten Diskussionstand verstanden. > > > > Richtig, so sollte es sein. Darauf hatten wir uns auch zuletzt > geeinigt, ich habe es lediglich noch nicht umgesetzt. > > > > Ich würde die Sache allerdings nur ungern weiter verkomplizieren, in > 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: > > Wenn auch externe Strukturdatenlisten unterstützt werden sollen, > 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? > > Außerdem bedeuten extern gepflegte Listen, dass im Grunde jeder sein > 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. > > Ich würde sogar so weit gehen, nicht einmal für verschiedene > 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. > > > >> Fände ich auch prima. Aus dem ursprünglich avisierten Treffen im > >> letzten Jahr in Dresden ist ja leider nichts geworden. Ich denke > aber, > >> daß manche Aspekte dieser Diskussion eher im Kontext "Viewer 3.0" zu > >> sehen sind. Für "Viewer 2.0" sehe ich die Punkte, die ich oben > genannt > >> habe, aber nicht als Erweiterung, sondern als konsequente Umsetzung > des > >> bereits besprochenen rsp. angedachten, aber nicht durchgeführten... > > > > Ja, ein Treffen fände ich auch prima. Meine ToDo-Liste für Version > 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. > > > > Viele Grüße > > Sebastian Meyer > > > > -- > > > > Sebastian Meyer > > Projekt-Mitarbeiter > > > > Sächsische Landesbibliothek - > > Staats- und Universitätsbibliothek Dresden (SLUB) > > 01054 Dresden > > Tel.: +49 351 4677-206 > > Fax: +49 351 4677-711 > > http://www.slub-dresden.de/ > > > > > >> -----Ursprüngliche Nachricht----- > >> Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- > bounces@dfg- > >> viewer.de] Im Auftrag von Kay Heiligenhaus > >> Gesendet: Samstag, 21. Februar 2009 12:36 > >> An: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de > >> Betreff: Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17- > >> Projekten > >> > >> Lieber Herr Stäcker, liebe Kolleginnen und Kollegen, > >> > >>> aus unserer Sicht ist die Typisierung mit VD16 und VD17 ok, wir > >> müssten > >>> es allerdings noch implementieren. > >> Wie gesagt, wir müßten es auch bei uns noch umstellen (von 'vda' auf > >> 'VD17'). Zu klären wären dann noch, ob wir eine geschlossene Liste > von > >> Identifier-Typen vorsehen - was ich befürworten würde, denn hier > sollte > >> m.E. nicht alles mögliche angezeigt werden (MODS macht bzgl. des > type- > >> Attributes keine Vorgaben). Für die jetzige Umsetzung würde ich > >> folgende Liste vorschlagen: 'VD16', 'VD17', 'ZDB'. Der Type 'URN' > wird > >> ja eh bereits besonders behandelt (was mich dazu bringt anzumerken, > daß > >> leider weiterhin die Seiten-Identifier (aus dem Attribut > "contentids") > >> nicht, wie vereinbart, im Viewer angezeigt werden). > >> > >>> Ich möchte daher noch einmal abstrakt fragen, ob das hier > angewandte > >>> Prinzip so jetzt ok und praktikabel ist. Ich habe doch einige > >> Zweifel. > >>> Nehmen wir z.B. > >>> > >>> <mets:div ID="log809417" TYPE="title_page" LABEL="Titelblatt" > >>> ORDER="1"/> > >>> <mets:div ID="log976482" TYPE="section" LABEL="Leichen-Text. Aus > der > >>> Geheimten Offenb. S. Johannis Cap. III. v. 5." ORDER="1"/> > >>> > >>> Daraus lassen sich zwei grundsätzliche Fälle der > Strukturdatenvergabe > >>> unterscheiden. Zum einen kann neben TYPE, das den englischen > >>> "Ansetzungsbegriff" bzw. ID, z.B. title_page oder section, enthält > im > >>> Label der "Content" dieses Begriffes, hier "Leichen-Text..." > stehen, > >>> zum anderen kann das LABEL die Übersetzung des Ansetzungsbegriffs > >>> enthalten title_page -> title page oder Titelblatt. Ich frage mich, > >> ob > >>> diese unterschiedlichen Verwendungen nicht in irgendeiner Form > >>> qualifiziert werden sollten. Theoretisch kann man ja bei > >>> TYPE="title_page" in LABEL auf den Inhalt der Titelseite schreiben. > >> In > >>> Ermangelung weiterer qualifizierender Tags könnte man in LABEL auf > >> der > >>> PCDATA-Ebene qualifizieren, indem z.B. Zitate grundsätzlich mit > >>> Anführungszeichen versehen werden: > >>> > >>> LABEL="'Leichen-Text. Aus der Geheimten Offenb. S. Johannis Cap. > III. > >>> v. > >>> 5.'" > >> Oh. Ihr Anliegen kann ich verstehen - wir hatten darüber bereits auf > >> dieser Liste diskutiert im Rahmen der Umsetzung der > englischsprachigen > >> Lokalisierung der Viewer-Implementierung -, aber den Vorschlag finde > >> ich aus technischer Sicht ziemlich "wild". Hintergrund des Problems > ist > >> aus meiner Sicht, daß wir aktuell _gezwungen_ sind, für jedes DIV > auch > >> ein LABEL-Attribut zu liefern - der Viewer interessiert sich > schlicht > >> nicht für das TYPE-Attribut. Damit gehen aber alle Möglichkeiten > >> verloren, die die Verwendung eines kontrollierten Vokabulars > eröffnen. > >> Konzept war und muß aus meiner Sicht hier sein: Das TYPE-Attribut > ist > >> verpflichtend, das LABEL-Attribut ist optional. Wenn ein LABEL > >> vorhanden ist, wird dies ohne Berücksichtigung des aktuellen > >> Sprachmodus des Viewers angezeigt. Wenn kein LABEL vorhanden ist, > dann > >> wird TYPE ausgewertet und entsprechend unserer abgestimmten Liste > unter > >> > >> http://dfg-viewer.de/strukturdatenset/ > >> > >> in der jeweils im Viewer gewählten Sprache angezeigt. Am besten - um > >> das voneinander abzuheben - in eckigen Klammern. So jeweils hatte > ich > >> den letzten Diskussionstand verstanden. > >> > >> Für mein ursprüngliches Beispiel unter > http://digitale.bibliothek.uni- > >> halle.de/oai/?verb=GetRecord&metadataPrefix=mets&identifier=692944 > >> konkretisiert hieße das: > >> > >> <mets:structMap TYPE="LOGICAL"> > >> <mets:div ID="log692944" DMDID="md692944" ADMID="amd692944" > >> TYPE="monograph" LABEL="Album Electorum Das Stamm- und Lebens Buch" > >> ORDER="1" CONTENTIDS="urn:nbn:de:gbv:3:1-79574"> > >> <mets:mptr LOCTYPE="URL" > >> xlink:href="http://digitale.bibliothek.uni- > >> > halle.de/oai/?verb=GetRecord&metadataPrefix=mets&identifier=692944"/> > >> <mets:div ID="log809417" TYPE="title_page" ORDER="1"/> > >> <mets:div ID="log809419" TYPE="dedication" ORDER="2"/> > >> <mets:div ID="log809421" TYPE="section" ORDER="3"> > >> <mets:div ID="log976482" TYPE="section" LABEL="Leichen-Text. > Aus > >> der Geheimten Offenb. S. Johannis Cap. III. v. 5." ORDER="1"/> > >> <mets:div ID="log976483" TYPE="section" LABEL="Eingang." > >> ORDER="2"/> > >> <mets:div ID="log976484" TYPE="section" LABEL="Abhandlung." > >> ORDER="3"/> > >> </mets:div> > >> <mets:div ID="log809455" TYPE="section" LABEL="Lebens-Lauff." > >> ORDER="4"/> > >> <mets:div ID="log809465" TYPE="section" LABEL="Abdanckungs- > Rede." > >> ORDER="5"/> > >> </mets:div> > >> </mets:structMap> > >> > >>> Anfühungszeichen, das ist mir bewusst, machen natürlich beim > >>> Prozessieren immer Schwierigkeiten und müssen maskiert werden, > daher > >>> wäre auch dies denkbar: > >>> > >>> LABEL="<q>Leichen-Text. Aus der Geheimten Offenb. S. Johannis Cap. > >> III. > >>> v. 5.</q>" > >> Jetzt wird es m.E. "ganz wild". Das bringt einen Metsologen - ich > >> selbst verstehe mich nicht als einen - wohl an den Rand des Kollaps. > ;) > >> > >>> Zum anderen noch die Frage, ob wir eine Qaulifizierung der Sprache > >>> brauchen. Geht so etwas (ich habe es nicht geprüft): > >>> > >>> <mets:div ID="log809417" TYPE="title_page" LABEL="Titelblatt" > >>> xml:lang="de" ORDER="1"/> > >>> > >>> Das ist für die Anzeige vielleihct nicht ganz so wichtig, wohl aber > >> für > >>> das Einsammeln von Daten, die nicht der Viewer-Strukturliste folgen > >> Das finde ich eine gute Anregung. Allerdings kann ich aktuell > mangels > >> Zugriff auf die LoC-Seiten auch nicht beurteilen, ob das METS- > technisch > >> so in Ordnung wäre. > >> > >>> Das bringt mich dann zu der Frage, ob man nicht grundsätzlich eher > >>> anders vorgehen sollte und in TYPE die Art des Strukturdatensets > >>> vermerkt und in LABEL den Ansetzungsbegriff. Dann müsste an anderer > >>> Stelle auf die Repräsentation des Ansetzungsbegriffs verwiesen > werden > >>> (z.B. Strukturdatenliste, Ortsnamenliste, Personennamenliste, > >>> Fachthesaurus, etc.): > >>> > >>> <mets:div ID="log809417" TYPE="structMD-dv" LABEL="title_page" > >>> ORDER="1"/> > >>> > >>> oder > >>> > >>> <mets:div ID="log809417" TYPE="ortsnamen" LABEL="Nummer Getty > >>> Thesaurus/Geodaten" ORDER="1"/> > >> Oh. Damit kommen wir m.E. in Teufelsküche, denn TYPE dient ganz > sicher > >> nicht dazu, eine Referenz auf ein kontrolliertes / nicht > kontrolliertes > >> Vokabular zu machen. Das müßte m.E., wenn überhaupt, an anderer > Stelle > >> geschehen. > >> > >>> Wäre es angesichts dessen nicht sinnvoll, sich noch eimal zu > treffen > >>> und diese Aspekte zu diskutieren und endgültig zu verabschieden? > Mir > >> fehlt > >>> hier einfach noch ein Baustein. > >> Fände ich auch prima. Aus dem ursprünglich avisierten Treffen im > >> letzten Jahr in Dresden ist ja leider nichts geworden. Ich denke > aber, > >> daß manche Aspekte dieser Diskussion eher im Kontext "Viewer 3.0" zu > >> sehen sind. Für "Viewer 2.0" sehe ich die Punkte, die ich oben > genannt > >> habe, aber nicht als Erweiterung, sondern als konsequente Umsetzung > des > >> bereits besprochenen rsp. angedachten, aber nicht durchgeführten... > >> > >> Beste Grüße, > >> Kay Heiligenhaus > > > > > > > -- > 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 >