DV-Technik

dv-technik@dfg-viewer.de

329 discussions

Re: [DFG-Viewer] Vorschlag: Wiederholbarkeit von dv:license

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, dem schließe ich mich an, weshalb ich zu entschuldigen bitte, dass ich die Diskussion zwar angestoßen, mich bisher aber nicht weiter selbst beteiligt habe. Beste Grüße vom Bibliothekartag, Sebastian Meyer Am 28.05.2015 15:22 schrieb David Maus <maus(a)hab.de>: ...und ein kurzer Nachtrag: Ich bin leider bis 26. Juni außer Haus und stehe erst dann wieder zur Verfügung. -- David Maus On Sat, 23 May 2015 12:39:50 +0200, David Maus wrote: > > Lieber Herr Schleier, > > On Fri, 22 May 2015 15:54:51 +0200, > Timo Schleier wrote: > > > > Lieber Herr Maus, > > > > > Wenn unterschiedliche Lizenzen für unterschiedliche Teile des > > > digitalen Objekts zugelassen werden sollen, dann *muss* <amdSec> > > > wiederholbar sein, damit auch unterschiedliche Lizenzgeber (dv:owner) > > > angegeben werden können. Oder unterschiedliche <digiprovMD>. > > Das ist richtig, wiederholbare <amdSec> erlauben darüber hinaus noch > > viel feinere Angaben, sind dafür aber auch komplexer. Wir haben hatten > > uns für die einfache Variante entschieden. > > > > Es ließe sich auch die <rightsMD> in der <amdSec> wiederholen und die > betreffenden Teile über das @ADMID-Attribut mit den <rightsMD> > verbinden. > > Ich sehe nicht, wie die <dv:license>/@type-Variante einfacher ist: > Anstatt expliziter Zuweisungen wählen Sie implizite Zuordnungen von > Lizenzen zu Bestandteilen des digitalen Objekts. Das wird Ihnen > mittelfristig auf die Füße fallen. > > Bis gerade eben wurde vorausgesetzt, dass die Lizenz der verschiedenen > Teile identisch ist. Die Entscheidung, diese Zuordnung über ein > Attribut des <dv:license>-Elements auszudrücken setzt voraus, dass der > Owner und der Sponsor identisch sind. Auf welcher Grundlage machen Sie > diese Voraussetzungen? Mir erscheint das ausgesprochen kurzsichtig. > > In Verbindung mit dem Anwendungsprofil, in dem eine Wiederholung von > <amdSec> et al. nicht vorgesehen ist verhindert die Lösung, dass die > Rechteangaben in METS-konformer Form zugewiesen werden können. Damit > ist das METS nur für den DFG-Viewer geeignet. Deswegen ist die > Attributlösung nicht interoperabel. > > > > Auch das ist abwärtskompatibel: Wer die <div> des Werkes mit der > > > <amdSec> verknüpft gibt an, dass die in der <amdSec> angegebenen > > > Lizenzinformationen für das gesamte digitale Objekt gilt. > > Ja, aber das Parsen und die Darstellung der Angaben wird schwieriger, > > wenn weitere <amdSec> erlaubt sind und diese für Teile des digitalen > > Objekts andere Rechteinformationen beinhalten. > > > > Es kann sein, dass die METS-konformen Angaben *für den DFG-Viewer* > schwieriger zu verarbeiten sind. Dann muss der DFG-Viewer > umprogrammiert werden. > > Mit besten Grüßen, > -- David > > > > Nein: Die <structMap> gehört zur METS-Datei. Sie könnten IIRC den > > > <metsHdr> mit einer <amdSec> verbinden. > > Über die Möglichkeit, den <metsHdr> mit einer <amdSec> zu verknüpfen > > hatten wir auch nachgedacht. Aus unserer Sicht wäre dies ebenfalls > > eine gute Lösung. Damit müsste die <amdSec> im METS-Anwendungsprofil > > wiederholbar werden. Darüber hinaus wäre es sinnvoll entsprechende > > Vorgaben zum <metsHdr> zu definieren, da es bisher im Anwendungsprofil > > dazu keine Angaben gibt. > > > > Viele Grüße > > Timo Schleier > > > > > > -- > David Maus > Herzog August Bibliothek - D-38299 Wolfenbuettel > Bibliothekarische IT / Digital Humanities > Phone: +49-5331-808-317 > Email: maus(a)hab.de > > PGP Key 0x7B4F5A762AF6FBA6 > Fingerprint DD38 8D2E 34C1 94DE 2058 69BE 7B4F 5A76 2AF6 FBA6 > > -- David Maus Herzog August Bibliothek - D-38299 Wolfenbuettel Bibliothekarische IT / Digital Humanities Phone: +49-5331-808-317 Email: maus(a)hab.de PGP Key 0x7B4F5A762AF6FBA6 Fingerprint DD38 8D2E 34C1 94DE 2058 69BE 7B4F 5A76 2AF6 FBA6

