DV-Technik February 2009

dv-technik@dfg-viewer.de

4 participants
14 discussions

by Thomas Stäcker

...auch noch einmal zum Regelwerk eine Nachfrage. Wir haben das Feld <originInfo>/<dateIssued> in der MODS Sektion als Pflichfeld deklariert. Wie behandeln wir den Fall, wenn es kein Jahr in der Quelle gibt? Soll das in a) Pflicht, wenn vh. geändert werden b) leer bleiben <dateIssued/> c) explizit als nicht vh. charakterisiert werden <originInfo>/<dateIssued>ohne Jahr Viele Grüße, Ihr Th. Stäcker

15 years, 2 months

Frage zu Validierung

by Thomas Stäcker

Lieber Herr Meyer, liebe Kollegen, können Sie mir in einer Sache helfen. Ich habe beigefügte Datei dem Validator übergeben. Er hat folgende <mets:structLink> <mets:smLink xlink:to="physMD_586140484" xlink:from="logMD_586140484"/> </mets:structLink> beanstandet als Fehler in der strukturellen Integrität des Dokuments [1] *Fehler!* Das 1. smLink Element des structLink Blocks verweist im Attribut xlink:to nicht auf eine gültige div Sektion structMap vom TYPE PHYSICAL. bzw, TYPE LOGICAL Da die ZuordnungsIDs vorhanden sind, ist mir nicht klar, was der Parser hier moniert. Können Sie mir helfen? Habe ich Tomaten auf den Augen? Dann auch noch einmal explizit die Frage (nur noch einmal zur Selbstvergewisserung): Die Verlinkungsrichtung ist die von LOGICAL auf PHYSICAL? Theoretisch kann es ja auch andersherum sein, je nachdem, ob man einer Seite Daten oder Daten einer Seite zuordnet bzw. ob man eher ein eBind oder TEI Konzept verfolgt. Oder stellen wir das frei? Viele Grüße und Dank im voraus, Ihr Th. Stäcker

15 years, 2 months

Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17-Projekten

by Kay Heiligenhaus

Liebe Frau Federbusch, > Ich denke, man sollte es nicht ganz so schwarz-weiß malen. Das finde ich auch immer gut. > Immerhin haben wir mit der ZVDD-Liste ja bereits ein weiteres Strukturdatenset > ... und nun gilt es, maßvoll mit den Möglichkeiten umzugehen. Auch > halte ich es für die Akzeptanz von Strukturdatentypologien für > günstiger, nicht auch noch Strukturen der Medientypen zu vermengen, da > auch die Beziehungen zwischen den Strukturen von Bedeutung sind und > sich mit einer Typologie für z.B. Handschriften ein klareres Bild > ergibt als wenn alles in einem Topf schwimmt. Das lese ich nun aber als Plädoyer für die Nutzung der vorhandenen Typologie für Druckwerke sowie der Entwicklung (mindestens einer weiteren) für z.B. Handschriften. Verstehe ich Sie da richtig? Beste Grüße, Kay Heiligenhaus

15 years, 2 months

Re: [DFG-Viewer] Nochmal zum Validator

by Kay Heiligenhaus

