Hallo Herr Heiligenhaus,
Kay Heiligenhaus schrieb am 02.09.2009 15:52:
Hallo Herr Funk,
Ihre Ausführungen kann ich nicht ganz nachvollziehen. Wenn Sie an den
Viewer Strukturdaten schicken, die nicht der vereinbarten
Strukturdatentypologie entsprechen, dann kann es zu allen möglichen
"Unschönheiten" kommen - aber dafür kann der Viewer doch nichts.
eigentlich wollte ich damit vermeiden, zwei METS-Dateien erzeugen zu müssen:
eine beispielsweise für zvdd und eine für den DFG-Viewer. Die "Unschönheiten"
würden ja aber sicher nur die Sprache betreffen...
Wir hatten das Thema "Mehrsprachigkeit" hier
schon oft diskutiert. Und die
probateste Lösung ist die, die Herr Meyer hier nun nochmals aufführt: Wenn
ein Label-Attribut angegeben ist, wird dessen Wert (unabhängig von der
gerade vom Nutzer gewählten Sprache) angezeigt. Wenn Label nicht vorhanden
ist, wird das Typ-Attribut ausgewertet und entsprechend der
Strukturdatenliste in die gerade ausgewählte Sprache
Das ist ja fein so, nur bin ich mir nicht sicher, ob der Typ noch davorgesetzt
werden soll, wenn ein Label existiert. Mit einem Typ in Englisch und einem
Titel in Deutsch könnte ich allerdings leben, wenn es in zukünftigen Versionen
die Möglichkeit gibt, auch Übersetzungen der Strukturtypen (und evtl. der
Labels) in die METS-Datei zu integrieren.
übersetzt. Über die Labels können Sie das Thema
Mehrsprachigkeit überhaupt
nicht lösen. Wie wollen Sie denn über OAI mitteilen, welche Sprache der
Viewernutzer gerade ausgewählt hat, um dann lokalisierte Labels zu
generieren?
Beste Grüße, Kay Heiligenhaus
Viele Grüße.
*fu*
Am 02.09.2009 um 13:59 schrieb "Stefan Funk"
<funk(a)sub.uni-goettingen.de>de>:
> Hallo liebe Liste.
>
> Eine kleine Unschönheit sehe ich hier mit verschiedenen Sprachen: Habe
> ich einen deutschen Titel und die Strukturtypen sind beispielsweise aus
> zvdd, dann wären diese Englisch. Der Viewer übersetzt, soweit ich weiß,
> nur die DFG-Viewer-Typen. Es wäre meiner Meinung nach sehr unpraktisch,
> dann die zvdd-Typen in der METS-Datei übersetzen zu müssen. Das wäre dann
> evtl. wieder die Sache des Labels, man könnte den Typ ja auch übersetzt
> in das Label schreiben (also "Typ: Label" als Label).
>
> Solange wir keine Regelung für Mehrsprachigkeit für Strukturtypen haben,
> würde ich daher gerne nur das Label anzeigen lassen.
>
> Viele Grüße. *fu*
> Meyer, Sebastian schrieb am 02.09.2009 13:36:
>> Lieber Herr Staecker,
>>
>> über die Behandlung von @TYPE und @LABEL im Viewer hatten wir uns vor
>> einiger Zeit schonmal (ich glaub in Halle) unterhalten. Damals hatten
>> wir die Entscheidung getroffen, dass in der Navigation immer bevorzugt
>> das Label angezeigt werden solle. Nur wenn das Attribut nicht
>> existiert, soll stattdessen der Typ (in entsprechender Übersetzung laut
>> Strukturdatenset) angezeigt werden. Ursprünglich war es mal so, dass
>> der Viewer immer "Typ: Label" angezeigt hat. Das wurde aber glaube ich
>> kritisiert, weil die Bezeichnungen dadurch teilweise recht lang wurden
>> und auch Dopplungen der Art "Titelseite: Titelseite" auftraten. (Wobei
>> ich es für falsch halte, in @LABEL reine Deskriptoren unterzubringen.
>> Diese Information steckt doch bereits in @TYPE und muss nicht nochmal
>> in @LABEL wiederholt werden. Was die Dopplungen betrifft, sehe ich den
>> Fehler also nicht beim Viewer, sondern beim Ersteller der METS-Datei.)
>>
>> Mein Vorschlag wäre deshalb, zum alten Verhalten des Viewers
>> zurückzukehren und immer "Typ: Label" in der Navigation anzuzeigen
>> (bzw. nur "Typ", falls kein @LABEL vergeben wurde). Die Vermeidung von
>> Dopplungen obliegt dann dem Datenlieferanten, der @LABEL nicht belegen
>> sollte, wenn die Information zu der in @TYPE redundant ist.
>>
>> Viele Grüße Sebastian Meyer
>> ________________________________ Von:
dv-technik-bounces(a)dfg-viewer.de
>> [dv-technik-bounces(a)dfg-viewer.de] im Auftrag von Thomas Stäcker
>> [staecker(a)hab.de] Gesendet: Mittwoch, 2. September 2009 07:42 An:
>> dv-technik(a)dfg-viewer.de Cc: Torsten Schaßan Betreff: Re: [DFG-Viewer]
>> Strukturdaten
>>
>> Lieber Herr Meyer, liebe Kollegen,
>>
>> sorry, ich war etwas vorschnell und wiegte mich wegen der positiven
>> Validierung in Sicherheit. Unser Skript hatte noch Mängel und bildete
>> die Strukturdaten im structLink Bereich nur auf der obersten
>> Hierarchiestufe ab. Das konnte natürlich dann trotz korrekter logical
>> structMap nicht gelingen. Jetzt ist alles OK, vgl. z.B.
>>
>>
http://dbs.hab.de/oai/wdb/?verb=GetRecord&metadataPrefix=mets&ident…
>>
>>
>>
>>
>> Ich möchte noch zwei Bemerkungen dazu anschließen.
>>
>> a) um eine zur Viewerliste-Strukturdatenliste konforme Ausgabe zu
>> erhalten, wird durch ein XSLT Skript geprüft, ob der Begriff, der in
>> unserer XML Strukturdatendatei, vorkommt und zumeist der Liste
>>
http://diglib.hab.de/rules/concordance/structMD.xml entnommen ist
>> (Alternative fachspezifische Listen s.
>>
http://www.hab.de/bibliothek/wdb/doku/lists.htm#thesauri), den
>> Indikator n="dfg-viewer" traegt. Wenn ja, wird der Begriff in xml:id
>> unserer Liste in @TYPE der <DIV> in <structMap> übernommen, der
Begriff
>> in <term xml:lang="de"> in @LABEL. Ist der Begriff vorhanden, hat
aber
>> nicht den Indikator n="dfg-viewer" wird nach einem Verweis gesucht
>> (z.B. verweist introduction auf preface) und dann der Viewer konforme
>> Begriff verwendet. Entsprechendes könnte für zvdd konforme Begriffe
>> gemacht werden (dazu brauchen wir dann noch einen Steuerungsindikator
>> oder überlegen, ob wir es über die behavior-section in METS lösen
>> können). Gibt es keinen Verweis und sonstwie keine Zuordnung wird das
>> Paar section/Abschnitt verwendet (dies vielleicht für die interessant,
>> die auf der Basis von TEI und/oder unserer XML Strukturdatenliste
>> arbeiten wollen).
>>
>> b) ich finde die Behandlung von @TYPE und @LABEL in der Anzeige noch
>> nicht ganz glücklich. Derzeit wird nur LABEL begrücksichtigt. Das
>> verkürzt aber die Information, die gebracht werden könnte und müsste.
>> Zum einen könnte auf der Basis unserer Vereinbarung die XML-IDs der
>> Viewerliste in @TYPE schreiben, mehrer Sprachen bedient werden. Vgl.
>> bei uns
http://diglib.hab.de/wdb.php?dir=drucke/nd-24&lang=de und
>>
http://diglib.hab.de/wdb.php?dir=drucke/nd-24&lang=eng=en. Zum anderen
>> besteht ein Problem der reinen @LABEL Darstellung darin, dass wir nicht
>> zwischen textlichen Inhalten und Deskriptoren unterscheiden können.
>> Wenn @LABEL den Inhalt einer Überschrift enthält, weiss man nicht mehr,
>> dass es sich um eine Überschrift handelt, es könnte auch ein Abschnitt
>> oder anderes sein (im obigen OAI Beispiel <mets:div
>> ID="logMD_515681113_8" TYPE="preface" LABEL="Avis, Sur
les dessein, &
>> sur l'ordre de ce Recueil"
>>> </mets:div> ).
>> Wenn ich recht sehe wird es in Halle auch so kodiert. Was wir an dieser
>> Stelle bräuchten, ist m.E. eine Anzeige der Form @TYPE: @LABEL
>> (preface: Avis...) oder eigentlich besser: Vorrede: Avis... Nun wäre
>> das aber bei den Deskriptoren unschön: illustration:Illustration. Eine
>> sinnvolle Alternative könnte darin bestehen mit Unterordnungen zu
>> arbeiten:
>>
>> <mets:div ID="logMD_515681113_8" TYPE="preface"
LABEL="Vorrede" >
>> <mets:div ID="logMD_515681113_8" TYPE="preface"
LABEL="Avis, Sur les
>> dessein, & sur l'ordre de ce Recueil" ></mets:div>
</mets:div>
>>
>> Was schlagen Sie vor?
>>
>> Viele Grüße, Ihr Th. Stäcker
>>
>> Thomas Stäcker schrieb:
>>> Lieber Herr Meyer,
>>>
>>> die neue Version ist wunderbar, besonders die Doppelseitenansicht
>>> gefällt mir sehr gut. Leider werden die Strukturdaten werden bei mir
>>> nur auf der obersten Hierachieebene angezeigt (Validation ist aber
>>> korrekt). Wenn Sie einmal
>>>
>>>
http://test.dfg-viewer.de/demo/viewer/?set[image]=372&set[zoom]=min&…
>>>
>>>
>>>
>>>
>>>
>>> mit
>>>
>>>
http://diglib.hab.de/drucke/nd-24/start.htm
>>>
>>> vergleichen, sehen Sie, dass das meiste weggefallen ist.
>>>
>>> Viele Grüße, Ihr Th. Stäcker
--
Stefan E. Funk
DP-D - Diensteportal Digitalisierung
Goettingen State and University Library - The Historical Library Building
Papendiek 14, 37073 Goettingen, Germany
Phone: +49 551 39-7700 | 39-12170
Mail: funk(a)sub.uni-goettingen.de