21 Feb
2009
21 Feb
'09
7:52 p.m.
Lieber Herr Heiligenhaus,
Sie haben zu meinen letzten Vorschlag, die Textelemente in ein FContent
Element zu verschieben, nichts gesagt. Wie Kleist das nennt, sind mir
die Gedanken beim Niederschreiben gekommen, insbesondere angesichts der
mir dämmernden Absurdität mit Anführungszeichen und Tags im Attribut,
was - da haben Sie völlig recht - nicht nur wild, sondern verkorkst
wäre. Kurz, vergessen Sie das einfach. Die FContent Variante scheint mir
dagegen zielführender zu sein und eher in der METS Linie zu liegen
(Stichwort: Zeigerorgie ;-)).
Für die Strukturdaten ohne Content hätten wir dann die Möglichkeit in
TYPE die Art des LABELS (auch Thesauri etc.) zu qualifizieren, d.h.
am besten:
<mets:div ID="log809417" TYPE="Strukturdaten"
LABEL="title_page" ORDER="1"/>
wobei dem Viewer auch noch mitgeteilt werden müsste, wie er "title_page"
auflösen soll,
am zweitbesten:
<mets:div ID="log809417" TYPE="Strukturdaten"
LABEL="Titelseite"
ORDER="1"/>
was für den Viewer einfach wäre, aber bequemere Möglichkeiten z.B. des
Sprachwechsels, verhinderte und auch für das spätere Harvesting nicht
so optimal wäre. Ich ahne das wachsende Unbehagen von Herrn Meyer .
Sobald die LOC wieder da ist (ich kann mich nicht erinnern, dass das
früher schon mal passiert ist), werde ich mal ein Beispiel ausformulieren.
Viele Grüße,
Ihr
Th. Stäcker
Kay Heiligenhaus schrieb:
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&metadataPre…
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