Lieber Herr Stäcker,
> Sie haben zu meinen letzten Vorschlag, die Textelemente in ein FContent
> Element zu verschieben, nichts gesagt.
Ich war wahrscheinlich schon zu vernebelt von meiner allmählichen Verfertigung der Gedanken beim Lesen. ;)
> Die FContent Variante scheint mir dagegen zielführender zu sein und eher in der METS Linie zu liegen
> (Stichwort: Zeigerorgie ;-)).
Ja, in dieser Hinsicht schon. Aber mir scheint das an dieser Stelle nicht notwendig rsp. würden wir uns m.E. mit Ihrem Vorschlag zu weit von der METS-Community und den - zumindest mir bekannten - Implementierungen entfernen.
Da nun die LoC-Seiten wieder da sind, kurz daraus:
"FContent: file content.
The FContent element is used to deliver a content file for a METS document within the METS file itself. The content file must be either Base 64 encoded, and contained within the subsidiary binData wrapper element, or consist of XML information and be contained within the subsidiary xmlData wrapper element." (http://www.loc.gov/standards/mets/docs/mets.v1-7.html#FContent)
Ich denke, das erklärt hinreichend, warum FContent so, wie Sie das andenken, nicht wirklich weiterhelfen kann.
> 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"/>
Auch hier der Hinweis auf die Spezifikation:
"div: Division.
The METS standard represents a document structurally as a series of nested div elements, that is, as a hierarchy (e.g., a book, which is composed of chapters, which are composed of subchapters, which are composed of text). 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.
[...]
LABEL: xsd:string optional
LABEL: an optional string label to describe this div to an end user viewing the document, as per a table of contents entry (NB: a div LABEL should be specific to its level in the structural map. In the case of a book with chapters, the book div LABEL should have the book title, and the chapter div LABELS should have the individual chapter titles, rather than having the chapter div LABELs combine both book title and chapter title).
[...]
TYPE: xsd:string optional
TYPE: an optional string attribute for specifying a type of division (e.g., chapter, article, page, etc.)." (http://www.loc.gov/standards/mets/docs/mets.v1-7.html#div)
Man kann das nun sehr weit auslegen, damit auch Ihr Vorschlag unter diese Beschreibung paßt. Ich denke aber, daß wir uns auch damit zu sehr von den Ausführungen hier in der Spezifikation sowie den verschiedenen Implementierung derselben bewegen würden. Zumindest ist mit kein METS-Profil bekannt, daß einen ähnlichen Angang macht, wie Sie ihn hier vorschlagen. Das spricht nicht prinzipiell gegen dieses Vorgehen, mir erschließt sich aber noch nicht, was der Vorzug gegenüber der bestehenden Kodierung sein sollte.
Wie gesagt: Gegen flexible "Strukturdatensets" (zur Abbildung unterschiedlicher "Medientypen") habe ich nichts einzuwenden. Ich denke aber, daß sich ein METS-Dokument, das an den Viewer ausgeliefert wird, auf einen Medientyp "festlegen" sollte und die für diesen Typ spezifischen "kontrollierten Vokabularien" verwenden. Das wäre im Falle von VD16/17, soweit ich das verstanden habe, die auf den Viewer-Seiten dokumentierte Typologie. Dieses Festlegen findet aktuell implizit statt - wir haben halt aktuell "nur" eine dokumentierte Typologie. Sobald es weitere gibt, sollte man diese Bezugnahme vielleicht explizit regeln. Der DV-Namensraum im aktuellen Profil wird uns dazu schon den Raum bieten.
Beste Grüße,
Kay Heiligenhaus
Liebe Kolleginnen und Kollegen,
offenbar gab es seit den Arbeiten am Listenserver Anfang des Monats einige Probleme mit den Mailinglisten. Teilweise verweigerte der Mail-Server der SLUB den Empfang von Mails an die DFG-Viewer-Listen. Ursache war eine fehlerhafte Konfiguration des internen DNS-Dienstes. Das Problem ist nun behoben.
Bitte entschuldigen Sie die Störung.
Viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Projekt-Mitarbeiter
Abteilung Informationstechnologie (IT)
Referat Entwicklung
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Besucheradresse: Zellescher Weg 18
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
Mail: smeyer(a)slub-dresden.de
Web: http://www.slub-dresden.de/
___________________________________________________
Liebe Kolleginnen und Kollegen,
die Arbeiten an unserem Listen-Server sind nun abgeschlossen. Die beiden DFG-Viewer-Mailinglisten "Support" und "Technik" sind damit ab sofort wieder freigegeben.
Viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Projekt-Mitarbeiter
Abteilung Informationstechnologie (IT)
Referat Entwicklung
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Besucheradresse: Zellescher Weg 18
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
Mail: smeyer(a)slub-dresden.de
Web: http://www.slub-dresden.de/
___________________________________________________
> -----Ursprüngliche Nachricht-----
> Von: Meyer, Sebastian
> Gesendet: Mittwoch, 4. Februar 2009 16:18
> An: 'technik(a)dfg-viewer.de'; 'support(a)dfg-viewer.de'
> Betreff: Arbeiten an den DFG-Viewer Mailinglisten
>
> Liebe Kolleginnen und Kollegen,
>
> am morgigen Donnerstag, 5. Februar, wird unser Listen-Server aufgrund
> notwendiger administrativer Arbeiten am Vormittag nicht erreichbar
> sein. Das vorgesehene Wartungsfenster umfasst die Zeit von 8 bis 12
> Uhr. Es werden beide Mailinglisten ("Technik" und "Support")
> gleichermaßen von der Maßnahme betroffen sein.
>
> Ich möchte Sie daher bitten, im genannten Zeitraum vom Versand von
> Mails an die Mailinglisten abzusehen. Darüber hinaus gibt es von Ihrer
> Seite nichts zu beachten. Nach Abschluss der Arbeiten sind die
> Mailinglisten wie gewohnt nutzbar. Über die Freigabe des Listen-Servers
> werde ich Sie auf diesem Weg informieren.
>
> Vielen Dank für Ihr Verständnis und viele Grüße
> Sebastian Meyer
>
> --
> ___________________________________________________
>
> Sebastian Meyer
> Projekt-Mitarbeiter
>
> Abteilung Informationstechnologie (IT)
> Referat Entwicklung
>
> Sächsische Landesbibliothek -
> Staats- und Universitätsbibliothek Dresden (SLUB)
> 01054 Dresden
> Besucheradresse: Zellescher Weg 18
>
> Tel.: +49 351 4677-206
> Fax: +49 351 4677-711
> Mail: smeyer(a)slub-dresden.de
> Web: http://www.slub-dresden.de/
> ___________________________________________________
>
Liebe Kolleginnen und Kollegen,
am morgigen Donnerstag, 5. Februar, wird unser Listen-Server aufgrund notwendiger administrativer Arbeiten am Vormittag nicht erreichbar sein. Das vorgesehene Wartungsfenster umfasst die Zeit von 8 bis 12 Uhr. Es werden beide Mailinglisten ("Technik" und "Support") gleichermaßen von der Maßnahme betroffen sein.
Ich möchte Sie daher bitten, im genannten Zeitraum vom Versand von Mails an die Mailinglisten abzusehen. Darüber hinaus gibt es von Ihrer Seite nichts zu beachten. Nach Abschluss der Arbeiten sind die Mailinglisten wie gewohnt nutzbar. Über die Freigabe des Listen-Servers werde ich Sie auf diesem Weg informieren.
Vielen Dank für Ihr Verständnis und viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Projekt-Mitarbeiter
Abteilung Informationstechnologie (IT)
Referat Entwicklung
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Besucheradresse: Zellescher Weg 18
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
Mail: smeyer(a)slub-dresden.de
Web: http://www.slub-dresden.de/
___________________________________________________