9 years, 6 months

dv:reference

by Philipp Vanscheidt

Sehr geehrte Damen und Herren, liebe Kollegen, eines unserer Projekte erhält eine neue Weboberfläche und vervollständigte METS-Dateien mit TEI-Headern. Dabei bin ich auf eine Frage gestoßen, die das verpflichtende Element dv:reference betrifft. Dieses verweist auf Katalogeinträge, zum Beispiel in einem eigenen OPAC. Unser Fall hat nun folgende Besonderheiten: Voraussetzung 1: Es gibt eine Datenbank, aus der dynamisch Einträge in einem Webportal erzeugt werden. Die Informationen aus der Datenbank werden ferner in die TEI-Header der METS-Dateien geschrieben. Das neue Webportal bietet aber nicht per se eine Adresse, um den vollständigen Katalogeintrag zu öffnen. Dieser lässt sich stattdessen in einer Trefferliste über einen Knopf jeweils auf- und zuklappen. Der Link bleibt dabei unverändert. Voraussetzung 2: Es gibt bei uns getrennte Katalogeinträge zu jedem Kodex und zu jedem Inhalt, die aber aufeinander verweisen. Zwischen beiden läßt sich entsprechend zwar navigieren, aber es erscheint wünschenswert, einen Katalogeintrag zu haben, der alle Information zu einem Kodex und zu allen seinen Inhalten umfasst. In unseren neuen METS-Dateien ist das der Fall. Es bieten sich, soweit ich sehe, drei Lösungen an: Lösung 1: Es wird auf die Katalogsuche selbst verweisen. Contra Lösung 1: Der Link wäre für alle Kodizes identisch. Man müsste erst noch nach dem jeweiligen Kodex suchen. Wenn man ihn gefunden hat, muss man sich gegebenfalls erst zu den Inhalten bewegen. Lösung 1 bietet keine Antwort auf den Wunsch aus Voraussetzung 2. Lösung 2: Man kann vielleicht versuchen, die Ereignisse, die zum Öffnen der Detailansicht führen, als Paramter in einem Link mitzugeben. Contra Lösung 2: Das wäre wahrscheinlich aufwendig. Ferner bildet es die Navigation auf der Oberfläche ab. Ändert sich diese, müssen auch die Parameter geändert werden. Es scheint mir sinnvoller, Adressen stabil zu halten als Weboberflächen. Auch Lösung 2 bietet keine Antwort auf die zweite Voraussetzung. Lösung 3: Wir verweisen direkt auf die METS-Datei mit dem TEI-Header, der alle Informationen aus der Datenbank enthält. (Alternativ können wir natürlich auch ein XML/TEI-Dokument erzeugen, das keine METS-Anteile enhält.) Diese Lösung kommt auch dem unter Vorausssetzung 2 geäußerten Erfordernis entgegen. Conta Lösung 3: Dies entspricht nicht den Beispielen in der Dokumentation. Nutzer könnten irritiert sein, wenn Sie einen OPAC erwarten und sich stattdessen eine XML-Datei öffnet. Trotz dieses Einwandes präferiere ich deutlich Lösung 3. Ich bin mir aber nicht sicher, ob das im Sinne des Erfinders ist. Der Definition von dv:reference widerspricht es m.E. allerdings auch nicht. Mit freundlichem Gruß Philipp Vanscheidt -- Technische Universität Darmstadt Institut für Sprach- und Literaturwissenschaft Dolivostraße 15, 64293 Darmstadt vanscheidt(a)linglit.tu-darmstadt.de

9 years, 6 months

