Lieber Herr Staecker, diese Informationen haben aus meiner Sicht aber nichts in der logischen structMap zu suchen. Dort sollen logische Strukturen kodiert werden, aber nicht deren Inhalte. Hier kann also beispielsweise ein Personenregister verzeichnet sein, aber nicht sämtliche Einträge des Registers (bzw. solche wären als "entry" zu kennzeichnen und nicht mit einer PND-ID o.ä. zu qualifizieren). Darüber hinausgehende Informationen sollten in entsprechenden verknüpften Sektionen abgelegt werden. Für Volltexte und Transskriptionen bietet sich da beispielsweise das TEI-P5-Format an (entweder in FContent oder einer eigenständigen Datei). PND-IDs von Personeneinträgen eines Registers gehören meiner Ansicht nach in eine Metadatensektion und nicht in die Strukturdaten. Das Problem werden Sie aber immer haben. Wir könnten jetzt natürlich festlegen, dass der Viewer die Navigation stets nach dem Muster "Type: Label" aufbaut, dann ergibt das aber für ihr Kapitel/capitula-Beispiel unschöne Ergebnisse. Lassen wir es dagegen so wie es ist (nur "Label" bzw. künftig wahlweise auch nur "Type", wenn kein Label vorhanden ist), dann besteht das Problem der fehlenden Qualifizierung des Typs. Da sehe ich allerdings die Datenerzeuger in der Verantwortung und nicht den Viewer: das Label-Attribut bezeichnet in meinem Verständnis eben gerade die gewünschte Anzeigeform und nicht eine exakte Transskription des Originals. Wenn der Datenlieferant also der Bezeichnung also den Typ des Strukturelements voran- oder hintenanstellen möchte, sollte er das im Label-Attribut auch so vermerken. Das ist auch der Grund, weshalb ich in einem älteren Beispiel einmal die Kapitelüberschriften jeweils in ein eigenes title-Feld einer MODS-Sektion gesteckt hatte - dabei handelte es sich dann um die exakte Transskription von der Vorlage, während im Label-Attribut teilweise davon abweichende (meist gekürzte) Anzeigeformen standen. Damals wurde ich darauf hingewiesen, dass es sich bei Kapitelüberschriften nicht um Titel handelt und sie deshalb nicht in das title-Feld von MODS geschrieben werden dürfen. Prinzipiell würde ich diesen Ansatz jedoch auch weiterhin bevorzugen und nicht das Label-Attribut ausschließlich Transskriptionen vorbehalten wollen. Viele Grüße Sebastian Meyer -- Sebastian Meyer Projekt-Mitarbeiter Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Tel.: +49 351 4677-206 Fax: +49 351 4677-711 http://www.slub-dresden.de/ > -----Ursprüngliche Nachricht----- > Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg- > viewer.de] Im Auftrag von Dr. Thomas Staecker > Gesendet: Montag, 23. Februar 2009 12:33 > An: dv-technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17- > Projekten > > Lieber Herr Meyer, liebe Kollegen, > > ich kann Ihrem Wunsch nach Einfachheit im Prinzip nur zustimmen. > Dennoch > beunruhigen mich Probleme wie die komplexeren Daten von Frau > Federbusch. Weniger für den Viewer, mehr für ein Harvesting. Nun könnte > man zwar argumentieren, dass uns das für den Viewer nicht interssiern > muss, jedoch prejudizieren wir durch bestimmte Kodierungen > Verfahrenswege, die aus meiner Sicht "unterflexibel" sind. Ich möchte > daher noch einmal abstrakt rekapitulieren: Wir haben ein Tag für das > sozusagen Markup (=type) und ein Tag für den Content (=Label). > > Der ersten Fall ist der, dass in Type bisher die XML-Form der > Strukturdatenliste, z.B. title_page, in LABEL die Umsetzung, z.B. > Titelblatt, kodiert wird. Soweit so gut; theoretisch könnte man auch > Mehrsprachigkeit auf der Basis des type-Attributes, das ja eigentlich > eine Ansetzungsform oder gleichsam Nummer ist, generieren. > Z.B. wenn ich einen Personennamen (hier kommt eine bestimmte Person > vor) > im Sinne eines virtuellen Personennamenregisters anzeigen möchte, wäre > analog eine Kodierung type=[PND-Nummer] Lable=Ansetzungsform zu wählen. > In type selber muss dann aber, um Äquivokationen zu vermeiden, ein > Schlüssel mitgegeben werden, z.B. type="pnd_1234567". Entsprechend wäre > es dann auch ratsam, die Strukturdatenliste - sie mag nun auch > HSS-Elemente enthalten oder nicht - mit structMD oder ählichem zu > versehen type="structMD_title_page". Wie gesagt, für die Anzeige, die > sich aus dem LABEL Attribut speist (wenn denn Mehrsprachigkeit kein > Thema ist), ist das erst einmal nebensächlich, für das Harvesting aber > zentral. > > Der andere Fall ist, dass das LABEL-Attribut echten Text-Content > enthält. Hier ist das Ignorieren des type Attributs auch unter > Viewergesichtspunkten problematisch. Z.B. findet sich eine Überschrift, > type=structMD_chapter, und LABEL="Die schöne Melusine...". Da hier nur > das Label ausgegeben und nicht weiter qualifiziert wird, sieht der > Nutzer nicht, worum es sich handelt. Ist diese eine Überschrift eine > Section, ein Kapitel, ein Titelblatt, eine Beischrift zu einer > Illustration, ein Kolophon etc. Unschön wird es, wenn sich Struktur und > Inhaltsdaten mischen, also "Kapitel", capitula (in der Überschrift), > etc. In die selbe Kategorie gehört Volltext oder Teilen daraus. Will > der > Viewer Voll- oder Teiltranskriptionen zu etwa Handschriften nicht mit > anzeigen, wenn sie denn vorliegen? Genau darauf zielte mein Vorschlag, > es mit FContent zu versuchen. Herr Heiligenhaus hat den Sachverhalt > benannt: > > "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." > > aber noch nicht in diesem Sinne interpretiert. > > Mit einem schnellen Hüftschuss kommen wir sicher sofort zur Ver. 2, > verbauen uns aber möglicherweise weitere Entwicklungsmöglichkeiten, > deswegen wollte ich noch einmal nackhaken, ohne jetzt sicher zu wissen, > was genau die Alternative wäre und ob wir das System nicht hypertroph > machen. Zumindest ist es nicht unproblematisch die type-label Struktur > für alle diese Aspekte verwenden zu wollen. > > Ein Trffen in Dresden würde ich sehr begrüßen. Bitte aber nicht vor dem > 9.3. > > Viele Grüße, > Ihr > Th. Stäcker > > > > > > > > > > > > > > > Meyer, Sebastian schrieb: > > Liebe Kollegen, > > > >> 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. > > > > Richtig, so sollte es sein. Darauf hatten wir uns auch zuletzt > geeinigt, ich habe es lediglich noch nicht umgesetzt. > > > > Ich würde die Sache allerdings nur ungern weiter verkomplizieren, in > dem der Viewer künftig auch noch eine Vielzahl verschiedener > Strukturdatensets unterstützen soll. Das wäre aus meiner Sicht auch > nicht besonders zielführend: > > Wenn auch externe Strukturdatenlisten unterstützt werden sollen, > müsste erst wieder ein Standard geschaffen werden, wie solche Listen > auszusehen haben. Wir müssten uns auf Format und Übertragungsweg > einigen und auch wieder alle Eventualitäten beachten. Wie soll der > Viewer beispielsweise reagieren, wenn die Liste nicht erreichbar ist > oder in einem ungültigen Format vorliegt? > > Außerdem bedeuten extern gepflegte Listen, dass im Grunde jeder sein > eigenes Strukturdatenset anfertigen und in den eigenen METS-Dateien > verlinken kann. Das würde zwar die Abstraktion des Viewers erhöhen, > umgekehrt aber auch jede Bemühung um ein standardisiertes > Strukturdatenset zunichte machen. > > Ich würde sogar so weit gehen, nicht einmal für verschiedene > Medientypen jeweils eigene Strukturdatensets zu pflegen, sondern nur > genau _ein_ Set zu unterstützen, dass jedoch passende Strukturdaten für > verschiedene Medientypen enthält. Statt also für Handschriften ein > eigenes Strukturdatenset zu erstellen, würde ich lieber dem vorhandenen > einige handschriften-spezifische Strukturdaten hinzufügen. (Zumal es > ohnehin eine Schnittmenge zwischen beiden Sets gäbe.) Das hätte den > Vorteil, dass der Viewer nicht auch noch vor der Darstellung der > Strukturdaten erst anhand irgendwelcher Kriterien eine Auswahl des > passenden Sets treffen müsste. > > > >> 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... > > > > Ja, ein Treffen fände ich auch prima. Meine ToDo-Liste für Version > 2.1 enthält noch einige weitere Punkte, die ich in den nächsten 1-2 > Wochen umsetzen werde. Anschließend würde sich ein weiteres Treffen zur > Diskussion des Arbeitsstands und der nächsten Schritte anbieten. Ein > Termin in der zweiten Märzhälfte wäre mir sehr recht. Ich werde einmal > schauen, wann hier entsprechende Räumlichkeiten frei wären und mache > dann auch konkretere Terminvorschläge. > > > > Viele Grüße > > Sebastian Meyer > > > > -- > > > > Sebastian Meyer > > Projekt-Mitarbeiter > > > > Sächsische Landesbibliothek - > > Staats- und Universitätsbibliothek Dresden (SLUB) > > 01054 Dresden > > Tel.: +49 351 4677-206 > > Fax: +49 351 4677-711 > > http://www.slub-dresden.de/ > > > > > >> -----Ursprüngliche Nachricht----- > >> Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- > bounces@dfg- > >> viewer.de] Im Auftrag von Kay Heiligenhaus > >> Gesendet: Samstag, 21. Februar 2009 12:36 > >> An: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de > >> Betreff: Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17- > >> Projekten > >> > >> 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&metadataPrefix=mets&identifier=692944 > >> 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 > > > > > > > -- > Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung) > Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel > Tel. +49(0)5331/808-119 - email: staecker(a)hab.de >

Lieber Herr Staecker, die Übersetzung des Typs kann der Viewer vornehmen. Dafür haben wir ja die Strukturdatenliste. Eine gestalterische Differenzierung von Typ und Label ist auch kein Problem, das machen wir in Dresden ja auch so. Mehrsprachige METS-Dateien würde ich nur mit niedriger Priorität behandeln wollen. Der Implementierungsaufwand ist auf beiden Seiten relativ hoch und die Nutzung wird sich deshalb in engen Grenzen halten. Ich bin mir deshalb nicht sicher, ob es sich lohnen würde. Das steht auf meiner ToDo-Liste unter "Version 3.0". :) Viele Grüße Sebastian Meyer -- Sebastian Meyer Projekt-Mitarbeiter Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Tel.: +49 351 4677-206 Fax: +49 351 4677-711 http://www.slub-dresden.de/ > -----Ursprüngliche Nachricht----- > Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg- > viewer.de] Im Auftrag von Dr. Thomas Staecker > Gesendet: Montag, 23. Februar 2009 13:17 > An: dv-technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17- > Projekten > > Lieber Herr Meyer, > > > Lieber Herr Staecker, > > > >> Doch gibt es hier auch noch andere Kodierungsmöglichkeiten, die > nicht > >> im > >> engeren Konzept von Strukturdaten, wohl aber virtuellen > >> Inhaltsverzeichnissen bzw. -registern liegen, die ja auch dem hier > >> verfolgten Zweck der besseren Navigation dienen. > > > > diese Informationen haben aus meiner Sicht aber nichts in der > logischen structMap zu suchen. Dort sollen logische Strukturen kodiert > werden, aber nicht deren Inhalte. Hier kann also beispielsweise ein > Personenregister verzeichnet sein, aber nicht sämtliche Einträge des > Registers (bzw. solche wären als "entry" zu kennzeichnen und nicht mit > einer PND-ID o.ä. zu qualifizieren). Darüber hinausgehende > Informationen sollten in entsprechenden verknüpften Sektionen abgelegt > werden. Für Volltexte und Transskriptionen bietet sich da > beispielsweise das TEI-P5-Format an (entweder in FContent oder einer > eigenständigen Datei). PND-IDs von Personeneinträgen eines Registers > gehören meiner Ansicht nach in eine Metadatensektion und nicht in die > Strukturdaten. > > Ja, dem würde ich so auch folgen wollen. Wir bräuchten jedoch noch ein > Beispiel bzw. Verfahren dafür. Wie gesagt, nach meiner Ansicht geht es > hier im Prinzip um Volltext, der in eine FContent gehört, das dann vom > Typ TEI sein muss. Wie das angezeigt wird, ist dann noch eine andere > Frage. > > > > >> Der andere Fall ist, dass das LABEL-Attribut echten Text-Content > >> enthält. Hier ist das Ignorieren des type Attributs auch unter > >> Viewergesichtspunkten problematisch. Z.B. findet sich eine > Überschrift, > >> type=structMD_chapter, und LABEL="Die schöne Melusine...". Da hier > nur > >> das Label ausgegeben und nicht weiter qualifiziert wird, sieht der > >> Nutzer nicht, worum es sich handelt. Ist diese eine Überschrift eine > >> Section, ein Kapitel, ein Titelblatt, eine Beischrift zu einer > >> Illustration, ein Kolophon etc. Unschön wird es, wenn sich Struktur > und > >> Inhaltsdaten mischen, also "Kapitel", capitula (in der Überschrift), > >> etc. > > > > Das Problem werden Sie aber immer haben. Wir könnten jetzt natürlich > festlegen, dass der Viewer die Navigation stets nach dem Muster "Type: > Label" aufbaut, dann ergibt das aber für ihr Kapitel/capitula-Beispiel > unschöne Ergebnisse. Lassen wir es dagegen so wie es ist (nur "Label" > bzw. künftig wahlweise auch nur "Type", wenn kein Label vorhanden ist), > dann besteht das Problem der fehlenden Qualifizierung des Typs. Da sehe > ich allerdings die Datenerzeuger in der Verantwortung und nicht den > Viewer: das Label-Attribut bezeichnet in meinem Verständnis eben gerade > die gewünschte Anzeigeform und nicht eine exakte Transskription des > Originals. Wenn der Datenlieferant also der Bezeichnung also den Typ > des Strukturelements voran- oder hintenanstellen möchte, sollte er das > im Label-Attribut auch so vermerken. > > Das ist auch der Grund, weshalb ich in einem älteren Beispiel einmal > die Kapitelüberschriften jeweils in ein eigenes title-Feld einer MODS- > Sektion gesteckt hatte - dabei handelte es sich dann um die exakte > Transskription von der Vorlage, während im Label-Attribut teilweise > davon abweichende (meist gekürzte) Anzeigeformen standen. Damals wurde > ich darauf hingewiesen, dass es sich bei Kapitelüberschriften nicht um > Titel handelt und sie deshalb nicht in das title-Feld von MODS > geschrieben werden dürfen. Prinzipiell würde ich diesen Ansatz jedoch > auch weiterhin bevorzugen und nicht das Label-Attribut ausschließlich > Transskriptionen vorbehalten wollen. > > > > Viele Grüße, > Ihr > Th. Stäcker > > > > > > > Viele Grüße > > Sebastian Meyer > > > > -- > > > > Sebastian Meyer > > Projekt-Mitarbeiter > > > > Sächsische Landesbibliothek - > > Staats- und Universitätsbibliothek Dresden (SLUB) > > 01054 Dresden > > Tel.: +49 351 4677-206 > > Fax: +49 351 4677-711 > > http://www.slub-dresden.de/ > > > > > >> -----Ursprüngliche Nachricht----- > >> Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- > bounces@dfg- > >> viewer.de] Im Auftrag von Dr. Thomas Staecker > >> Gesendet: Montag, 23. Februar 2009 12:33 > >> An: dv-technik(a)dfg-viewer.de > >> Betreff: Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17- > >> Projekten > >> > >> Lieber Herr Meyer, liebe Kollegen, > >> > >> ich kann Ihrem Wunsch nach Einfachheit im Prinzip nur zustimmen. > >> Dennoch > >> beunruhigen mich Probleme wie die komplexeren Daten von Frau > >> Federbusch. Weniger für den Viewer, mehr für ein Harvesting. Nun > könnte > >> man zwar argumentieren, dass uns das für den Viewer nicht > interssiern > >> muss, jedoch prejudizieren wir durch bestimmte Kodierungen > >> Verfahrenswege, die aus meiner Sicht "unterflexibel" sind. Ich > möchte > >> daher noch einmal abstrakt rekapitulieren: Wir haben ein Tag für das > >> sozusagen Markup (=type) und ein Tag für den Content (=Label). > >> > >> Der ersten Fall ist der, dass in Type bisher die XML-Form der > >> Strukturdatenliste, z.B. title_page, in LABEL die Umsetzung, z.B. > >> Titelblatt, kodiert wird. Soweit so gut; theoretisch könnte man auch > >> Mehrsprachigkeit auf der Basis des type-Attributes, das ja > eigentlich > >> eine Ansetzungsform oder gleichsam Nummer ist, generieren. > >> Doch gibt es hier auch noch andere Kodierungsmöglichkeiten, die > nicht > >> im > >> engeren Konzept von Strukturdaten, wohl aber virtuellen > >> Inhaltsverzeichnissen bzw. -registern liegen, die ja auch dem hier > >> verfolgten Zweck der besseren Navigation dienen. > >> Z.B. wenn ich einen Personennamen (hier kommt eine bestimmte Person > >> vor) > >> im Sinne eines virtuellen Personennamenregisters anzeigen möchte, > wäre > >> analog eine Kodierung type=[PND-Nummer] Lable=Ansetzungsform zu > wählen. > >> In type selber muss dann aber, um Äquivokationen zu vermeiden, ein > >> Schlüssel mitgegeben werden, z.B. type="pnd_1234567". Entsprechend > wäre > >> es dann auch ratsam, die Strukturdatenliste - sie mag nun auch > >> HSS-Elemente enthalten oder nicht - mit structMD oder ählichem zu > >> versehen type="structMD_title_page". Wie gesagt, für die Anzeige, > die > >> sich aus dem LABEL Attribut speist (wenn denn Mehrsprachigkeit kein > >> Thema ist), ist das erst einmal nebensächlich, für das Harvesting > aber > >> zentral. > >> > >> Der andere Fall ist, dass das LABEL-Attribut echten Text-Content > >> enthält. Hier ist das Ignorieren des type Attributs auch unter > >> Viewergesichtspunkten problematisch. Z.B. findet sich eine > Überschrift, > >> type=structMD_chapter, und LABEL="Die schöne Melusine...". Da hier > nur > >> das Label ausgegeben und nicht weiter qualifiziert wird, sieht der > >> Nutzer nicht, worum es sich handelt. Ist diese eine Überschrift eine > >> Section, ein Kapitel, ein Titelblatt, eine Beischrift zu einer > >> Illustration, ein Kolophon etc. Unschön wird es, wenn sich Struktur > und > >> Inhaltsdaten mischen, also "Kapitel", capitula (in der Überschrift), > >> etc. In die selbe Kategorie gehört Volltext oder Teilen daraus. Will > >> der > >> Viewer Voll- oder Teiltranskriptionen zu etwa Handschriften nicht > mit > >> anzeigen, wenn sie denn vorliegen? Genau darauf zielte mein > Vorschlag, > >> es mit FContent zu versuchen. Herr Heiligenhaus hat den Sachverhalt > >> benannt: > >> > >> "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." > >> > >> aber noch nicht in diesem Sinne interpretiert. > >> > >> Mit einem schnellen Hüftschuss kommen wir sicher sofort zur Ver. 2, > >> verbauen uns aber möglicherweise weitere Entwicklungsmöglichkeiten, > >> deswegen wollte ich noch einmal nackhaken, ohne jetzt sicher zu > wissen, > >> was genau die Alternative wäre und ob wir das System nicht > hypertroph > >> machen. Zumindest ist es nicht unproblematisch die type-label > Struktur > >> für alle diese Aspekte verwenden zu wollen. > >> > >> Ein Trffen in Dresden würde ich sehr begrüßen. Bitte aber nicht vor > dem > >> 9.3. > >> > >> Viele Grüße, > >> Ihr > >> Th. Stäcker > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Meyer, Sebastian schrieb: > >>> Liebe Kollegen, > >>> > >>>> 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. > >>> Richtig, so sollte es sein. Darauf hatten wir uns auch zuletzt > >> geeinigt, ich habe es lediglich noch nicht umgesetzt. > >>> Ich würde die Sache allerdings nur ungern weiter verkomplizieren, > in > >> dem der Viewer künftig auch noch eine Vielzahl verschiedener > >> Strukturdatensets unterstützen soll. Das wäre aus meiner Sicht auch > >> nicht besonders zielführend: > >>> Wenn auch externe Strukturdatenlisten unterstützt werden sollen, > >> müsste erst wieder ein Standard geschaffen werden, wie solche Listen > >> auszusehen haben. Wir müssten uns auf Format und Übertragungsweg > >> einigen und auch wieder alle Eventualitäten beachten. Wie soll der > >> Viewer beispielsweise reagieren, wenn die Liste nicht erreichbar ist > >> oder in einem ungültigen Format vorliegt? > >>> Außerdem bedeuten extern gepflegte Listen, dass im Grunde jeder > sein > >> eigenes Strukturdatenset anfertigen und in den eigenen METS-Dateien > >> verlinken kann. Das würde zwar die Abstraktion des Viewers erhöhen, > >> umgekehrt aber auch jede Bemühung um ein standardisiertes > >> Strukturdatenset zunichte machen. > >>> Ich würde sogar so weit gehen, nicht einmal für verschiedene > >> Medientypen jeweils eigene Strukturdatensets zu pflegen, sondern nur > >> genau _ein_ Set zu unterstützen, dass jedoch passende Strukturdaten > für > >> verschiedene Medientypen enthält. Statt also für Handschriften ein > >> eigenes Strukturdatenset zu erstellen, würde ich lieber dem > vorhandenen > >> einige handschriften-spezifische Strukturdaten hinzufügen. (Zumal es > >> ohnehin eine Schnittmenge zwischen beiden Sets gäbe.) Das hätte den > >> Vorteil, dass der Viewer nicht auch noch vor der Darstellung der > >> Strukturdaten erst anhand irgendwelcher Kriterien eine Auswahl des > >> passenden Sets treffen müsste. > >>>> 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... > >>> Ja, ein Treffen fände ich auch prima. Meine ToDo-Liste für Version > >> 2.1 enthält noch einige weitere Punkte, die ich in den nächsten 1-2 > >> Wochen umsetzen werde. Anschließend würde sich ein weiteres Treffen > zur > >> Diskussion des Arbeitsstands und der nächsten Schritte anbieten. Ein > >> Termin in der zweiten Märzhälfte wäre mir sehr recht. Ich werde > einmal > >> schauen, wann hier entsprechende Räumlichkeiten frei wären und mache > >> dann auch konkretere Terminvorschläge. > >>> Viele Grüße > >>> Sebastian Meyer > >>> > >>> -- > >>> > >>> Sebastian Meyer > >>> Projekt-Mitarbeiter > >>> > >>> Sächsische Landesbibliothek - > >>> Staats- und Universitätsbibliothek Dresden (SLUB) > >>> 01054 Dresden > >>> Tel.: +49 351 4677-206 > >>> Fax: +49 351 4677-711 > >>> http://www.slub-dresden.de/ > >>> > >>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- > >> bounces@dfg- > >>>> viewer.de] Im Auftrag von Kay Heiligenhaus > >>>> Gesendet: Samstag, 21. Februar 2009 12:36 > >>>> An: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de > >>>> Betreff: Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und > VD17- > >>>> Projekten > >>>> > >>>> 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&metadataPrefix=mets&identifier=692944 > >>>> 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 > >>> > >> > >> -- > >> Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung) > >> Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel > >> Tel. +49(0)5331/808-119 - email: staecker(a)hab.de > >> > > > > > > > -- > Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung) > Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel > Tel. +49(0)5331/808-119 - email: staecker(a)hab.de >