DV-Technik

dv-technik@dfg-viewer.de

329 discussions

Re: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer]

by Kay Heiligenhaus

Lieber Herr Stäcker, > Genau, schön, dass Sie es präzisieren. Das war in meiner Mail > missverstaendlich. In Ermangelungen anderer Resolver dachte ich, es > verstünde sich von selbst ;-) Gut. Da das immer und leicht durcheinander geht, war es mir nur wichtig, daß klar ist, daß wir über dieselben Dinge reden... > Jein, natürlich "steckt" da noch eine URN drin, aber das Ganze ist > natürlich keine URN mehr. Klar ist auch, dass der Modifier natürlich > nur funktioniert, wenn er dem Resolver der DNB übergeben wird, dem URN > Konzept selbst sind Modifier fremd und an anderen Resolvern würde es so > nicht funktionieren. So ist es. > Insofern kann man vielleicht die Persistenzaspekte auch noch einmal > etwas entspannter sehen. Wenn ich (möglichst persönlich) in 100 Jahren > noch zu der Ressource kommen will, muss es unerheblich sein, in welchem > Kontext sie angezeigt wird. Im heir und jetzt geht es erst einmal nur > um einen konkreten Nutungskontext von URNs, die in einer bestimmten Form > aufgelöst werden. Es an den Resolver der DNB zu koppeln macht > angesichts mangelender Alternativen aus meiner Sicht aber Sinn. Ja, das sehe ich auch so. Aus meinem Verständnis bestünde hier aber nur die Möglichkeit, die die DNB vorgeschlagen hat: Verlinkung auf eine Resolving-URL, die eine Liste der möglichen Ziele des _einen_ URN auflistet: http://nbn-resolving.org/urn:nbn:de:gbv:089-3321752945&n2ls Dies setzt aber voraus, daß man diese Alternativ-URLs an die DNB übermittelt hat (das Beispiel paßt in dieser Hinsicht nicht ganz, da die Alternativen hier die Archiv-Kopien der DNB sind, aber das Prinzip sollte "auf die Schnelle" klarwerden). Auch ist damit eben verbunden, daß der Nutzer dann immer eine Zwischenseite angezeigt bekommt und selbst eine Auswahl treffen muß. Andere Alternativen sehe ich nicht (die Verwendung mehrerer URNs, wie von Herrn Meyer als weitere Alternative ins Spiel gebracht, halte ich ebenfalls nicht für sachgerecht, wie Sie ja auch bereits ausgeführt haben). Letztlich muß man sich hier aber m.E. fragen, warum man nicht einfach die Anzeige im Viewer zur "Standardanzeigeform" macht, die via URN adressiert wird, gleich, aus welchem Kontext man kommt. Das ist ja der Weg, den wir in Halle gehen. Vom Viewer kommt man immer auch zur lokalen Präsentation und damit auch zu evtl. erweiterten Funktionalitäten der lokalen Anzeige. Natürlich kann man gegen diese "Standardanzeigeform" auch Gegenargumente ins Feld führen und sich eben die Funktionalität wünschen, die Sie hier intendieren. Bei Verwendung "nur" eines URN/PURL läßt sich das aber technisch nicht sauber machen - es sei denn, man verzweigt auf diese Zwischenseite. Beste Grüße, Kay Heiligenhaus

15 years, 8 months

Re: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer]

by Kay Heiligenhaus

