21 Dec
2010
21 Dec
'10
11:49 a.m.
Lieber Herr Meyer, lieber Herr Schaßan,
besten Dank für die Bereitstellung des Beispiels! Das sieht doch schon mal, nach erster
Sichtung, sehr vielversprechend aus! Erste Anmerkungen / Nachfragen von meiner Seite:
1) Aktuell finden sich ja noch keine Strukturdaten im Beispiel. Hier sehe ich eigentlich
der größten Klärungsbedarf, denn anders als bei Druckschriften haben wir im
Handschriftenbereich keine so klare "Aufgabenteilung" zwischen TEI und METS wie
zwischen MODS und METS. In welche Richtung gehen da aktuell Ihre Überlegungen?
2) Entsprechend fehlt die log. structMap (und damit auch die persistente Adressierung der
Handschrift via @ CONTENTIDS). Die Verlinkung unter structLink
<mets:structLink>
<mets:smLink xlink:from="log_mss_278-helmst_tei-msDesc_Lesser"
xlink:to="phys_mss_278-helmst_tei-msDesc_Lesser"/>
</mets:structLink>
ist deshalb auch noch ein Fake, denn ein Element mit der ID
"log_mss_278-helmst_tei-msDesc_Lesser" fehlt ja im Dokument. (Eigentlich dürfte
der Viewer so was überhaupt nicht anzeigen, aber wenn die zugrundeliegende Frage noch
nicht geklärt ist, kann man damit vorerst leben).
3) Das Element <mets:digiprovMD> enthält einen interessanten Hinweis von Herrn
Schaßan:
<mets:digiprovMD ID="digiprov_mss_278-helmst_tei-msDesc_Lesser">
<mets:mdWrap MIMETYPE="text/xml" MDTYPE="OTHER"
OTHERMDTYPE="DVLINKS">
<mets:xmlData>
<dv:links xmlns:dv="http://dfg-viewer.de/">
<dv:reference>zu_berechnen_oder_als_Parameter_zu_übergeben</dv:reference>
<dv:presentation/>
</dv:links>
</mets:xmlData>
</mets:mdWrap>
</mets:digiprovMD>
Hm. Da erlaube ich mir doch die Nachfrage, ob das wirklich z.Z. eine Überlegung ist in der
Community? An welchen "Berechnungsalgorithmus" haben Sie denn so gedacht?
Beste Grüße,
Kay Heiligenhaus
21 Dec
21 Dec
3:14 p.m.
New subject: Prototyp eines DFG-Viewers für METS/TEI
Lieber Herr Heiligenhaus,
besten Dank für die Bereitstellung des Beispiels! Das
sieht doch schon mal, nach erster Sichtung, sehr vielversprechend aus! Erste Anmerkungen /
Nachfragen von meiner Seite:
1) Aktuell finden sich ja noch keine Strukturdaten im Beispiel. Hier sehe ich eigentlich
der größten Klärungsbedarf, denn anders als bei Druckschriften haben wir im
Handschriftenbereich keine so klare "Aufgabenteilung" zwischen TEI und METS wie
zwischen MODS und METS. In welche Richtung gehen da aktuell Ihre Überlegungen?
In der Tat können die TEI-Daten die Strukturdaten (mindestens teilweise)
enthalten: In einer Beschreibung z.B. als Nachweise von Texten in
<msItem>, in Volltexten z.B. als <div>/<head> oder <pb/> etc.
Genau aus diesem Grund habe ich noch keine Konversion in METS-Strukturen
vorgenommen. Hier ist eine Diskussion in der Community notwendig, welche
(TEI-)Elemente in welche METS-Strukturen überführt werden sollten. Aus
METS-Sicht ist die Konversion natürlich notwendig, ob nicht aber eine
generische Verarbeitung der TEI-Daten im Viewer-Kontext ausreicht, wäre
zu diskutieren.
Eine Stelle, an der wir (in der HAB durch interne Diskussionen
ermittelt) ganz klar METS vorziehen und in Zukunft auch unmittelbar METS
-bislang ohne eigene TEI-Kodierung- gebrauchen werden, ist die
Moglichkeit, über <structMap TYPE="physical"> verschiedene
Paginierungs-/Foliierungssysteme zu dokumentieren, virtuelle Umbindungen
vorzunehmen etc.
vgl. dazu http://diglib.hab.de/edoc/ed000006/mss/64-weiss/METS.xml
2) Entsprechend fehlt die log. structMap (und damit
auch die persistente Adressierung der Handschrift via @ CONTENTIDS).
Ja, die structMap habe ich noch auskommentiert, einen weiteren Vorschlag
kann ich aber machen.
3) Das Element<mets:digiprovMD> enthält einen
interessanten Hinweis von Herrn Schaßan:
<mets:digiprovMD ID="digiprov_mss_278-helmst_tei-msDesc_Lesser">
<mets:mdWrap MIMETYPE="text/xml" MDTYPE="OTHER"
OTHERMDTYPE="DVLINKS">
<mets:xmlData>
<dv:links xmlns:dv="http://dfg-viewer.de/">
<dv:reference>zu_berechnen_oder_als_Parameter_zu_übergeben</dv:reference>
<dv:presentation/>
</dv:links>
</mets:xmlData>
</mets:mdWrap>
</mets:digiprovMD>
Hm. Da erlaube ich mir doch die Nachfrage, ob das wirklich z.Z. eine Überlegung ist in
der Community? An welchen "Berechnungsalgorithmus" haben Sie denn so gedacht?
Diese Angabe bezieht sich auf die "Gestaltung" von Webadressen digitaler
Bibliotheken. Nicht in allen Bibliotheken werden "vorhersehbare"
Webadressen genutzt, die es möglich machen, z.B. in einer
Handschriftenbeschreibung aus der Signatur auf die Webadresse zu
schließen. Auch wenn das im Grunde wünschenswert wäre, kann das
tei2mets-Skript doch nicht davon ausgehen. Also gibt es im Skript einen
Parameter, dessen Wert entweder gesetzt wird, schlicht aus den Daten
ausgelesen wird oder aus der Beschreibung per Algorithmus ermittelt
werden könnte. Da digitale Bibliotheken und Kodierung wahrscheinlich
niemals so zu vereinheitlichen sind, dass an dieser Stelle im Skript
eine feste Angabe stehen könnte, habe ich als Erinnerung diesen Ausdruck
verwendet. (Und hier auch so stehen gelassen, um genau diese Diskussion
anzuzetteln. Sonst hätte ich für die Beispieldaten ja auch noch einen
Wert einsetzen können.)
Frohe Weihnachten wünscht,
Torsten Schaßan
--
Torsten Schassan
Digitale Editionen
Abteilung Handschriften und Sondersammlungen
Herzog August Bibliothek, Postfach 1364, D-38299 Wolfenbuettel
Tel.: +49-5331-808-130 (Fax -165), schassan {at} hab.de
http://www.hab.de/forschung/projekte/europeana-regia.htm
http://www.hab.de/forschung/projekte/weiss64.htm
5:09 p.m.
New subject: [DFG-Viewer] Prototyp eines DFG-Viewers für METS/TEI
Lieber Herr Schaßan,
Das wäre eigentlich mein erster Angang gewesen, denn hier genau unterscheidet sich eben
MODS von TEI. Aber:
Ich erinnere mich an eine Diskussion, die wir auf Inetbib in ähnlichem Kontext bzgl. der
Nutzung von URNs hatten... ;)
1) Aktuell
finden sich ja noch keine Strukturdaten im Beispiel. Hier sehe ich
eigentlich der
größten Klärungsbedarf, denn anders als bei Druckschriften
haben wir im Handschriftenbereich keine so klare "Aufgabenteilung"
zwischen TEI und METS wie zwischen MODS und METS. In welche Richtung
gehen da aktuell Ihre Überlegungen?
In der Tat können die TEI-Daten die Strukturdaten (mindestens teilweise)
enthalten: In einer Beschreibung z.B. als Nachweise von Texten in <msItem>,
in Volltexten z.B. als <div>/<head> oder <pb/> etc.
Genau aus diesem Grund habe ich noch keine Konversion in METS-
Strukturen vorgenommen. Hier ist eine Diskussion in der Community
notwendig, welche (TEI-)Elemente in welche METS-Strukturen überführt
werden sollten. Aus METS-Sicht ist die Konversion natürlich notwendig, ob
nicht aber eine generische Verarbeitung der TEI-Daten im Viewer-Kontext
ausreicht, wäre zu diskutieren. Eine Stelle, an der wir (in der HAB durch interne
Diskussionen
ermittelt) ganz klar METS vorziehen und in Zukunft auch unmittelbar METS -
bislang ohne eigene TEI-Kodierung- gebrauchen werden, ist die Moglichkeit,
über <structMap TYPE="physical"> verschiedene Paginierungs-
/Foliierungssysteme zu dokumentieren, virtuelle Umbindungen
vorzunehmen etc.
vgl. dazu http://diglib.hab.de/edoc/ed000006/mss/64-weiss/METS.xml
Sie meinen <structMap TYPE="logical">, oder? Das scheint mir auch genau
der Vorteil zu sein. Dann wird es aber vergeblich, ein Mapping TEI-METS zu machen, denn in
TEI liegen diese "verschiedenen Perspektiven" ja nicht vor. Vielmehr hätten wir
eine Arbeitsteilung zwischen METS und TEI analog zu METS/MODS bei Druckschriften. Korrekt?
3) Das
Element<mets:digiprovMD> enthält einen interessanten Hinweis
von Herrn
Schaßan:
<mets:digiprovMD ID="digiprov_mss_278-helmst_tei-msDesc_Lesser">
<mets:mdWrap MIMETYPE="text/xml" MDTYPE="OTHER"
OTHERMDTYPE="DVLINKS">
<mets:xmlData>
<dv:links xmlns:dv="http://dfg-viewer.de/">
<dv:reference>zu_berechnen_oder_als_Parameter_zu_übergeben</dv:ref
erence>
<dv:presentation/>
</dv:links>
</mets:xmlData>
</mets:mdWrap>
</mets:digiprovMD>
Hm. Da erlaube ich mir doch die Nachfrage, ob das wirklich z.Z. eine
Überlegung
ist in der Community? An welchen "Berechnungsalgorithmus"
haben Sie denn so gedacht?
Diese Angabe bezieht sich auf die "Gestaltung" von Webadressen digitaler
Bibliotheken. Nicht in allen Bibliotheken werden "vorhersehbare"
Webadressen genutzt, die es möglich machen, z.B. in einer
Handschriftenbeschreibung aus der Signatur auf die Webadresse zu
schließen. Auch wenn das im Grunde wünschenswert wäre, kann das
tei2mets-Skript doch nicht davon ausgehen. Also gibt es im Skript einen
Parameter, dessen Wert entweder gesetzt wird, schlicht aus den Daten
ausgelesen wird oder aus der Beschreibung per Algorithmus ermittelt
werden könnte.
Sie sprechen jetzt über Ihre eigene Transformation von TEI zu METS, nicht von einem
"Script", das im Viewer implementiert ist. Korrekt?
Da digitale Bibliotheken und Kodierung wahrscheinlich
niemals so zu vereinheitlichen sind, dass an dieser Stelle im Skript
eine feste Angabe stehen könnte, habe ich als Erinnerung diesen Ausdruck
verwendet. (Und hier auch so stehen gelassen, um genau diese Diskussion
anzuzetteln. Sonst hätte ich für die Beispieldaten ja auch noch einen
Wert einsetzen können.)
Ich fühlte mich genau dadurch und aufgrund unserer damaligen Diskussion in Inetbib
"angezettelt". Wir sind uns aber einig, daß im resultierenden METS hier die
Konventionen eingehalten werden, die wir im Viewer bereits nutzen. Oder?
Beste Grüße,
Kay Heiligenhaus
22 Dec
22 Dec
2:49 p.m.
New subject: Prototyp eines DFG-Viewers für METS/TEI
Lieber Herr Heiligenhaus,
Am 21.12.2010 11:49, schrieb Kay Heiligenhaus:
Lieber Herr Meyer, lieber Herr Schaßan,
besten Dank für die Bereitstellung des Beispiels! Das sieht doch schon mal, nach erster
Sichtung, sehr vielversprechend aus! Erste Anmerkungen / Nachfragen von meiner Seite:
1) Aktuell finden sich ja noch keine Strukturdaten im Beispiel. Hier sehe ich eigentlich
der größten Klärungsbedarf, denn anders als bei Druckschriften haben wir im
Handschriftenbereich keine so klare "Aufgabenteilung" zwischen TEI und METS wie
zwischen MODS und METS. In welche Richtung gehen da aktuell Ihre Überlegungen?
Ich sehe es eigentlich so, dass man <msItem> als massgebliche Struktur
anzeigen sollte. Handschriften haben ihre Einheit anders als Drucke
durch ihre buchbinderische Zusammenfügung, d.h. sie werden in der Regel
von Deckel zu Deckel gescannt und auch so in Katalogen unten den
Signaturen beschrieben. Die buchbinderischen Einheiten sind sodann durch
<msItem> strukturiert. <msItem> entspäche gewissermassen untergeordneten
Titeln. Dazu können weitere Strukturinformationen nach Liste treten.
Dort wurden ja bereits Handschriftenbelange berücksichtigt. Diese würden
dann aber vermutlich nicht im teiHeader, sondern in METS abgelegt. Beide
Aspekte ineinander zu "verblenden" dürfte die Herausforderung sein.
Viele Grüße und schon einmal ein frohes Weihnachtsfest,
Ihr
Th. Stäcker
2) Entsprechend fehlt die log. structMap (und damit
auch die persistente Adressierung der Handschrift via @ CONTENTIDS). Die Verlinkung unter
structLink
<mets:structLink>
<mets:smLink xlink:from="log_mss_278-helmst_tei-msDesc_Lesser"
xlink:to="phys_mss_278-helmst_tei-msDesc_Lesser"/>
</mets:structLink>
ist deshalb auch noch ein Fake, denn ein Element mit der ID
"log_mss_278-helmst_tei-msDesc_Lesser" fehlt ja im Dokument. (Eigentlich dürfte
der Viewer so was überhaupt nicht anzeigen, aber wenn die zugrundeliegende Frage noch
nicht geklärt ist, kann man damit vorerst leben).
3) Das Element<mets:digiprovMD> enthält einen interessanten Hinweis von Herrn
Schaßan:
<mets:digiprovMD ID="digiprov_mss_278-helmst_tei-msDesc_Lesser">
<mets:mdWrap MIMETYPE="text/xml" MDTYPE="OTHER"
OTHERMDTYPE="DVLINKS">
<mets:xmlData>
<dv:links xmlns:dv="http://dfg-viewer.de/">
<dv:reference>zu_berechnen_oder_als_Parameter_zu_übergeben</dv:reference>
<dv:presentation/>
</dv:links>
</mets:xmlData>
</mets:mdWrap>
</mets:digiprovMD>
Hm. Da erlaube ich mir doch die Nachfrage, ob das wirklich z.Z. eine Überlegung ist in
der Community? An welchen "Berechnungsalgorithmus" haben Sie denn so gedacht?
Beste Grüße,
Kay Heiligenhaus
5137
days inactive
5138
days old
3 comments
3 participants
participants (3)
-
Kay Heiligenhaus -
Thomas Stäcker -
Torsten Schassan