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

Liebe Kollegen, 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. 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. > > Beste Grüße, > Kay Heiligenhaus