Lieber Herr Stäcker, > > so ganz schlau werde ich aus Ihrem Mailwechsel mit der DNB noch > nicht. Ist es Ihr Ziel, daß URNs "kontextspezifisch" aufgelöst werden > können, je "nach Herkunft eines Klicks"? Also z.B. aus dem VD17 auf den > Viewer, aus dem OPAC auf den lokalen Bestand, aus dem Viewer selbst > wiederum auf den Viewer usw.? > > Genau so ist es. Idee war eigentlich, dass ein Nutzer, der sich im DFG > Viewer eine URN besorgt, auch wieder dorthin zurück gelangen kann und > nicht auf dem lokalen Angebot landet. Oh, dann reden wir aber - formal betrachten, was m.E. hier wichtig ist - nicht mehr über URNs, sondern a) über Resolving-URLs, die evtl. um Parameter angereichert werden, oder b) über eine URN-Auflösung zur einer Auswahlseite, die dann verschiedene Möglichkeiten des Zugangs anbietet. Einem URN selbst kann man nicht "ansehen", woher er kopiert wurde. Und wenn man ihm gleich eine Resolving-Adresse mit Parametern mitgibt, dann ist das kein URN mehr, sondern eben ein spezifischer URL, den der Nutzer sich kopiert. In dieser Hinsicht ist auch die Antwort der DNB nicht wirklich präzise, denn hier werden URNs und Resolving-URLs nicht klar voneinander abgegrenzt... Beste Grüße, Kay Heiligenhaus

15 years, 8 months

Re: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer]

by Kay Heiligenhaus

Lieber Herr Stäcker, so ganz schlau werde ich aus Ihrem Mailwechsel mit der DNB noch nicht. Ist es Ihr Ziel, daß URNs "kontextspezifisch" aufgelöst werden können, je "nach Herkunft eines Klicks"? Also z.B. aus dem VD17 auf den Viewer, aus dem OPAC auf den lokalen Bestand, aus dem Viewer selbst wiederum auf den Viewer usw.? 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 Dr. Thomas Staecker > Sent: Monday, April 27, 2009 5:02 PM > To: dv-technik(a)dfg-viewer.de > Subject: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer] > > Liebe Kolleginnen und Kollegen, > > ich leite Ihnen einmal hier einen Mailaustausch mit der DNB weiter zu > der Frage, ob wir eine Viewer bezogenen URN Resolver bekommen könnten. > Die Rückmeldung war nicht in jeder Hinsicht befriedigend, aber es gibt > einen Lösungsvorschlag mit dem Code "&n2ls", so dass man immerhin die > Viewerressource auswählen könnte. Meine Meinung dazu habe ich in der > Antwort kundgetan, die Ihrige würde mich interessieren. > > Viele Grüße, > Ihr > Th. Stäcker > > > > Sehr geehrte Frau XXX, > > haben Sie vielen Dank für Ihre Erläuterungen. Ich sehe schon, dass die > Sachlage etwas komplizierter ist, als man es sich wünschen möchte. > Aber dazu im Einzelnen: > > > > > > > Der Modifier &institution ist dafür vorgesehen (aber bisher noch > > nicht implementiert), dass bei Aufliegen eines Objektes bei > > verschiedenen Insitutionen (z. B. Forschungszentrum und > > Universitätsbibliothek) über die URN gesteuert werden kann, zu > > welchem Server aufgelöst wird. > > Der Modifier ist also für Ihre Anforderung nicht geeignet. > Eigentlich ist das, was Sie beschreiben, genau das, was wir benötigen > würden. Dieselbe Ressource liegt an zwei Orten und der Nutzer (oder der > Anbieter) kann per Code entscheiden, wie sie aufgelöst wird. Dabei wird > entscheidend sein, wo der Nutzer die Ressource gesehen hat. INsofern > finde ich es schade, dass Sie dieses Feature wohl nicht implementieren > werden. > > > > > Sie sollten vielmehr entscheiden, welche der genannten URLs die > "role=primary" > > erhält. Die Liste aller URLs erhalten Sie dann per Resolving mit dem > Modifier > > &N2Ls. > > Beispiel: > > http://nbn-resolving.de/urn:nbn:de:bsz:93-opus-59&n2ls > Eine Primary-Auflösung ist zwar möglich, bedeutet aber einen > Zwischenschritt, der vom Nutzer zu nehmen ist, da er aus einer Liste > auswählen muss. Schöner wäre es, wie gesagt, wenn die URN nach der > Quelle aufgelöst werden könnte, wo der Nutzer sie gefunden hat. Aber > immerhin ist diese Lösung denkbar. > > > > > Zur URL des DFG-Viewers: > > Wenn innerhalb einer URL eine andere URL aufgerufen wird (z. B. VG- > Wort > > Metis) haben wir schlechte Erfahrungen damit gemacht. Wir befürchten, > dass > > in diesen Fällen die URNs nicht auf die URLs aufgelöst werden können. > > Wenn Sie diese URLs verwenden möchten, müssen wir unbedingt einen > > Test dazu durchführen. > Möglicherweise verstehe ich das Problem nicht ganz, aber was gemacht > wird, ist doch nur, dass eine regelkonforme URL (dabei ist > gleichgültig, > ob diese URL wieder eine andere URL aufruft) mit einem Namen, der URN, > verbunden wird. Wenn sie also auf den Viewer resolven und dort geht > etwas schief, dann ist das doch eigentlich kein Problem des Resolvers > mehr, weil der Weg zum Viewer ja funktioniert hat. Genauso gut kann > auch > jede andere URL versagen. Oder verstehe ich das Problem nicht richtig? > > > > > Zum URN/URL-Eingabeformular: > > Die Veränderung der Längenbeschränkung für URL-Eingaben werden wir > > auf unsere ToDo-Liste aufnehmen. > Vielen Dank. > > Beste Grüße, > Ihr > Th. Stäcker > > > -- > Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung) > Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel > Tel. +49(0)5331/808-119 - email: staecker(a)hab.de >