Lieber Herr Stäcker, > wenn ich recht sehe, geht es doch nur um Kleinkram, den man problemlos > noch in die Datei bringen kann (smLinks). Entscheidend ist, dass es > valide durchläuft, sprich METS valide ist. So hatte ich Herrn Meyer > verstanden. Ja, es geht letztlich um Kleinkram. Aber an dem scheiden sich ja zuweilen die Geister. ;) Gegenüber dem METS-Schema der LoC sind beide Varianten, die wir bislang auf den Viewer-Seiten dokumentiert haben, valide. Auch gehe ich davon aus, daß sich nach und nach eher das erweiterte Profil durchsetzen wird, da es einen deutlich erweiterten Ausdrucksraum besitzt. Institutionen tun also gut daran, direkt diese Variante zu implementieren. Was m.E. jedoch wichtig ist: wir haben für die Version 1 des Viewers beschlossen, daß "METS light" unterstützt wird. Wenn man sich im Netz so umschaut, hat das recht schnell zu einer breiteren Akzeptanz des Formates in den Communities geführt. Damit sollte man m.E. nicht ohne Not brechen, sondern das in der Dokumentation auf den Viewer-Seiten nur entsprechend deutlich machen. > Im Übrigen hat der UA der DFG formal bislang kein in einem Schema > abbildbares Applikation Profile beschlossen, sondern nur die gleichsam > generische METS Kompatibilität plus eine Beschreibung, was in den MODS > Feldern minimal stehen sollte. Da bin ich mal gespannt auf die genaue Formulierung. METS kann alles mögliche sein. Erst mit einem echten AP wird daraus etwas, was man wirklich sinnvoll nutzen kann. > Kurz- bis Mittelfristig sollte sich das ändern, indem z.B. von Seiten > der DFG Schemata vorgegeben werden. Für diesen Zweck müsste auch die > Community noch etwas Finetuning übernehmen, z.B. ist m.E. der dv- > Bereich noch nicht abschliessend diskutiert (was ist verbindlich, z.B. > emailadresse oder eine lokale Homepage?). Aber es sieht mit den > vorhandenen Schema-Dateien schon ganz gut aus und wir rücken ja > minütlich ein Stück weiter an ein AP für den Viewer heran ;-) So ist es. Allerdings sehe ich die Diskussion für Vers. 2.0 des Viewers eigentlich schon als abgeschlossen an. Es geht mir hier also nicht um Erweiterungen, die über da bereits beschlossene und implementierte hinausgehen, sondern um einige Implementierungsdetails auf Seiten des Viewers (Layoutbugs, Anzeige der Seitenidentifier (sofern vorhanden), Anzeige von bibliographischen Nachweisen (sofern vorhanden)), die m.E. für eine Version 2.x noch zu leisten sind. Dazu kommen dann Details der Dokumentation, die hier im Kern den Validator betreffen. Funktionale Erweiterungen sehe ich eher einer Version 3.0 vorbehalten. Beste Grüße, kay Heiligenhaus

15 years, 2 months

Re: [DFG-Viewer] Nochmal zum Validator

by Kay Heiligenhaus

Lieber Herr Meyer, > ja, da rächt es sich nun, dass wir dieses elende METS light > unterstützen... Nur um eine structLink-Sektion mit einem einzigen > smLink-Eintrag und eine structMap-Sektion mit einem einzigen logischen > Eintrag einzusparen, müssen wir nun an zig Stellen Sonderbehandlungen > einbauen. Ich bin ja nach wie vor der Meinung, dass diese zwei Zeilen > XML die Sache auch nicht unzumutbar kompliziert gemacht, uns dafür aber > technisch sauberes METS beschert hätten. Hm, das sehe ich nicht so. "Sauber" ist das "METS light" auch. Es entspricht sogar eher den Implementierungen, die ich im METS-Umfeld so kennen. > Der Validator kann METS light nicht validieren, Version 2.0 des Viewers > kann es nicht anzeigen, die Beispiele und Dokumentation sorgen mit > Ausnahmen und Sonderregeln für Verwirrung und der Anwender glaubt METS > zu erzeugen, das in Wahrheit aber kein valides METS ist (und deshalb > ausschließlich im Kontext des Viewers brauchbar ist). Das stimmt so nicht. Der Validator zeigt beim "METS light" ja nun auch an, daß es sich um valides METS handelt. Er bemängelt nur, daß keine smLinks usw. vorhanden sind. > Und das führt dann letztlich zu solchen Trugschlüssen wie denen von Herrn Graf und > dem Kommentator Markus. > Natürlich kann (und werde) ich nun einen Hinweis beim Validator > anbringen, dass dieser sich nicht für METS light eignet, letztlich wird > das die Verwirrung aber eher noch vergrößern. Die Verwirrung entsteht aktuell aus den Diskrepanzen zwischen Dokumentation und Implementierung. > Der DFG-Unterausschuss für Kulturelle Überlieferung hat vor anderthalb > Wochen die Verabschiedung des Praxisregel-Entwurfs beschlossen. Damit > wird es nun also langsam wirklich ernst für den Viewer. Meiner Meinung > nach sollten wir die letzte Gelegenheit nutzen und die offizielle > Unterstützung von METS light wieder einstellen. Inoffiziell kann der > Viewer es ja auch weiterhin interpretieren, damit Anwender wie die BSB > nicht schon wieder ihr Format umstellen müssen, aber es sollte eben > nirgendwo mehr dokumentiert oder validiert werden. Künftige Anwender > würden dann gleich echtes METS erzeugen, wovon letztlich beide Seiten > nur profitieren. Wenn er die Entwurfsfassung beschlossen hat, dann hat er "METS light" beschlossen. Ein Grund mehr, dem Validator beizubringen, daß er das Format auch interpretieren kann. So schwer ist das m.E. nicht. Beste Grüße, Kay Heiligenhaus > > 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: Sonntag, 22. Februar 2009 12:26 > > An: dv-technik(a)dfg-viewer.de > > Betreff: [DFG-Viewer] Nochmal zum Validator > > > > Lieber Herr Meyer, > > > > ich habe gesehen, daß Sie nun den Validator auf den Viewer-Seiten > aktiv > > geschaltet haben: > > > > http://dfg-viewer.de/profil-der-metadaten/validator/ > > > > Leider wird der Nutzer an keiner Stelle darauf hingewiesen, daß der > > Validator keine METS/MODS-Dateien der Version 1 (Light-Profil) > > validieren kann, obgleich unsere eigenen Beispiele auf den Viewer- > > Seiten diesem Schema folgen. Wohin das führt, konnte vor kurzem die > BSB > > am eigenen Leibe erfahren: > > > > http://archiv.twoday.net/stories/5525850/ > > > > Im Kommentar vom 19.2. heißt es: > > > > "In dem angegebenen Link zum DFG-Viewer muss die URL, die zur METS > > Datei fuehrt encoded werden. > > Der derzeitige Link gibt lediglich eine Fehlermeldung des DFG-Viewers > > aus; die METS Datei der BSB wird nichtmal geladen. > > > > http://dfg-viewer.de/v1/?set%5Bmets%5D=http%3A%2F%2Fmdz10.bib- > > bvb.de%2F%7Edb%2Fmets%2Fbsb00025408_mets.xml > > > > waere die richtige URL - die allerdings auch nicht funktioniert, da > die > > METS Datei nicht den Spezifikationen des DFG Viewers entspricht." > > > > Die BSB-METS-Datei entspricht sehr wohl den Vorgaben des DFG-Viewers > im > > Light-Profil (wie übrigens fast alle mir bisher bekannten Umsetzungen > > der Viewer-Anforderungen an zig Standorten). Das Problem steckt hier > > woanders (nämlich darin, daß die Image-URLs nicht mehr gültig sind). > > Man sieht aber an diesem Beispiel, wie schnell aus solchen > technischen > > Wirrnissen Anwürfe generalisierender Art werden: "BSB missachtet ihre > > Pflichten gegenüber der DFG". Das kann nicht im Interesse der > Community > > sein... > > > > Beste Grüße, > > Kay Heiligenhaus >

15 years, 2 months

Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17-Projekten

by Kay Heiligenhaus

Lieber Herr Meyer, > Richtig, so sollte es sein. Darauf hatten wir uns auch zuletzt > geeinigt, ich habe es lediglich noch nicht umgesetzt. Das habe ich so auch in Erinnerung. > 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? Ich würde die Listen zentral pflegen wollen, auf den Viewer-Seiten selbst. Bzgl. des Formats gab es hier schon ein paar Vorschläge. Das könnte man sich in Ruhe überlegen. > 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. Wie gesagt, ich sehe es eher so, daß man - analog zur VD16/17-Liste - eben weitere in den jeweiligen Communities diskutieren und standardisieren könnte. > 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. Die technische Komplexität bei einer zentralen Pflege halte ich für gering. Demgegenüber würde ein einziges Strukturdatenset m.E. Gefahr laufen, unendlich zu wuchern. Beste Grüße, Kay Heiligenhaus

15 years, 2 months

Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17-Projekten

by Kay Heiligenhaus

Lieber Herr Meyer, > das Problem der überlagerten Dropdown-Box hat nichts mit der Menge der > Strukturdaten zu tun. Vielmehr besteht hier ein Problem bei zu kurzen > Titeln. Das werde ich korrigieren. Prima. > Was das Problem der zu kurzen Dropdown-Box betrifft, ist das leider > etwas schwieriger. Hier habe ich die Wahl, dem Feld entweder eine feste > Breite zuzuweisen oder dem Browser die Wahl der Breite zu überlassen. > Ich hatte mich gegen die feste Breite entschieden, weil die Angaben in > der Dropdown-Box prinzipiell beliebig lang sein können (es werden ja > die Paginierungssequenzen aus der METS-Datei angezeigt) und dann unter > Umständen abgeschnitten würden. Die variable Breite orientiert sich > dagegen am Inhalt. Dummerweise vergessen einige Browser dabei jedoch, > dass ja auch der Scrollbalken noch etwas Platz braucht, was dann zu den > beschriebenen Effekten führt. Ich werde einfach mal die Variante mit > der festen Breite ausprobieren. Finde ich ebenfalls gut. > Ich unterstütze den Vorschlag. Die angezeigte VD16/17-Nummer könnte ja > sogar vom Viewer automatisch mit dem Katalog verknüpft werden, so dass > in <dv:reference> auch weiterhin der OPAC verlinkt sein könnte. Der > Nutzer hätte dann die Wahl, ob er in den OPAC der digitalisierenden > Einrichtung oder den VD16/17-Katalog wechseln möchte. Ich finde es nicht so sinnvoll, dem Nutzer mehrere Links anzubieten. Aus meiner Sicht sollte sich jede Institution selbst entscheiden können, wohin verlinkt wird. Für VD16/17 sehe ich es persönlich als überflüssig an, in den eigenen OPAC zu verlinken. Das zentrale Nachweisinstrument ist eben der VD16/17-Katalog. Aber, das mag jeder halten, wie er will. Beste Grüße, Kay Heiligenhaus

15 years, 2 months

Re: [DFG-Viewer] Nutzung des DFG-Viewers in VD16- und VD17-Projekten

by Kay Heiligenhaus

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=… 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: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

15 years, 2 months

Nutzung des DFG-Viewers in VD16- und VD17-Projekten

by Kay Heiligenhaus

