DV-Technik

dv-technik@dfg-viewer.de

329 discussions

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

17 years

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

17 years

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

17 years

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

17 years

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

by Kay Heiligenhaus

Lieber Herr Stäcker, > Sie haben zu meinen letzten Vorschlag, die Textelemente in ein FContent > Element zu verschieben, nichts gesagt. Ich war wahrscheinlich schon zu vernebelt von meiner allmählichen Verfertigung der Gedanken beim Lesen. ;) > Die FContent Variante scheint mir dagegen zielführender zu sein und eher in der METS Linie zu liegen > (Stichwort: Zeigerorgie ;-)). Ja, in dieser Hinsicht schon. Aber mir scheint das an dieser Stelle nicht notwendig rsp. würden wir uns m.E. mit Ihrem Vorschlag zu weit von der METS-Community und den - zumindest mir bekannten - Implementierungen entfernen. Da nun die LoC-Seiten wieder da sind, kurz daraus: "FContent: file content. The FContent element is used to deliver a content file for a METS document within the METS file itself. The content file must be either Base 64 encoded, and contained within the subsidiary binData wrapper element, or consist of XML information and be contained within the subsidiary xmlData wrapper element." (http://www.loc.gov/standards/mets/docs/mets.v1-7.html#FContent) Ich denke, das erklärt hinreichend, warum FContent so, wie Sie das andenken, nicht wirklich weiterhelfen kann. > Für die Strukturdaten ohne Content hätten wir dann die Möglichkeit in > TYPE die Art des LABELS (auch Thesauri etc.) zu qualifizieren, d.h. > > am besten: > > <mets:div ID="log809417" TYPE="Strukturdaten" LABEL="title_page" > ORDER="1"/> > > wobei dem Viewer auch noch mitgeteilt werden müsste, wie er > "title_page" auflösen soll, > > am zweitbesten: > > <mets:div ID="log809417" TYPE="Strukturdaten" LABEL="Titelseite" > ORDER="1"/> Auch hier der Hinweis auf die Spezifikation: "div: Division. The METS standard represents a document structurally as a series of nested div elements, that is, as a hierarchy (e.g., a book, which is composed of chapters, which are composed of subchapters, which are composed of text). Every div node in the structural map hierarchy may be connected (via subsidiary mptr or fptr elements) to content files which represent that div's portion of the whole document. [...] LABEL: xsd:string optional LABEL: an optional string label to describe this div to an end user viewing the document, as per a table of contents entry (NB: a div LABEL should be specific to its level in the structural map. In the case of a book with chapters, the book div LABEL should have the book title, and the chapter div LABELS should have the individual chapter titles, rather than having the chapter div LABELs combine both book title and chapter title). [...] TYPE: xsd:string optional TYPE: an optional string attribute for specifying a type of division (e.g., chapter, article, page, etc.)." (http://www.loc.gov/standards/mets/docs/mets.v1-7.html#div) Man kann das nun sehr weit auslegen, damit auch Ihr Vorschlag unter diese Beschreibung paßt. Ich denke aber, daß wir uns auch damit zu sehr von den Ausführungen hier in der Spezifikation sowie den verschiedenen Implementierung derselben bewegen würden. Zumindest ist mit kein METS-Profil bekannt, daß einen ähnlichen Angang macht, wie Sie ihn hier vorschlagen. Das spricht nicht prinzipiell gegen dieses Vorgehen, mir erschließt sich aber noch nicht, was der Vorzug gegenüber der bestehenden Kodierung sein sollte. Wie gesagt: Gegen flexible "Strukturdatensets" (zur Abbildung unterschiedlicher "Medientypen") habe ich nichts einzuwenden. Ich denke aber, daß sich ein METS-Dokument, das an den Viewer ausgeliefert wird, auf einen Medientyp "festlegen" sollte und die für diesen Typ spezifischen "kontrollierten Vokabularien" verwenden. Das wäre im Falle von VD16/17, soweit ich das verstanden habe, die auf den Viewer-Seiten dokumentierte Typologie. Dieses Festlegen findet aktuell implizit statt - wir haben halt aktuell "nur" eine dokumentierte Typologie. Sobald es weitere gibt, sollte man diese Bezugnahme vielleicht explizit regeln. Der DV-Namensraum im aktuellen Profil wird uns dazu schon den Raum bieten. Beste Grüße, Kay Heiligenhaus

17 years

Probleme mit den DFG-Viewer-Mailinglisten

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, offenbar gab es seit den Arbeiten am Listenserver Anfang des Monats einige Probleme mit den Mailinglisten. Teilweise verweigerte der Mail-Server der SLUB den Empfang von Mails an die DFG-Viewer-Listen. Ursache war eine fehlerhafte Konfiguration des internen DNS-Dienstes. Das Problem ist nun behoben. Bitte entschuldigen Sie die Störung. Viele Grüße Sebastian Meyer -- ___________________________________________________ Sebastian Meyer Projekt-Mitarbeiter Abteilung Informationstechnologie (IT) Referat Entwicklung Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Besucheradresse: Zellescher Weg 18 Tel.: +49 351 4677-206 Fax: +49 351 4677-711 Mail: smeyer(a)slub-dresden.de Web: http://www.slub-dresden.de/ ___________________________________________________

17 years

Re: [DFG-Viewer] Arbeiten an den DFG-Viewer Mailinglisten

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, die Arbeiten an unserem Listen-Server sind nun abgeschlossen. Die beiden DFG-Viewer-Mailinglisten "Support" und "Technik" sind damit ab sofort wieder freigegeben. Viele Grüße Sebastian Meyer -- ___________________________________________________ Sebastian Meyer Projekt-Mitarbeiter Abteilung Informationstechnologie (IT) Referat Entwicklung Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Besucheradresse: Zellescher Weg 18 Tel.: +49 351 4677-206 Fax: +49 351 4677-711 Mail: smeyer(a)slub-dresden.de Web: http://www.slub-dresden.de/ ___________________________________________________ > -----Ursprüngliche Nachricht----- > Von: Meyer, Sebastian > Gesendet: Mittwoch, 4. Februar 2009 16:18 > An: 'technik(a)dfg-viewer.de'; 'support(a)dfg-viewer.de' > Betreff: Arbeiten an den DFG-Viewer Mailinglisten > > Liebe Kolleginnen und Kollegen, > > am morgigen Donnerstag, 5. Februar, wird unser Listen-Server aufgrund > notwendiger administrativer Arbeiten am Vormittag nicht erreichbar > sein. Das vorgesehene Wartungsfenster umfasst die Zeit von 8 bis 12 > Uhr. Es werden beide Mailinglisten ("Technik" und "Support") > gleichermaßen von der Maßnahme betroffen sein. > > Ich möchte Sie daher bitten, im genannten Zeitraum vom Versand von > Mails an die Mailinglisten abzusehen. Darüber hinaus gibt es von Ihrer > Seite nichts zu beachten. Nach Abschluss der Arbeiten sind die > Mailinglisten wie gewohnt nutzbar. Über die Freigabe des Listen-Servers > werde ich Sie auf diesem Weg informieren. > > Vielen Dank für Ihr Verständnis und viele Grüße > Sebastian Meyer > > -- > ___________________________________________________ > > Sebastian Meyer > Projekt-Mitarbeiter > > Abteilung Informationstechnologie (IT) > Referat Entwicklung > > Sächsische Landesbibliothek - > Staats- und Universitätsbibliothek Dresden (SLUB) > 01054 Dresden > Besucheradresse: Zellescher Weg 18 > > Tel.: +49 351 4677-206 > Fax: +49 351 4677-711 > Mail: smeyer(a)slub-dresden.de > Web: http://www.slub-dresden.de/ > ___________________________________________________ >

17 years, 1 month

Arbeiten an den DFG-Viewer Mailinglisten

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, am morgigen Donnerstag, 5. Februar, wird unser Listen-Server aufgrund notwendiger administrativer Arbeiten am Vormittag nicht erreichbar sein. Das vorgesehene Wartungsfenster umfasst die Zeit von 8 bis 12 Uhr. Es werden beide Mailinglisten ("Technik" und "Support") gleichermaßen von der Maßnahme betroffen sein. Ich möchte Sie daher bitten, im genannten Zeitraum vom Versand von Mails an die Mailinglisten abzusehen. Darüber hinaus gibt es von Ihrer Seite nichts zu beachten. Nach Abschluss der Arbeiten sind die Mailinglisten wie gewohnt nutzbar. Über die Freigabe des Listen-Servers werde ich Sie auf diesem Weg informieren. Vielen Dank für Ihr Verständnis und viele Grüße Sebastian Meyer -- ___________________________________________________ Sebastian Meyer Projekt-Mitarbeiter Abteilung Informationstechnologie (IT) Referat Entwicklung Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Besucheradresse: Zellescher Weg 18 Tel.: +49 351 4677-206 Fax: +49 351 4677-711 Mail: smeyer(a)slub-dresden.de Web: http://www.slub-dresden.de/ ___________________________________________________

17 years, 1 month

Validator

by Thomas Stäcker

Lieber Herr Meyer, ich habe noch ein Problem mit dem Validator. Ich bekomme folgende Fehlermeldung, die ich bei meinem häsulichen Saxon nicht bekomme: Validierung gegen das MODS Schema (http://www.loc.gov/mods/v3/mods-3-2.xsd) Teildokument #1 *Fehler!* Die Validierung gegen das MODS Schema ist fehlgeschlagen.Element '{http://www.loc.gov/mods/v3}mods', attribute '{http://www.w3c.org/2001/XMLSchema-instance}schemaLocation': The attribute '{http://www.w3c.org/2001/XMLSchema-instance}schemaLocation' is not allowed. Line: 1 Column: 0 ?Originale Quelldatei: Problem könnte ist, dass offenbar korrekte Angaben zur schemaLocation nicht goutiert werden. Nach meinem Gefühl sollte der Parser solche Angaben eigentlich überschreiben, weil er die Regeln vorgibt, nicht ein externes Schema. Das kann man normalerweise auch so konfigurieren. Oder, wie wollen wir damit umgehen? Dann wird das Fehlen von <dv:rights> <dv:owner>Herzog August Bibliothek Wolfenbüttel</dv:owner> <dv:ownerLogo>http://www.hab.de/images/logo_dfg_viewer.gif</dv:ownerLogo> <dv:ownerSiteURL>http://www.hab.de/</dv:ownerSiteURL> <dv:ownerContact>auskunft(a)hab.de</dv:ownerContact> </dv:rights> nicht beanstandet. Dies war valide: <mets:rightsMD ID="amd_dvrights_586140484"> <mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="DVRIGHTS"> <mets:xmlData> <hallo>test</hallo> </mets:xmlData> </mets:mdWrap> </mets:rightsMD> sprich, mein Codeschnipsel ist doch nicht implementiert worden :-( Dann werden ID-Referenzen nicht überall geprüft, z.B. ist <mets:structLink> <mets:smLink xlink:to="logMD_586140484" xlink:from="xxx"/> </mets:structLink> gültig, obwohl xlink:from="xxx" keine Entsprechung im Dokument hat Dies fürs erste. Viele Grüße, Ihr Th. Stäcker

17 years, 1 month

DFG-Viewer und Webseite nun zweisprachig

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, die Übersetzung von Webseite und Dokumentation des DFG-Viewers sowie den METS/MODS-Anwendungsprofilen ist bis auf wenige Details abgeschlossen. Lediglich ein paar Mouse-Over-Texte sind noch einsprachig. Das werde ich in den kommenden Tagen noch korrigieren. Oben rechts auf der Webseite finden Sie einen Sprachumschalter, um zwischen deutscher und englischer Sprachversion zu wechseln. Viele Grüße Sebastian Meyer -- ___________________________________________________ Sebastian Meyer Projekt-Mitarbeiter Abteilung Informationstechnologie (IT) Referat Entwicklung Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Besucheradresse: Zellescher Weg 18 Tel.: +49 351 4677-206 Fax: +49 351 4677-711 Mail: smeyer(a)slub-dresden.de Web: http://www.slub-dresden.de/ ___________________________________________________

17 years, 1 month

← Newer
1
...
23
24
25
26
27
28
29
...
33
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

DV-Technik