15 years, 8 months

Re: [DFG-Viewer] Resolving für VD16/17-Nummern

by Kay Heiligenhaus

Lieber Herr Meyer, > ich bin gerade dabei, die noch ausstehende Verlinkung von VD16/17- > Nummern in die jeweiligen Datenbanken umzusetzen. Leider will mir > partout nicht mehr einfallen, auf welche Typenbezeichnung für die > Identifier wir uns zuletzt geeinigt hatten. Wir hatten uns m.W. auf "vd16" und "vd17" geeinigt. > Herr Heiligenhaus, Sie verwenden type="vda" für VD17-Nummern. Wie > würden Sie dann VD16-Nummern auszeichnen? Das "vda" ist bei uns historisch bedingt - im GBV wird dieser Typbezeichner bei SRU-Anfragen verwendet. Wäre nicht schlecht, wenn Sie das auch vorerst berücksichtigen könnten, ist aber nicht notwendig. Wir werden das mit einem kommenden Update auf "vd17" ändern. Bei VD16-Daten liefern wir jetzt bereits "vd16". > Oder gibt es einen gemeinsamen Resolver, so dass wir gar nicht zwischen VD16 und VD17 (und > künftigen VDs) unterscheiden müssen? Mir ist keiner bekannt und ich denke auch nicht, daß ein solcher existiert. Beste Grüße, Kay Heiligenhaus

15 years, 8 months

Resolving für VD16/17-Nummern

by Meyer, Sebastian

Liebe Kollegen, ich bin gerade dabei, die noch ausstehende Verlinkung von VD16/17-Nummern in die jeweiligen Datenbanken umzusetzen. Leider will mir partout nicht mehr einfallen, auf welche Typenbezeichnung für die Identifier wir uns zuletzt geeinigt hatten. Herr Heiligenhaus, Sie verwenden type="vda" für VD17-Nummern. Wie würden Sie dann VD16-Nummern auszeichnen? Oder gibt es einen gemeinsamen Resolver, so dass wir gar nicht zwischen VD16 und VD17 (und künftigen VDs) unterscheiden müssen? 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/

15 years, 8 months

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

15 years, 8 months

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

15 years, 8 months

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

15 years, 8 months

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

15 years, 8 months

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

15 years, 8 months

← Newer
1
...
20
21
22
23
24
25
26
...
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