Lieber Herr Stäcker, Ich war wahrscheinlich schon zu vernebelt von meiner allmählichen Verfertigung der Gedanken beim Lesen. ;) 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. 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