Vorschlag: Wiederholbarkeit von dv:license

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, im METS-Anwendungsprofil des DFG-Viewers [1] gibt es ja schon seit einiger Zeit das optionale Element "dv:license" in der administrativen Metadaten-Sektion. Dieses Element dient dazu, ein Digitalisat wahlweise als Public Domain zu kennzeichnen, unter eine Creative Commons-Lizenz zu stellen oder sich alle Rechte daran vorzubehalten. Letzteres ist der Standard, wenn nicht explizit anderes angegeben wurde oder das Element gar nicht vorhanden ist. Bislang wird dieses Element zwar im DFG-Viewer noch gar nicht interpretiert (geplant ist die Anzeige eines entsprechenden Lizenz-Logos), aber in anderen Kontexten wie z.B. der Deutschen Digitalen Bibliothek wird es bereits gerne ausgewertet. Dabei ist nun aufgefallen, dass ein einziges Element, das zudem nicht wiederholbar ist, den Anforderungen leider nicht gerecht wird. Oft sind beispielsweise Images und Metadaten mit unterschiedlichen Lizenzen versehen oder es werden mehrere alternative Lizenzen angeboten. Ich möchte daher in Abstimmung mit der DDB Fachstelle Bibliothek (SUB Göttingen) vorschlagen, das METS-Anwendungsprofil in folgender Weise zu erweitern: 1. Das Element dv:license darf wiederholt werden. 2. Das Element dv:license erhält ein Attribut "type", in dem angegeben werden kann, ob die Lizenzangabe sich auf das gesamte Dokument, die Metadaten oder die Images (oder die Volltexte oder ...) bezieht. Dazu werden normierte Attributwerte vorgegeben, damit diese einheitlich verwendet werden. Wird kein type-Attribut angegeben, wird die Lizenz auf das gesamte Dokument angewendet. Dadurch ist gewährleistet, dass existierende Implementierungen nicht verändert werden müssen. D.h. wer dieses Element nach aktuellem Anwendungsprofil bereits verwendet, muss seine Implementierung nicht anpassen, um weiterhin dieselbe Aussage zu treffen. Gleichzeitig besteht aber optional die Möglichkeit, die Aussagen zu präzisieren und verschiedene Teile des Digitalisats unterschiedlich zu lizensieren. Was meinen Sie? Haben Sie ergänzende oder abweichende Vorschläge? Wie handhaben Sie ggf. jetzt schon die Angabe verschiedener Lizenzen innerhalb Ihrer Digitalisate? Viele Grüße Sebastian Meyer -- Sebastian Meyer Referatsleiter Digitale Bibliothek Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) Abteilung IT, Referat Digitale Bibliothek 01054 Dresden Besucheradresse: Zellescher Weg 18 Tel.: +49 351 4677 206 | Fax: +49 351 4677 711 E-Mail: sebastian.meyer(a)slub-dresden.de<mailto:sebastian.meyer@slub-dresden.de> http://www.slub-dresden.de<http://www.slub-dresden.de/>

9 years, 7 months

Adressierung von Einzelseiten

by Dirk Rothe

Hallo Herr Meyer, wir haben festgestellt, dass es Problem bei der direkten Adressierung von Einzelseiten gibt. Aus unserer Sicht dürfte die Vereinbarung darin bestehen, dass wir mit dem Parameter &set[image]=phys9576442 die selektierte Seite kennzeichnen. Ein Beispiel wäre: http://dfg-viewer.de/show/?set[image]=phys9576442&set[mets]=http%3A//digita… Leider wird immer nur die erste Seite selektiert. Das führt dann zu fehlerhaften Auflösungen bei Einzelseiten-URNs wie z.B. http://nbn-resolving.de/urn:nbn:de:gbv:3:1-643237-p0007-9 In der 2er DVG-Viewer Version hat dieser Mechanismus noch funktioniert. Das METS sieht m.E. im Bezug auf phys9576442 auch sauber aus: http://digitale.bibliothek.uni-halle.de/vd18/oai?verb=GetRecord&metadataPre… Beste Grüsse, Dirk Rothe

10 years

Re: [DFG-Viewer] Größen von DEFAULT, MIN, MAX und THUMBS

by Heinze, Carl

Lieber Herr Meyer, lieber Herr Stäcker, vielen Dank für Ihre Antworten, die meine Fragen gut beantworten. Viele Grüße & schönes WE, Carl Heinze ----- Ursprüngliche Mail ----- Von: Sebastian.Meyer(a)slub-dresden.de An: dv-technik(a)dfg-viewer.de Gesendet: Freitag, 5. Dezember 2014 12:28:07 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien Betreff: Re: [DFG-Viewer] Größen von DEFAULT, MIN, MAX und THUMBS Liebe Kollegen, zu 1): Seit der DFG-Viewer den stufenlosen Zoom unterstützt, ist die Angabe von drei verschiedenen fileGrps bzw. Bildgrößen nicht mehr nötig. Der Viewer verwendet nur noch die jeweils größte verfügbare Bildgröße (i.d.R. MAX - wenn das nicht vorhanden ist, wird DEFAULT verwendet). So ist es auch auf der Webseite des DFG-Viewers dokumentiert [1]. Der Viewer ist jedoch abwärtskompatibel, d.h. es schadet auch nicht, wenn Sie weiterhin alle drei Zoomstufen ausliefern. Zu 2): Die empfohlenen Auflösungen hat Herr Staecker ja bereits benannt. Was die Originalauflösungen betrifft, gibt es auch dafür inzwischen eine fileGrp -Konvention (ORIGINAL) für den DFG-Viewer. In den nächsten Tagen werden wir die neue Version des DFG-Viewers veröffentlichen. Diese bringt neben einer Kalenderblatt-Navigation für Zeitungen auch eine optionale und noch experimentelle Volltext-Suche über eine SRU-Schnittstelle des Datenlieferanten mit. Für das Trefferhighlighting im Digitalisat werden Wortkoordinaten benötigt, die sich auf die Originalauflösung des Scans beziehen. Damit der DFG-Viewer diese Koordinaten für die aktuelle Zoomstufe umrechnen kann, benötigt er die Originalauflösung der Scans. Dazu ist die fileGrp [@USE="ORIGINAL"] vorgesehen. Ist diese nicht vorhanden, geht der DFG-Viewer davon aus, dass die fileGrp [@USE="MAX"] bereits die Originalauflösung enthält. Um also sowohl den DFG-Praxisregeln wie auch den (optionalen) Anforderungen des DFG-Viewers gerecht zu werden, müssten Sie die Scans in Originalauflösung entweder in fileGrp [@USE="MAX"] verlinken oder zusätzlich eine fileGrp [@USE="ORIGINAL"] einfügen. Zu 3): Der Unterschied zwischen THUMBS und TEASER ist, dass THUMBS Vorschaubilder jeder einzelnen Seite enthalten soll und für die grafische Navigation im Werk verwendet wird. TEASER soll dagegen nur 1 (oder wenige) Image enthalten, das das gesamte Werk repräsentiert (z.B. die Titelseite). Dieses Image wird als Vorschaubild bei z.B. Suchtreffern angezeigt. Im DFG-Viewer wird TEASER derzeit nicht verwendet. Viele Grüße Sebastian Meyer [1] http://dfg-viewer.de/hinweise-zur-bildbearbeitung/ -- Sebastian Meyer Referatsleiter Digitale Bibliothek Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) Abteilung IT, Referat Digitale Bibliothek 01054 Dresden Besucheradresse: Zellescher Weg 18 Tel.: +49 351 4677 206 | Fax: +49 351 4677 711 E-Mail: sebastian.meyer(a)slub-dresden.de http://www.slub-dresden.de From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-viewer.de] On Behalf Of Thomas Staecker Sent: Friday, December 05, 2014 12:00 PM To: dv-technik(a)dfg-viewer.de Subject: Re: [DFG-Viewer] Größen von DEFAULT, MIN, MAX und THUMBS Am 05.12.2014 11:03, schrieb Heinze, Carl: Hallo, ich habe mehrere Fragen bzgl. der JPG-Versionen meiner Digitalisate und hoffe, dass Ihr mir weiter helfen könnt. 1) Für den DFG-Viewer sollte man JPGs als DEFAULT, MIN, MAX und THUMBS erstellen, oder? Ja 2) Welche Pixelgrößen müssen die jeweiligen Bilder haben? Falls es keine definitiven Vorgaben gibt, was wären jeweils sinnvolle Größen, wenn meine Vorlage eine Handschrift aus dem 19. Jahrhundert ist? Wir haben hier 1000,600, 2000 und 150px Bildbreite genommen. Die DFG verlangt neuerdings auch eine Bereitstellung der Originalgröße (300dpi) in JPEG bei geringer Kompression. Das müsste - nebenbei bemerkt - vom DFG Viewer noch abgebildet werden (z.B. ORIGSIZE), oder diese Originalgrößen werden als MAX geliefert. 3) Im METS-Anwendungsprofil des DFG-Viewers wird u.A. auch noch von TEASER als weiterer Version des Digitalisats gesprochen - wie unterscheidet sich dies von THUMBS? Es geht doch in beiden Fällen um Vorschaubilder, oder? Nach meinem Wissen in nichts 4) Unabhängig von den Anforderungen des DFG-Viewers: Welche weiteren Versionen des Digitalisats erzeugt Ihr in Euren Digitalisierungsprojekten? Gibt es Standards oder Best-Practices dafür? Die DFG-Richtlinien bennenen übrigens auch keine konkreten Größenangaben - genau daran wäre ich aber interessiert. s.o. Master ist ein TIFF mit mind. 300dpi Auflösung, bei sehr feingliedrigen Graphiken odre Handschriften auch 400 dpi. Mehr ist m.E. nicht nötig. Viele Grüße, Th . Stäcker Ganz herzlichen Dank! Ich bin natürlich auch sehr über Antworten zu einzelnen Fragen dankbar, also nur zu! Viele Grüße, Carl Heinze ------------------------------------------ Dr. Carl Heinze Forschungsverbund Marbach Weimar Wolfenbüttel Deutsches Literaturarchiv Marbach Digital Humanities ------------------------------------------ Schillerhöhe 8-10 71672 Marbach am Neckar Telefon +49-7144/848-144 Telefax +49-7144/848-154 carl.heinze(a)dla-marbach.de www.dla-marbach.de www.mww-forschung.de ------------------------------------------ -- --------------------------------------------- Dr. Thomas Stäcker Stellv. Direktor Herzog August Bibliothek Wolfenbüttel Tel. +49+5331/808-303 Email staecker(a)hab.de

10 years, 1 month

Größen von DEFAULT, MIN, MAX und THUMBS

by Heinze, Carl

Hallo, ich habe mehrere Fragen bzgl. der JPG-Versionen meiner Digitalisate und hoffe, dass Ihr mir weiter helfen könnt. 1) Für den DFG-Viewer sollte man JPGs als DEFAULT, MIN, MAX und THUMBS erstellen, oder? 2) Welche Pixelgrößen müssen die jeweiligen Bilder haben? Falls es keine definitiven Vorgaben gibt, was wären jeweils sinnvolle Größen, wenn meine Vorlage eine Handschrift aus dem 19. Jahrhundert ist? 3) Im METS-Anwendungsprofil des DFG-Viewers wird u.A. auch noch von TEASER als weiterer Version des Digitalisats gesprochen - wie unterscheidet sich dies von THUMBS? Es geht doch in beiden Fällen um Vorschaubilder, oder? 4) Unabhängig von den Anforderungen des DFG-Viewers: Welche weiteren Versionen des Digitalisats erzeugt Ihr in Euren Digitalisierungsprojekten? Gibt es Standards oder Best-Practices dafür? Die DFG-Richtlinien bennenen übrigens auch keine konkreten Größenangaben - genau daran wäre ich aber interessiert. Ganz herzlichen Dank! Ich bin natürlich auch sehr über Antworten zu einzelnen Fragen dankbar, also nur zu! Viele Grüße, Carl Heinze ------------------------------------------ Dr. Carl Heinze Forschungsverbund Marbach Weimar Wolfenbüttel Deutsches Literaturarchiv Marbach Digital Humanities ------------------------------------------ Schillerhöhe 8-10 71672 Marbach am Neckar Telefon +49-7144/848-144 Telefax +49-7144/848-154 carl.heinze(a)dla-marbach.de www.dla-marbach.de www.mww-forschung.de ------------------------------------------

10 years, 1 month

Re: [DFG-Viewer] Groß- und Kleinschreibung bei Attributen und Attributwerten

by Georg Hohmann

