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

Lieber Herr Heiligenhaus, liebe Kolleginnen und Kollegen, aus unserer Sicht ist die Typisierung mit VD16 und VD17 ok, wir müssten es allerdings noch implementieren. Ich möchte des weiteren noch einmal die Gelegenheit ergreifen grundsätzlich zu fragen, ob die Kodierung der Strukturdaten jetzt so verbindlich ist. Ich habe nicht in Erinnerung, dass wir darüber abschliessend gesprochen hätten (aber ich habe ein schwaches Gedächtnis), weiss aber noch, dass wir beim Anliegen von Frau Federbusch "hängengeblieben" sind. 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.'" 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>" 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 (bei diesen kann man die Übersetzungsbegriffe ja der Liste entnehmen). Es sei mal dieser Fall konstruiert: <mets:div ID="log809417" TYPE="ortsname" LABEL="München" xml:lang="de" ORDER="1"/> und <mets:div ID="log809417" TYPE="ortsname" LABEL="Munich" xml:lang="en" ORDER="1"/> 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"/> In beiden Fällen müsste der Viewer aus vorhandenen Listen die zugehörige Anzeigeform ermitteln und ausgeben. Auf diese Listen könnte über FLocat zugegriffen werden. Bei Transkriptionselementen könnte man dann - der Sache adäquater- ein FContent Tag in der Filesection anlegen: <mets:div ID="log809417" FILEID="FContent_xyz" TYPE="structMD-dv" LABEL="section" ORDER="1"/> verweist auf <mets:FContent ID="FContent_xyz"> <xmlData>Leichen-Text. Aus der Geheimten ...</xmlData> </mets:FContent> Ich weiss, es ist etwas umständlicher zu implementieren, es böte zugleich aber deutlich mehr Flexibilität vor allem bei der Repäsentation normierter Elemente. Es wäre vielleicht auch ein guter Weg für das Problem von Frau Federbusch, wo es um komplexere Sinn- und Abschnittseinheiten ging, und öffnete den Viewer für umfangreichere Volltextelemente. Wenn dies pläsiert, sollte auf jeden Fall noch einmal ein METSOLOGE darauf schauen. Da im Moment die LOC Seite nicht verfügbar ist, kann ich nicht validieren (ohne aufwändig lokal umzubauen). 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. Viele Grüße, Ihr Th. Stäcker Kay Heiligenhaus schrieb: