DV-Technik April 2009

dv-technik@dfg-viewer.de

8 participants
25 discussions

Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) veröffentlicht

by Kay Heiligenhaus

Lieber Herr Meyer, > ich habe mir mein Beispiel noch einmal angeschaut, kann aber nichts > finden, was mich überraschen könnte. Können Sie mir auf die Sprünge > helfen? :) Ja, kann ich. Bei Übernahme der Daten aus dem SWB haben Sie hier kein Problem, das habe ich mir just noch mal genauer im BSZ-Verbundsystem angeschaut, wo man direkten Zugriff auf die zugrundeliegenden PICA-Daten Ihres Beispiels hat. Inwieweit das davon abhängt, daß Sie hier evtl. VD17-Daten nachnutzen (wo m.W. die Katalogisierung von mehrbändigen Werken etwas anders organisiert ist), kann ich nicht genau beurteilen. Bei Daten aus anderen Verbundsystemen (spontan fallen mir hier Daten ein, die wir aus dem HeBIS und dem hbz übernehmen) sieht die Sache anders aus (siehe das Beispiel aus Trier, die Daten stammen aus dem hbz). Nun habe ich mich doch noch im Regelwerk und den jeweils verbundspezifischen Katalogisierungsregeln verheddert - und wollte da überhaupt nicht hin. Man kann sich daran nämlich nur allzuschnell die Finger verbrennen. Als Ausweg bleibt mir hier nur, auf die Mapping-Regeln in der MODS-Spezifikation zu verweisen (s. http://dfg-viewer.de/fileadmin/groups/dfgviewer/MODS_Anwendungsprofil_1.0.p…). Hier wird konsequent zwischen MAB2- und GBV-PICA-Satzarten und deren Spezifika eingegangen, was einen Eindruck vermittelt, daß hier a) in diesen beiden "Welten" z.T. recht unterschiedliche Modelle zum Einsatz kommen sowie b) in der "PICA-Welt" feinsäuberlich zwischen GBV-PICA, SWB-PICA, HeBIS-PICA usw. zu unterscheiden ist. Was dann nach einem Umstieg auf MARC21 (in 2059?) der Fall sein wird, das können wir in Ruhe abwarten. ;) Das alles sollte den Viewer nicht interessieren. Von daher würde ich Ihnen nun folgen und sagen: der MODS-Datensatz des Bandes ist das, was der Viewer anzeigen sollte. Auch wenn man mich hier und da dafür steinigen wird. ;) Beste Grüße, Kay Heiligenhaus

16 years

Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) veröffentlicht

by Kay Heiligenhaus

Lieber Herr Meyer, > Das ist aber doch ein Problem, dem wir auch mit einer Konkretisierung > im Format nicht beikommen werden: der Viewer wird nie wissen, welche > dmdSec die aussagekräftigere für den Nutzer ist. Das würde ich so nicht sehen. Natürlich kann der Viewer nicht "wissen", welches die "aussagekräftigere" Beschreibung ist. Das ist aber eigentlich nicht der Punkt: bei mehrbändigen Werken ist _immer_ erst die Kombination aus bibliographischer Beschreibung des Bandes und bibliographischer Beschreibung der Gesamtheit aussagekräftig. Nehmen Sie zur Verdeutlichung einfach den Katalogeintrag Ihres eigenen Beispiels: http://dienste.slub-dresden.de/cgi-bin/FOZK.pl?PPN=27611342X Bevor ich mich hier aber in Regelwerksfragen verliere (und das auch noch bei diesem Themen) - hier sind eher die Katalogisierungsexperten gefordert, nicht so sehr die Techniker. > Er wird immer entweder die dmdSec des Bandes oder die des mehrbändigen Werks bevorzugen > (derzeit tut er letzteres, mein Vorschlag wäre, dass er ersteres tun > sollte), aber nie von Fall zu Fall unterschiedlich entscheiden können. > Zu Ihrem Beispiel wird es genauso ein Gegenbeispiel geben, bei dem es > für den Nutzer verwirrend wäre, bei der Betrachtung des Bandes den > Titel des mehrbändigen Werks statt des Bandtitels angezeigt zu bekommen > (und genau das wäre bei der derzeitigen Implementierung der Fall). Wie gesagt, das ist nicht mein Ziel. Aber ich würde Ihnen folgen, ersteres zu tun (der Nutzer kann ja immer "nach oben" navigieren, um die bibliographische Beschreibung der Gesamtheit einzusehen). Sie sollten sich zuvor aber noch die eigenen Beispiele näher anschauen, bevor Sie selbst überrascht sind, was dann hinten rauskommen wird... ;) Beste Grüße, Kay Heiligenhaus

16 years

Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) veröffentlicht

by Kay Heiligenhaus

Lieber Herr Meyer, > Genau diese beiden Fälle sollten doch mit dem in meiner anderen Mail > vorgeschlagenen Ansatz korrekt funktionieren. In Pseudo-Code sähe es > etwa so aus: > > 1. Prüfe, ob das oberste DIV-Element der logischen Struktur, das in der > structLink-Sektion berücksichtigt wird (mit dem also physische > Strukturen verknüpft sind), DMDID- und ADMID-Attribute enthält. > > 2a. Wenn ja, dann verwende diese. > > 2b. Wenn nein (oder nur eins von beidem), dann suche die noch fehlenden > Angaben im obersten DIV-Element der logischen Struktur. > > Damit sollten in meinem Beispiel korrekt die DMDID und ADMID des Bandes > gefunden werden und in Ihrem Beispiel würde die DMDID des Bandes und > die ADMID der Zeitschrift verwendet werden. Vollkommen richtig. Das funktioniert mit Ihrer Änderung von gestern bereits jetzt vollkommen korrekt. Das Problem sehe ich eher bei der Darstellung der bibliographischen Daten mehrbändiger Werke. Die sind in den verschiedenen Katalogsystemen, mit denen wir hier in Deutschland zu tun haben, erst dann korrekt darstellbar, wenn sowohl eine dmdSec für den Band wie für die Gesamtheit geliefert wird... Beste Grüße, Kay Heiligenhaus

16 years

Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) veröffentlicht

by Kay Heiligenhaus

Lieber Herr Barth, > ich dachte immer, das sei das erste <div>, das eine DMDID hat - > darunter nur untergeordnete, darüber nur übergeordnete <div's> Ja, das hat Herr Meyer heute aber noch mal weiter präzisiert: > meine gestrige Lösung durchsucht schlicht die logischen DIV-Elemente > von oben nach unten und verwendet die ersten DMDID- und ADMID-Werte, > die gefunden werden. Der alternative Lösungsvorschlag sucht aber primär > im obersten DIV, mit dem physische Strukturen verknüpft sind (was nicht > zwingend gleichzeitig das oberste DIV der logischen Struktur sein > muss). Nur so würden die DMDID und ADMID eines Bandes auch dann > berücksichtigt werden, wenn bereits die (übergeordnete) Gesamtheit > DMDID- und ADMID-Attribute besitzt. Das halte ich - jenseits der Fragen der "Vollständigkeit" der jeweiligen dmdSecs - für eine gute Lösung. Beste Grüße, Kay Heiligenhaus

16 years

Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) veröffentlicht

by Kay Heiligenhaus

Hallo Herr Enders, > An dieser Stelle waere es wichtig den allgemeinen Zweck des METS > Profils zu klaeren. Ist es eher eine Anleitung, um METS Dateien, die > nach diesem Schema produziert wurden zu verstehen oder ist das Profil > nicht vielmehr auch als Implementierungsanweisung gedacht? Ich würde es eher als Implementierungsanleitung verstehen, eine narrative Umschreibung zum besseren Verständnis von METS-Dateien, die der freien Inspiration von Entwicklern erwachsen, hätte m.E. nur einen begrenzten Wert bei der Verfolgung der zuvor beschriebenen Zwecke ("Standardisierung zur einheitlichen Anzeige von Digitalisaten verschiedener DFG-geförderter Projekte"). ;) > Wenn letzteres, so fehlt an vielen Stellen eine Aussage ueber die > Verbindlichkeit von Sektionen - kann, soll, muss darf ruhig haeufiger > in dem Dokument auftauchen ;-) Wenn ich das Profil querlese faellt mir > auf, dass wenn immer etwas als optional gemeint ist, dies mit dem Wort > "kann" oder "koennte" auch so beschrieben wird. Verpflichtende Teile > werden jedoch nicht als "muss" beschrieben, sondern eher all allgemeine > Beschreibung Dem kann ich mich nur anschließen. > Das ist in der Tat sehr missverstaendlich. Zumal sie darueber streiten > liesse, ob diese Information in die structMap Anforderung oder in die > amdSec Anforderung 2: "Metadaten zu Herkunft und Online-Präsentation" > sollte. Sie gehört m.E. in beide. In Anforderung 2 müßte der grundsätzliche Ansatz beschrieben sein, unter den Anforderungen für die structMap dann die Konkretisierung für verschiedene Anwendungsfälle, die - so interpretiere ich den Angang des Profils - je nach "Dokumenttyp" (den es aber leider formal hier nicht gibt, s.u.) unterschiedlich sein werden. > Ferner ist unklar, ob ein eine amdSec von mehreren <div>s benutzt > werden darf oder gar muss. IMHO muss nur das oberste logische <div> > welches mit einem physischen <div> Element verknuepft ist eine amdSec > zugeordnet bekommen. Das waere also die Monographie, der Band, oder der > Zeitschriftenband. Das sehe ich anders, zumindest scheint mir das Profil hier einen anderen Angang zu wählen, den ich - offen gesagt - aber auch noch etwas unausgegoren finde, wenn ich auch ad hoc keinen besseren vorschlagen könnte: a) Bände von Zeitschriften und b) Bände von mehrbändigen Werken wären hier unterschiedlich zu implementieren. Bei a) müßte die ADMID an der Zeitschrift hängen (diese hat ein korrespondierendes Katalogisat zur Anzeige), bei b) am konkreten Band (dieser hat ein korrespondierendes Katalogisat zur Anzeige). Nun kommt man aber ins Schleudern, denn die bibliographische Beschreibung, die anzuzeigen wäre, setzt sich letztlich aus den Metadaten zusammen, die beide "Ebenen" zusammen erst ergeben ("Ich bin Bd. 10 des mehrbändigen Werkes X" sowie "Ich bin Jg. 3 der Zeitschrift Y). Das kann man aber gut auch anders sehen (aber man kommt dann schnell ins Weiterschleudern, wenn man größere Hierarchiestufen betrachtet). Lassen Sie uns das also konkretisieren: Herr Meyer hat hier vor einiger Zeit ein Beispiel geposted, das er wohl auch zur Implementierung des Viewers verwendet hat: http://digital.slub-dresden.de/Band.xml Hier besitzt die Überordnung (mehrbändiges Werk) keine DMDID und ADMID (samt korrespondierender dmdSec und amdSec), nur der Band hat solche. Das ist konsequent gedacht, funktioniert aber bei Zeitschriften nicht recht. Dazu ein Beispiel aus einem unserer Anwendungskontexte: http://www.dilibri.de/oai/?verb=GetRecord&metadataPrefix=mets&identifier=57… Hier besitzt die Überordnung (Zeitschrift) DMD und ADMID (samt korrespondierender dmdSec und amdSec), der Band hat "nur" eine DMDID (samt korrespondierender dmdSec). > Ich denke, dass dies auch ein Problem der typen-unabhaengigen > Implementierung ist. Ja, die "Dokumenttypen" sind ein echtes Desiderat des Profils, auch wenn diese im Profil stillschweigend hier und da vorkommen. > Der DFG-Viewer nutzt m.W. ja den Wert des TYPE > Attributes eines <div> Elements nicht, um entsprechend die Anzeige etc. > zu steuern. Daher sind solche Feinheiten auch im Profil nicht geregelt. > Bei Ihnen geht es ja ueberhaupt um die Frage, welche URLs in das > Element <dv:reference> und <dv:presentation> eingetragen werden sollen. So ist es. > Prinzipiell natuerlich die URL, die zu dem jeweiligen <div> gehoert. > Wenn das <div> der Band ist, dann gehoert in <dv:reference> natuerlich > die URL des Katalogisat des Bandes. Wenn der Band kein Katalogisat hat, > muss diese URL entfallen. D.h. die beiden Elemente <dv:reference> und > <dv:presentation> waeren nur mandatory, if applicable. Yep, so ist das für Zeitschriften. > In dem Fall dass das oberste logische <div> Element kein Katalogisat > hat, koennte der DFG-Viewer einen Link fuer das Katalogisat des > uebergeordneten <div> Elements praesentieren. D.h. dass die Zeitschrift > immer eine <amdSec> besitzen muss - sowohl in der METS Datei der > Zeitschrift als auch in der METS Datei des Bandes. Und nun sind wir in der Misere: Was soll eigentlich das oberste logische DIV sein? Und was wird im Viewer angezeigt, wenn das oberste DIV mal dazu dient, eine Navigation von "unten nach oben" zu ermöglichen (Band -> Zeitschrift, die Digitalisate des Bandes werden angezeigt) und mal dazu, eine Navigation von "oben nach unten" zu ermöglichen (Zeitschrift -> Bände, es wird kein Digitalisat angezeigt, da die Zeitschrift keine unmittelbaren hat)? Vor allem, wie halte ich diese Fälle formal hinreichend auseinander? Beste Grüße, Kay Heiligenhaus

16 years

Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) veröffentlicht

by Kay Heiligenhaus

Lieber Herr Meyer, > meine gestrige Lösung durchsucht schlicht die logischen DIV-Elemente > von oben nach unten und verwendet die ersten DMDID- und ADMID-Werte, > die gefunden werden. Der alternative Lösungsvorschlag sucht aber primär > im obersten DIV, mit dem physische Strukturen verknüpft sind (was nicht > zwingend gleichzeitig das oberste DIV der logischen Struktur sein > muss). Nur so würden die DMDID und ADMID eines Bandes auch dann > berücksichtigt werden, wenn bereits die (übergeordnete) Gesamtheit > DMDID- und ADMID-Attribute besitzt. > > Die Angabe "Ich bin Band 4 des mehrbändigen Werks 'Gesammelte Werke'" > ist doch bereits jetzt verfügbar: dass es sich um Band 4 handelt, wird > der dmdSec des Bandes entnommen, und dass die übergeordnete Einheit > "Gesammelte Werke" heißt, steht im LABEL des logischen DIVs der > Gesamtheit. Nehmen wir wieder ein konkretes Beispiel (Band eines mehrbändigen Werkes): http://www.dilibri.de/oai/?verb=GetRecord&metadataPrefix=mets&identifier=13… Wie Sie sehen: Die bibliographischen Daten des Bandes sind ausgesprochen "rudimentär". Die "eigentlichen" bibliographischen Daten stehen in der dmdSec der Überordnung (die Bibliothekare unter uns mögen mir die Ausdrucksweise nachsehen). Von daher würde Ihr Vorschlag hier zu einer Darstellung der bibliographischen Daten führen, die für den Nutzer eher verwirrend wäre. Beste Grüße, Kay Heiligenhaus

16 years

Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) veröffentlicht

by Kay Heiligenhaus

Hallo Herr Kothe, > für einen Bibliothekar und einen OPAC und eine Karteikasten mag das > sinnvoll und nachvollziebar sein - für eine allumfassende Darstellung von > digitalen Sammlungen in digtaler Weise ist schlicht aber ergreifend ein Ansetzung > falsch. Was ist denn an dieser Darstellung von Zeitschriften im Viewer so "undigital"? Zeitschrift: http://dfg-viewer.de/demo/viewer/?set%5Bimage%5D=1&set%5Bzoom%5D=default&se… Jahrgang: http://dfg-viewer.de/demo/viewer/?set%5Bmets%5D=http%3A%2F%2Fwww.dilibri.de… Beste Grüße, Kay Heiligenhaus

16 years

Re: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) veröffentlicht

by Kay Heiligenhaus

Lieber Herr Meyer, liebe Kolleginnen und Kollegen, kurz noch zum gestern berichteten Problem bei der METS-Interpretation der METS-Daten des VD17-Projektes der ULB Sachsen-Anhalt: Dies sind nun durch einen beherzten Eingriff von Herrn Meyer behoben. Vielen Dank noch einmal an dieser Stelle für den konstruktiven Austausch, den wir dazu heute und gestern per PM hatten und die schnelle Lösung des Problems! Hintergrund war hier, daß es einige Fallstricke bei der Interpretation der Verwendung von METS-Pointern gibt, die der formalen Darstellung "mehrteiliger Werke" (also vor allem Periodika und mehrbändige Werke) dienen, aber ebenfalls einen Seiteneffekt bei unserer Abbildung von Monographien hatten. Herr Meyer und ich haben im Nachgang unseres Austauschs zwei offene Punkte auf der Agenda, die unserer Ansicht nach in größerer zu diskutieren sind: 1) Releasepolitik zukünftiger Versionen des DFG-Viewers. 2) Spezifikation der Nutzung von METS-Pointern zur Abbildung "mehrteiliger Werke". Zu 1) Der DFG-Viewer erfreut sich inzwischen ja einer recht großen Beliebtheit. Mit der Verabschiedung der aktuellen Fassung der "DFG-Praxisregeln" im April 2009 erhält er nun auch einen "offiziellen Status" bei der Umsetzung von Digitalisierungsprojekten, die von der DFG gefördert werden (s. http://www.dfg.de/forschungsfoerderung/wissenschaftliche_infrastruktur/lis/…). Unter Punkt "4.2.2 Funktionalitätsanforderungen" wird hier ausgeführt: "Aus zentralen DFG-geförderten Informationssystemen (VD16, VD17, Fachportalen etc.) sollte zuerst auf eine Ansicht im Style "DFG-Viewer" verlinkt werden." Mit Punkt "5. Präsentationsstandards ("DFG-Viewer") und Formate (METS/MODS)" wird der Hintergrund dieser Anforderung deutlich: "Um für die wissenschaftlichen Nutzer neben den unterschiedlich gestalteten und dezentral verantworteten Webangeboten der jeweiligen Einrichtungen einen einheitlichen Zugriff auf die Daten (Inhalte) aller DFG-geförderter digitalisierter Drucke bieten zu können, werden derzeit zwei sich ergänzende Strategien verfolgt". Ich persönlich bevorzuge stark die zentrale Variante der Nutzung des Viewer-Dienstes, da aus meiner Sicht ein lokaler Betrieb zu unnötiger Doppelpflege der Systeme führt. Die Nutzung eines zentralen Services setzt aber ein stabiles Betriebs- und Release-Management voraus, da ein Ausfall oder eine Störung des zentralen Services unmittelbar auf den Nutzer durchschlägt: Er gelangt aus dem OPAC, dem Verbundsystem, dem VD16/17 usw. usf. nicht mehr auf die entsprechenden Digitalisate, sondern auf eine mehr oder weniger erquickliche Fehlermeldung. Schlußfolgerung muß hier deshalb sein, daß zukünftig Updates des Service zunächst im Rahmen eines öffentlichen Beta- oder RC-Testes durchzuführen und hier auf der Liste anzukündigen sind. Nur so sind Inkompatibilitäten frühzeitig zu erkennen und (gleich auf welcher Seite) zu beheben. Zu 2) Die Darstellung von "mehrteiligen Werken" (Periodika und mehrbändige Werke) werden im METS-Profil unter Beispiel 11 behandelt (s. http://dfg-viewer.de/fileadmin/groups/dfgviewer/METS_Anwendungsprofil_2.0.p…). Leider schweigt sich das Profil, soweit ich das sehe, über das Vorhandensein von ADMIDs in der logischen structMap aus, die für die Katalogreferenzen sowie die Darstellung der Icons der digitalisierenden Einrichtung usw. notwendig sind. Hier sind Unterschiede zwischen Bänden eines Mehrbändigen Werkes (die über eigenständige Katalogeinträge verfügen) und Bänden einer Zeitschrift (die nicht über eigenständige Katalogeinträge verfügen) zu berücksichtigen. In der Weiterung wären unselbständige Teile eines mehrbändigen Werkes (Aufsätze, ...) zu berücksichtigen, die wiederum über eigenständige Katalogisate verfügen können. Dies alles hat unmittelbare Auswirkungen auf die Darstellung im DFG-Viewer, denn im Falle eines Bandes eines Mehrbändigen Werkes sind die bibliographischen Daten des Bandes anzuzeigen und auf dessen Katalogeintrag zu verlinken, im Falles eines Bandes einer Zeitschrift sind die bibliographischen Daten der Zeitschrift anzuzeigen und auf deren Katalogeintrag zu verlinken usw. In dieser Hinsicht ergibt sich unserer Ansicht nach ein gewisser Präzisierungsbedarf im METS-Profil sowie bei der Umsetzung der Darstellung im Viewer. Ich hoffe, ich habe die Zusammenhänge soweit richtig dargestellt und würde mich über Kommentare aus dem Kreise freuen, insbesondere hinsichtlich der Formatspezifikation. Beste Grüße, Kay Heiligenhaus > -----Original Message----- > From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg- > viewer.de] On Behalf Of Kay Heiligenhaus > Sent: Monday, April 20, 2009 5:15 PM > To: technik(a)dfg-viewer.de > Subject: Re: [DFG-Viewer]DFG-Viewer v2.5 (release candidate 1) > veröffentlicht > > Lieber Herr Meyer, > > mit dem Release scheint auch die Schnittstelle zum Ponickau-Projekt der > ULB Sachsen-Anhalt gebrochen zu sein: > > http://dfg- > viewer.de/demo/viewer/?set[mets]=http%3A%2F%2Fdigitale.bibliothek.uni- > halle.de%2Foai%3Fverb%3DGetRecord%26metadataPrefix%3Dmets%26identifier% > 3D94835 > > Ich kann allerdings auf Anhieb keinen Fehler im METS-Format erkennen, > zudem wir seit Umstellung auf die Nutzung der Version 2 des Viewers > Anfang Februar keine Änderungen gemacht haben: > > http://digitale.bibliothek.uni- > halle.de/oai?verb=GetRecord&metadataPrefix=mets&identifier=94835 > > Die Fehlermeldung, die der Viewer liefert, ist hier wenig > aussagekräftig: > > Could not find DMDID and/or ADMID. > > Könnten Sie mir auf die Sprünge helfen? > > Beste Grüße, > Kay Heiligenhaus > > p.s. Es wäre m.E. sehr ratsam, einen RC1 nicht direkt in Produktion zu > übernehmen. Wir nutzen den DFG-Viewer in Halle abstimmungsgemäß ja zur > primären Anzeige aus lokalem OPAC, GBV und VD17. Da führt eine so > plötzliche Umstellung schnell dazu, daß nun 10.000 Titel der ULB nicht > mehr erreichbar sind im Netz... > > > -----Original Message----- > > From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- > bounces@dfg- > > viewer.de] On Behalf Of Meyer, Sebastian > > Sent: Monday, April 20, 2009 4:57 PM > > To: technik(a)dfg-viewer.de; support(a)dfg-viewer.de > > Subject: [DFG-Viewer] DFG-Viewer v2.5 (release candidate 1) > > veröffentlicht > > > > Liebe KollegInnen, > > > > die nächste Version des DFG-Viewers ist nun beinahe fertiggestellt. > Zu > > den Neuerungen gehören: > > > > - Es gibt keine Unterscheidung mehr zwischen v1 und v2. Egal ob Sie > > "METS light" oder vollwertiges METS erzeugen und egal ob Sie > > Strukturdaten erfassen oder nicht, Sie müssen sich keine Gedanken > mehr > > darum machen, welche Version des DFG-Viewers Sie verlinken müssen. Es > > gibt nur noch eine Version, die mit allen METS-Formaten zurechtkommt. > > Den DFG-Viewer erreichen Sie daher künftig auch einheitlich unter der > > URL http://dfg-viewer.de/show/. (Aus Gründen der > Abwärtskompatibilität > > bleiben die Links http://dfg-viewer.de/v1/ und http://dfg- > viewer.de/v2/ > > weiterhin gültig.) > > > > - Im Zuge der Vereinheitlichung beherrscht nun auch der Demonstrator > > den Umgang mit Strukturdaten. > > > > - Neben den persistenten Identifiern auf Werkebene werden nun auch > die > > persistenten Identifier auf Seitenebene angezeigt, sofern sie im > Format > > (im Attribut CONTENTIDS) hinterlegt sind. Die Identifier auf > Werkebene > > werden der MODS-Sektion entnommen. Derzeit werden PURL, URN und > > VD16/17-Nummer berücksichtigt (letztere aber noch nicht korrekt > > verlinkt, das wird aber im Laufe der Woche noch korrigiert). > > > > - Sie können ein konkretes Image nun nicht mehr nur über die > > Imagenummer referenzieren, sondern dem Parameter set[image] wahlweise > > auch die ID eines physischen DIVs vom Typ "page" übergeben. (Das soll > > die gezielte Verlinkung von Strukturdaten aus ZVDD erleichtern.) > > > > - In der Werknavigation wird nun die Rootline zum aktuellen > > Strukturelement hervorgehoben dargestellt. Dadurch sieht man auf den > > ersten Blick, an welcher Stelle im Werk man sich gerade befindet. > > Außerdem wurde die mögliche Hierarchietiefe auf fünf Ebenen erhöht. > > (Tatsächlich sind beliebig tiefe Hierarchien möglich, alle Ebenen > > unterhalb der fünften werden aber nicht mehr tiefer eingerückt > > dargestellt.) > > > > - Die Übersetzung der im Strukturdatenset festgelegten Strukturen ist > > nun ebenfalls umgesetzt. Der Sprachumschalter verbirgt sich oben > rechts > > unter den beiden Landesflaggen. > > > > - Die Verlinkung von Download-Varianten des Gesamtwerks in den > > logischen Strukturdaten wird nun ebenfalls berücksichtigt. Sind > sowohl > > in der physischen wie in der logischen Struktur Download-Varianten > > hinterlegt, wird die Variante aus der logischen Struktur verlinkt (da > > diese potentiell selbst die logische Werknavigation enthält und nicht > > nur eine Abfolge von Images ist). > > > > Ich würde Sie nun bitten, die neue Version eingehend zu testen und > mir > > auftretende Fehler zu melden. Beispiele finden Sie auf der Seite des > > Demonstrators (http://dfg-viewer.de/demo/) - Strukturdaten liefert > > beispielsweise die SUB Göttingen. (Die METS-Schnittstelle der BSB > > scheint derzeit nicht zu funktionieren.) > > > > In den nächsten Tagen werde ich auch noch den Validator voll in den > > Viewer integrieren und im Zuge dessen die Fehlermeldungen > überarbeiten, > > um sie aussagekräftiger zu gestalten. Außerdem wird es ein Update der > > Dokumentation und Webseite geben. > > > > 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/ > > > > >

16 years

UserAgent beim METS-Request

by Dirk Rothe

Lieber Herr Meyer, es wäre sehr praktisch, wenn der DFG-Viewer beim Abholen der METS-Daten einen User-Agent[1] im Request-Header mitschicken würde. Zur Zeit schickt er einen Leerstring bzw. gar keinen - das habe ich aber ehrlich gesagt nicht weiter überprüft. Üblicherweise sollte man dann auch die Version des Clients (also des Viewer-Services) darin unterbringen. Der Hintergrund ist, dass wir die Viewer-Anfragen dann expliziter als Bot-Anfragen behandeln können. Auf unserer Seite spart das dann ein paar überflüssige Routinen, die nur für Browser relevant sind. Und das Identifizieren via UA ist auch unter "good citizen" Gesichtpunkten zu empfehlen. Beste Grüße, Dirk Rothe [1] http://en.wikipedia.org/wiki/User_agent

16 years

Antw: Re: Viewer: METS-XML: Schwierigkeiten beimInterpretieren der Dateien?

by Petra Schröder

Lieber Herr Meyer, vielen Dank. Jetzt funktioniert es. Die Download-Funktion ist aber noch nicht implementiert? Viele Grüße Petra Schröder >>> "Meyer, Sebastian" <smeyer(a)slub-dresden.de> 21.04.09 11.29 Uhr >>> Liebe Frau Schröder, Sie haben in der physischen Struktur keine IDs für die DIVs vom Typ "page" vergeben. Der Viewer benötigt jedoch für jedes DIV-Element eine eindeutige ID, um diese unterscheiden und ansprechen zu können. 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 Petra Schröder > Gesendet: Dienstag, 21. April 2009 11:12 > An: dv-technik(a)dfg-viewer.de > Betreff: [DFG-Viewer] Viewer: METS-XML: Schwierigkeiten beim > Interpretieren der Dateien? > > Liebe Kollegen, > > bislang ließ sich unser Demo-Objekt einwandfrei im Viewer anzeigen: > http://dfg-viewer.de/v1/?set[mets]=http%3A%2F%2Fbvbm1.bib- > bvb.de%2Fourmets.xml > > Zur Zeit werden die Bilder allerdings nicht angezeigt. Stattdessen > erscheint die Meldung:"Das Bild scheint nicht erreichbar zu sein." > Wurde etwas umgestellt? > > Mit besten Grüßen > Petra Schröder > > > ------------------------------------------- > Dr. Petra Schröder > Bayerische Staatsbibliothek > Bibliotheksverbund Bayern / Verbundzentrale > Virtuelle Bibliothek Bayern > > Tel.: (089) 28638-2221 > Tel.: (09405) 956-821 (an Telearbeitstagen) > > E-Mail: Petra.Schroeder(a)bsb-muenchen.de

16 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

DV-Technik April 2009