Liebe alle, > Groß- und Kleinschreibung ist in XML nicht optional, das gilt für Elemente, > Attribute und Attributwerte gleichermaßen (dh. structMap, StructMAP, > StructMap etc. wären völlig verschiedene Dinge). Dass in XML sowohl die Tags als auch die Attribute case-sensitive sind, hat Hr. Schweizer ja schon erwähnt. Der Knackpunkt liegt in den Attributwerten. Generell ist in XML alles als case-sensitive anzusehen (Vgl. z.B. http://xml.silmaril.ie/case.html), also auch die Werte bzw. die Inhalte. Ich bleibe einmal bei dem gegebenen Beispiel, dem Attribut "TYPE". Im Anwendungsprofil des DFG-Viewers heißt es dazu: "Für die logische Struktur muss das Attribut TYPE mit dem Wert LOGICAL verwendet werden." (S.8) Im METS-XML-Schema heißt es: "For example, a <structMap> that represented a purely logical or intellectual structure could be assigned a TYPE value of 'logical'" Es handelt sich hier streng genommen also um zwei verschiedene Werte, nämlich "logical" und "LOGICAL". Nun könnte man natürlich in der Verarbeitung der Werte einfach case-insensitive arbeiten, da das XML-Schema keine Werte normiert. Allerdings ist man dann darauf angewiesen, dass der Verarbeiter immer so verfährt, was nicht garantiert werden kann. Die AP von ZVDD und Co. sind ja eine Sache, aber es wäre ja schön, seine METS-Dateien weltweit "kompatibel" zu haben. Was wäre hier "good practice"? Herzliche Grüße Georg Hohmann Am 30. Oktober 2014 17:27 schrieb Alexander Jahnke < jahnke(a)sub.uni-goettingen.de>: > Liebe Liste, > > Groß- und Kleinschreibung ist in XML nicht optional, das gilt für Elemente, > Attribute und Attributwerte gleichermaßen (dh. structMap, StructMAP, > StructMap etc. wären völlig verschiedene Dinge). > Selbst wenn nun der DFG-Viewer so etwas wie type="logical" akzeptieren > würde, kann man nicht davon ausgehen, dass andere Anwendungen, die dasselbe > AP anwenden (wie z.B. das zvdd) das auch tun, anders ausgedrückt: Die Daten > wären nicht mehr AP-konform wenn die korrekte Schreibweise nicht eingehalten > wird. > > Herzlichen Gruß, > A. Jahnke > > > > Am 30.10.2014 17:01, schrieb Siegfried Schweizer: >> >> Liebe Liste, >> >> ich frage mich, welche Rolle für den DFG-Viewer eigentlich Groß- und >> Kleinschreibung bei Attributnamen und Attributwerten in METS und MODS >> spielen, z.B.: >> >> <mets:structMap TYPE='LOGICAL'> >> >> In der METS-Dokumentation sind die Attributnamen stets großgeschrieben, >> ohne daß dies expressis verbis gefordert wird. Hält man sich also streng >> an die Dokumentation, so wird man wohl die Attributnamen im eigenen zu >> erzeugenden METS ebenfalls großschreiben. >> >> Anders die Attributwerte. Das 'LOGICAL' aus dem Beispiel oben kommt aus >> dem Anwendungsprofil des DFG-Viewers; die METS-Dokumentation kennt hier >> keine Vorgabe. Aber auch im Anwendungsprofil des DFG-Viewers findet sich >> keine explizite Anweisung zu Groß- und Kleinschreibung, weder für >> Attributnamen noch für Attributwerte. >> >> Müssen METS/MODS-Daten sich also in dieser Hinsicht exakt an die Angaben >> in METS-Dokumentation >> (http://www.loc.gov/standards/mets/version18/mets.xsd) und >> Anwendungsprofil des DFG-Viewers >> >> ( http://dfg-viewer.de/fileadmin/groups/dfgviewer/METS-Anwendungsprofil_2.1.p… ) >> halten, um kompatibel mit dem DFG-Viewer zu sein? Oder darf auch >> Kleinschreibung verwendet werden? >> >> Viele Grüße aus München >> >> Siegfried Schweizer >> > > -- > Alexander Jahnke > Gruppenleiter Metadaten und Datenkonversion > > Georg-August-Universität Göttingen > Niedersächsische Staats- und Universitätsbibliothek Göttingen > D-37070 Göttingen > > Papendiek 14 (Historisches Gebäude, Raum 1.612) > +49 551 39-9869 (Tel.) > > jahnke(a)sub.uni-goettingen.de > http://www.sub.uni-goettingen.de > http://www.eromm.org >

10 years, 2 months

Groß- und Kleinschreibung bei Attributen und Attributwerten

by Siegfried Schweizer

Liebe Liste, ich frage mich, welche Rolle für den DFG-Viewer eigentlich Groß- und Kleinschreibung bei Attributnamen und Attributwerten in METS und MODS spielen, z.B.: <mets:structMap TYPE='LOGICAL'> In der METS-Dokumentation sind die Attributnamen stets großgeschrieben, ohne daß dies expressis verbis gefordert wird. Hält man sich also streng an die Dokumentation, so wird man wohl die Attributnamen im eigenen zu erzeugenden METS ebenfalls großschreiben. Anders die Attributwerte. Das 'LOGICAL' aus dem Beispiel oben kommt aus dem Anwendungsprofil des DFG-Viewers; die METS-Dokumentation kennt hier keine Vorgabe. Aber auch im Anwendungsprofil des DFG-Viewers findet sich keine explizite Anweisung zu Groß- und Kleinschreibung, weder für Attributnamen noch für Attributwerte. Müssen METS/MODS-Daten sich also in dieser Hinsicht exakt an die Angaben in METS-Dokumentation (http://www.loc.gov/standards/mets/version18/mets.xsd) und Anwendungsprofil des DFG-Viewers (http://dfg-viewer.de/fileadmin/groups/dfgviewer/METS-Anwendungsprofil_2.1.p…) halten, um kompatibel mit dem DFG-Viewer zu sein? Oder darf auch Kleinschreibung verwendet werden? Viele Grüße aus München Siegfried Schweizer -- Dipl.-Ing. (FH) Siegfried Schweizer Bereich Forschung, Archiv, Bibliothek Deutsches Museum Digital Deutsches Museum Museumsinsel 1 80538 München Tel. +49 089 21 79 563 s.schweizer(a)deutsches-museum.de www.deutsches-museum.de Als wenn Kunst nicht in allem sein sollte, so lang dies nicht ist, sind wir immer noch zum Teil Barbaren. – Ludwig I. von Bayern

10 years, 2 months

Transkriptionen und Übersetzungen

by Sebastian Hofmann

Sehr geehrte Damen und Herren, ich bin Mitarbeiter der Thüringer Universitäts- und Landesbibliothek und beschäftige mich mit der Anzeige von Transkriptionen und Übersetzungen im MyCoRe-ImageViewer. Geplant ist folgendes: Die Transkriptionen sollen als HTML-Datein abgelegt werden. Für jedes Dokument und für jede Sprache soll eine HTML-Datei angelegt werden. Eine HTML-Datei enthält Elemente für die Seiten, welche mit einer ID gekennzeichnet sind. In der METS-Datei sollen die Seiten mit der richtigen HTML-Datei und den Elementen mit der ID verknüpft werden. Da die Kompatibilität zum DFG-Viewer bestehen bleiben soll, richte ich mich bei meiner Arbeit nach dem METS-Anwendungsprofil des DFG-Viewers. Da ich dem Anwendungsprofil nicht entnehmen konnte, wie Transkriptionen richtig in die METS-Datei integriert werden, wollte ich mich erkundigen ob diesbezüglich schon etwas in Planung ist, außerdem habe ich ein Beispiel entworfen wie Transkriptionen in die METS-Datei integriert werden könnten. Das Beispiel befindet sich im Anhang. Viele Grüße Sebastian Hofmann

10 years, 5 months

Re: [DFG-Viewer] DFG-Viewer 3.0 veröffentlicht!

by Meyer, Sebastian

Lieber Herr Maus, die Reihenfolge der Elemente ist tatsächlich beliebig. Bei der Angabe des Förderers ist zu unterscheiden zwischen der bibliografischen Angabe und der "Steuerungsangabe" für das Logo im DFG-Viewer. Die bibliografisch relevante Angabe machen Sie in MODS in einem entsprechenden mods:name-Element (oder eben auch nicht, wenn Sie keine Angabe machen wollen). Über die Angabe in der amdSec steuern Sie lediglich die Anzeige des Logos im DFG-Viewer und dort wird standardmäßig das Logo der DFG angezeigt, weil der Viewer selbst ein DFG-gefördertes Angebot ist. Auch wenn Ihre Digitalisierung nicht von der DFG gefördert wurde, so wird doch zumindest die Präsentation der Digitalisate im DFG-Viewer gewissermaßen von der DFG gefördert. Viele Grüße Sebastian Meyer -- Sebastian Meyer Referatsleiter Digitale Bibliothek Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) Zellescher Weg 18 // 01069 Dresden Postanschrift: 01054 Dresden Tel: +49 351 4677206 // Fax: +49 351 4677711 E-Mail: sebastian.meyer(a)slub-dresden.de http://www.slub-dresden.de/ -------- Ursprüngliche Nachricht -------- Von: David Maus Datum:02.06.2014 08:18 (GMT+01:00) An: dv-technik(a)dfg-viewer.de Cc: "'technik(a)dfg-viewer.de'" Betreff: Re: [DFG-Viewer] DFG-Viewer 3.0 veröffentlicht! Liebe Kolleginnen und Kollegen, Mir sind da zwei Dinge am METS-Anforderungsprofil aufgefallen. 1/ Reihenfolge der Kindelement von <dv:rights> und <dv:links> Beim Schreiben von Schemata für die o.g. Elemente[1] ist mir aufgefallen, dass das Anwendungsprofil keine Aussage über die Reihenfolge trifft, in der die Kindelement auftreten dürfen. Ist die Reihenfolge beliebig? 2/ Angabe eines Förderers Laut Anwendungsprofil sind die Angaben zum Förderer optional, der DFG-Viewer scheint aber mit der DFG als Standardwert zu arbeiten. Welche Möglichkeiten habe ich, um auszudrücken, dass die Information zum Förderer schlicht nicht vorliegt? Mit besten Grüßen, -- David Maus [1] https://gist.github.com/dmj/c498a161bf053a1ed550 At Fri, 30 May 2014 19:17:37 +0200, Meyer, Sebastian wrote: > > Liebe Kolleginnen und Kollegen, > > nach mehreren Ehrenrunden bei der Formatspezifikation und einer fast halbjährigen Testphase ist es endlich soweit: Version 3.0 des DFG-Viewers hat das Licht der Welt erblickt! > > Die Neuerungen sind neben zahllosen Detailverbesserungen und Fehlerkorrekturen: > > - Neben METS/MODS wird nun auch METS/TEI unterstützt, womit insbesondere digitalisierte mittelalterliche und frühneuzeitliche Handschriften im DFG-Viewer angezeigt werden können. [1] Grundsätzlich ist die Umsetzung jedoch so generisch, dass mit verhältnismäßig geringem Aufwand künftig auch noch weitere bibliographische Formate unterstützt werden können. > - Statt der drei festen Zoomstufen gibt es nun einen stufenlosen Zoom. Dieser bewegt sich außerdem immer innerhalb seines Containers und sprengt somit auch bei hohen Auflösungen nicht mehr den Bildschirm. > - Eine Vorschauansicht ist verfügbar, sofern in der METS-Datei eine Dateigruppe "THUMBS" vorhanden ist. Diese erlaubt die optische Navigation durch das Werk alternativ zum inhaltlichen Strukturbaum. > - Es werden nun auch deskriptive Metadaten untergeordneter Strukturelemente angezeigt statt nur diejenigen auf bibliographischer Titelebene. Diese zusätzlichen Informationen lassen sich (ebenso wie das Inhaltsverzeichnis) ein- und ausblenden. > > Alle Änderungen am DFG-Viewer sind voll abwärtskompatibel, so dass Sie keine Anpassungen an Ihren METS-Dateien vornehmen müssen. Einige der neuen Funktionen könnten allerdings zusätzliche Angaben erfordern (diese sind aber ausnahmslos optional). Entsprechend wurden die Anwendungsprofile für METS und MODS angepasst und ein neues Anwendungsprofil für TEI auf der Webseite ergänzt [2]. Ein Blick in die Dokumentation lohnt sich, da sich einige neue Möglichkeiten ergeben, die hier nicht im Detail aufgeführt sind! > > Im Kern des neuen DFG-Viewers werkelt nun Goobi.Presentation [3], die freie Präsentationskomponente der quelloffenen Goobi Digitalisierungssuite [4]. Dadurch arbeitet der Webservice um ein Vielfaches ressourceneffizienter und ist wesentlich flexibler konfigurierbar als zuvor, bleibt aber weiterhin quelloffen und frei nachnutzbar. Den Quellcode des DFG-Viewers finden Sie auf der Entwicklerplattform Github [5] sowie im TYPO3 Extension Repository [6]. Dort können Sie auch Fehler melden und Anregungen für die weitere Entwicklung loswerden. > > Die nächste Version des DFG-Viewers wird gegen Jahresende fertiggestellt sein und einige Anpassungen speziell für die Anzeige digitalisierter Zeitungen enthalten (z.B. eine kalendarische Navigation). Mein Kollege Alexander Bigga wird Sie darüber auf dem Laufenden halten und zu gegebener Zeit eine erste Testversion veröffentlichen. > > Viele Grüße > Sebastian Meyer > > [1] http://dfg-viewer.de/show/?tx_dlf[id]=http%3A%2F%2Ftest.dfg-viewer.de%2Ffil…<http://dfg-viewer.de/show/?tx_dlf%5bid%5d=http%3A%2F%2Ftest.dfg-viewer.de%2…> > [2] http://dfg-viewer.de/profil-der-metadaten/ > [3] http://typo3.org/extensions/repository/view/dlf > [4] http://www.goobi.org/ > [5] https://github.com/slub/dfg-viewer > [6] http://typo3.org/extensions/repository/view/dfgviewer > > -- > Sebastian Meyer > Referatsleiter Digitale Bibliothek > > Sächsische Landesbibliothek - > Staats- und Universitätsbibliothek Dresden (SLUB) > Abteilung IT, Referat Digitale Bibliothek > 01054 Dresden > Besucheradresse: Zellescher Weg 18 > Tel.: +49 351 4677 206 | Fax: +49 351 4677 711 > E-Mail: sebastian.meyer(a)slub-dresden.de<mailto:sebastian.meyer@slub-dresden.de> > > http://www.slub-dresden.de<http://www.slub-dresden.de/> > > -- David Maus Herzog August Bibliothek - D-38299 Wolfenbuettel Bibliothekarische IT / Digital Humanities Phone: +49-5331-808-317 Email: maus(a)hab.de PGP Key 0x7B4F5A762AF6FBA6 Fingerprint DD38 8D2E 34C1 94DE 2058 69BE 7B4F 5A76 2AF6 FBA6

10 years, 6 months

← Newer
1
...
6
7
8
9
10
11
12
...
33
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

DV-Technik