Liebe Kolleginnen und Kollegen, im Ponickau-Projekt der ULB Sachsen-Anhalt haben wir im Rahmen der Einspielung einer neuen Softwareversion inzwischen auf die Nutzung des DFG-Viewers in Version 2.0 umgestellt. Das erlaubt dem Nutzer des Projektes damit auch die Navigation über die im Viewer angezeigten Strukturdaten. Ein Beispiel: http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fdigitale.bibliothek.uni-hal… Allerdings scheint es noch ein Problem zu geben, wenn nur wenige Strukturdaten im Werk enthalten sind. Ein Beispiel: http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fdigitale.bibliothek.uni-hal… Hier verdeckt die Navigationsleiste die Dropdown-Box für die Seitennavigation. Auch ist die Dropdown-Box für die Seitennavigation so knapp ausgelegt, daß bei Lieferung von Paginierungsinformationen diese nicht mehr vollständig angezeigt werden. Dadurch verliert dieses wichtige Navigationsmittel leider seinen Zweck (getestet mit IE7 und FF3). Bei unseren internen Diskussionen über die Nutzung des Viewers speziell im Kontext von VD16- und VD17-Projekten ist mir dann nochmal in Erinnerung gekommen, daß wir einen m.E. wichtigen Punkt auf unserer Abstimmungsliste nicht mehr weiterverfolgt haben bei der Implementierung des Viewers Vers. 2.0: die Lieferung und Anzeige der VD16- rsp. VD17-Nummern. Bei unserer eigenen Schnittstellen-Implementierung haben wir zwar dafür gesorgt, daß (a) die VD16/VD17-Nummer mitgeliefert wird sowie (b) der OPAC-Link zum VD16/VD17-Katalog verweist (s. etwa das erste Beispiel unter http://digitale.bibliothek.uni-halle.de/oai/?verb=GetRecord&metadataPrefix=…) <mods:identifier type="vda">3:640177N</mods:identifier> und <dv:reference>http://gso.gbv.de/DB=1.28/CMD?ACT=SRCHA&IKT=8002&TRM=3:640177N</dv:reference> Allerdings haben wir uns nicht auf ein "Typsystem" für den Identifier verständigt (wir liefern hier - nach guter GBV-Tradition ;) - für VD17 den type "vda"), Herr Meyer hatte aber damals, wenn ich mich recht entsinne, das Naheliegende vorgeschlagen: type="VD16" und type="VD17". Da ich zufällig über das Thema auch mit Frau Fabian von der BSB sprach (die das als ein echtes Desiderat der Viewer-Implementierung berachtet!), würde ich kurz in die Runde fragen wollen: Spricht aus Ihrer Sicht etwas dagegen, diese Erweiterung beim Update zu berücksichtigen, sprich: wenn entsprechende Identifier mitgeliefert werden, dann werden diese in eckigen Klammern hinter der Kurztitelaufnahme angezeigt, also für Beispiel 1 oben etwa: "Ferdinand <Römisch-Deutsches Reich, Kaiser, II.>: Calvinischer Mutwill/ Das ist: Kurtze Erwegung/ deß newlich in offentlichem Truck/ unter dem Titul eines Behemischen/ mit Niderlendischem Hirn gefülten Streittkopffs/ oder Behemischen Wunder-Hirns außgangenen Tractats (Augspurg, 1620) [VD17 14:006773Q]" Das wäre für einen VD16/VD17-Nutzer auch aus meiner Sicht sehr hilfreich und sollte sich auch ohne größere Aufwände umsetzen lassen. Was denken Sie? Beste Grüße, Kay Heiligenhaus

15 years, 2 months

Nochmal zum Validator

by Kay Heiligenhaus

Lieber Herr Meyer, ich habe gesehen, daß Sie nun den Validator auf den Viewer-Seiten aktiv geschaltet haben: http://dfg-viewer.de/profil-der-metadaten/validator/ Leider wird der Nutzer an keiner Stelle darauf hingewiesen, daß der Validator keine METS/MODS-Dateien der Version 1 (Light-Profil) validieren kann, obgleich unsere eigenen Beispiele auf den Viewer-Seiten diesem Schema folgen. Wohin das führt, konnte vor kurzem die BSB am eigenen Leibe erfahren: http://archiv.twoday.net/stories/5525850/ Im Kommentar vom 19.2. heißt es: "In dem angegebenen Link zum DFG-Viewer muss die URL, die zur METS Datei fuehrt encoded werden. Der derzeitige Link gibt lediglich eine Fehlermeldung des DFG-Viewers aus; die METS Datei der BSB wird nichtmal geladen. http://dfg-viewer.de/v1/?set%5Bmets%5D=http%3A%2F%2Fmdz10.bib-bvb.de%2F%7Ed… waere die richtige URL - die allerdings auch nicht funktioniert, da die METS Datei nicht den Spezifikationen des DFG Viewers entspricht." Die BSB-METS-Datei entspricht sehr wohl den Vorgaben des DFG-Viewers im Light-Profil (wie übrigens fast alle mir bisher bekannten Umsetzungen der Viewer-Anforderungen an zig Standorten). Das Problem steckt hier woanders (nämlich darin, daß die Image-URLs nicht mehr gültig sind). Man sieht aber an diesem Beispiel, wie schnell aus solchen technischen Wirrnissen Anwürfe generalisierender Art werden: "BSB missachtet ihre Pflichten gegenüber der DFG". Das kann nicht im Interesse der Community sein... Beste Grüße, Kay Heiligenhaus

15 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

DV-Technik February 2009