3 Dec
2008
3 Dec
'08
4:11 p.m.
Liebe Kolleginnen und Kollegen,
der METS/MODS-Validator ist nun weitestgehend fertig und kann unter folgender URL getestet
werden:
http://194.95.142.95/fileadmin/statics/validator/metsmods.php
Der Validator basiert auf den kürzlich von den Göttinger Kollegen freigegebenen METS- und
MODS-Profilen für den Einsatz im Rahmen des DFG-Viewers und ZVDD. Die Validierung findet
dabei in mehreren Schritten statt und gibt bei invaliden Dokumenten Hinweise zum Fehler
aus.
Eine Integration in die Webseite des DFG-Viewers soll im Laufe der kommenden Woche
erfolgen.
Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde ich mich freuen.
Viele Grüße aus Dresden
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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/
___________________________________________________
4 Dec
4 Dec
3:09 p.m.
Lieber Herr Meyer,
wunderbar! Sehr schönes tool. Auf die Schnelle eine erste kurze Rückmeldung.
Eine Fehlermeldung, die nach meiner Ansicht nicht ganz optimal ist:
"Verstoß gegen ZVDD Vorgaben [1] (Teildokument #1)
Warnung! In relatedItem Elementen des Typs series wird die Verwendung
des part/detail/number Elements emfohlen."
Es handelt sich dabei um Folgendes:
<mods:relatedItem type="series" >
<mods:titleInfo>
<mods:title>Digitalisierung naturwissenschaftlicher, technischer und
medizinischer Texte der Leibnizzeit, Projekt der Herzog August
Bibliothek</mods:title>
</mods:titleInfo>
<mods:identifier type="purl"
</mods:relatedItem>
part/detail/number zu verlangen ist ein wenig problematisch, wenn man
davon ausgeht, dass es eine gezählte Serie sein muss. Das ist aber bei
diesen Projekten eigentlich unnötig.
Dann auch die Frage, ob es sprachlich "ZVDD Vorgaben" heissen muss, wenn
es der validator des Viewers ist. Würde ich neutraler benennen: "Verstoß
gegen [1]..."
Dann:
"Verstoß gegen ZVDD Vorgaben [3] (Teildokument #1)
Warnung! Das titleInfo Element sollte exakt 1 subTitle Element
enthalten, falls geeignete Daten vorliegen."
Finde ich überflüssig ebenso wie
"Verstoß gegen ZVDD Vorgaben [4] (Teildokument #1)
Warnung! Es wird empfphlen das nonSort Element in titleInfo Elementen zu
verwenden."
ebenso wie
"Verstoß gegen ZVDD Vorgaben [7] (Teildokument #1)
Warnung! Das MODS Dokument sollte mind. 1 name Element mit dem type
Attributwert corporate enthalten, wenn geeignete Daten vorliegen."
Insgesamt wäre es schön, wenn man zum Debugging die Zeilen der Fehler
bekäme.
Zuletzt noch die neugierige Frage, welcher Parser zum Einsatz kommt.
Viele Gruesse,
Th. Staecker
Meyer, Sebastian schrieb:
Liebe Kolleginnen und Kollegen,
der METS/MODS-Validator ist nun weitestgehend fertig und kann unter folgender URL
getestet werden:
http://194.95.142.95/fileadmin/statics/validator/metsmods.php
Der Validator basiert auf den kürzlich von den Göttinger Kollegen freigegebenen METS- und
MODS-Profilen für den Einsatz im Rahmen des DFG-Viewers und ZVDD. Die Validierung findet
dabei in mehreren Schritten statt und gibt bei invaliden Dokumenten Hinweise zum Fehler
aus.
Eine Integration in die Webseite des DFG-Viewers soll im Laufe der kommenden Woche
erfolgen.
Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde ich mich freuen.
Viele Grüße aus Dresden
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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/
___________________________________________________
--
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
10 Dec
10 Dec
11:05 a.m.
Lieber Herr Staecker,
vielen Dank für Ihre Hinweise. Ich würde allen angesprochenen Punkten lediglich sprachlich
begegnen wollen. Statt von "ZVDD Vorgaben" zu sprechen, schlage ich die
allgemeinere Formulierung "Profil-Vorgaben" vor. Damit wäre der Validator sowohl
im Kontext des DFG-Viewers als auch im Kontext von ZVDD nutzbar.
Die anderen von Ihnen angemerkten Fehlermeldungen des Validators würde ich gerne nicht
völlig ausblenden, sondern lediglich sprachlich etwas entschärfen: statt einen
"Verstoß gegen Profil-Vorgaben" anzumahnen, könnte der Validator lediglich einen
neutralen "Hinweis" oder "Tipp" ausgeben.
Insgesamt wäre es schön, wenn man zum Debugging die
Zeilen der Fehler
bekäme.
Zumindest bei den Schema-basierten Prüfungen sollte das der Fall sein. Warum es bei den
anderen Prüfungen nicht funktioniert, weiß ich auch nicht. Da werde ich nochmal mit dem
Entwickler sprechen.
Viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] Im Auftrag von Dr. Thomas Staecker
> Gesendet: Donnerstag, 4. Dezember 2008 15:10
> An: technik(a)dfg-viewer.de
> Betreff: Re: [DFG-Viewer] METS/MODS-Validator
>
> Lieber Herr Meyer,
>
> wunderbar! Sehr schönes tool. Auf die Schnelle eine erste kurze
> Rückmeldung.
>
> Eine Fehlermeldung, die nach meiner Ansicht nicht ganz optimal ist:
>
> "Verstoß gegen ZVDD Vorgaben [1] (Teildokument #1)
> Warnung! In relatedItem Elementen des Typs series wird die Verwendung
> des part/detail/number Elements emfohlen."
>
> Es handelt sich dabei um Folgendes:
>
> <mods:relatedItem type="series" >
> <mods:titleInfo>
> <mods:title>Digitalisierung naturwissenschaftlicher, technischer und
> medizinischer Texte der Leibnizzeit, Projekt der Herzog August
> Bibliothek</mods:title>
> </mods:titleInfo>
> <mods:identifier type="purl"
> >http://diglib.hab.de/?link=011</mods:identifier>
> </mods:relatedItem>
>
>
> part/detail/number zu verlangen ist ein wenig problematisch, wenn man
> davon ausgeht, dass es eine gezählte Serie sein muss. Das ist aber bei
> diesen Projekten eigentlich unnötig.
>
> Dann auch die Frage, ob es sprachlich "ZVDD Vorgaben" heissen muss,
> wenn
> es der validator des Viewers ist. Würde ich neutraler benennen:
> "Verstoß
> gegen [1]..."
>
> Dann:
>
> "Verstoß gegen ZVDD Vorgaben [3] (Teildokument #1)
> Warnung! Das titleInfo Element sollte exakt 1 subTitle Element
> enthalten, falls geeignete Daten vorliegen."
>
> Finde ich überflüssig ebenso wie
>
> "Verstoß gegen ZVDD Vorgaben [4] (Teildokument #1)
> Warnung! Es wird empfphlen das nonSort Element in titleInfo Elementen
> zu
> verwenden."
>
> ebenso wie
>
> "Verstoß gegen ZVDD Vorgaben [7] (Teildokument #1)
> Warnung! Das MODS Dokument sollte mind. 1 name Element mit dem type
> Attributwert corporate enthalten, wenn geeignete Daten vorliegen."
>
Insgesamt wäre es schön, wenn man zum Debugging die
Zeilen der Fehler
bekäme.
>
> Zuletzt noch die neugierige Frage, welcher Parser zum Einsatz kommt.
>
>
> Viele Gruesse,
> Th. Staecker
>
>
>
>
>
> Meyer, Sebastian schrieb:
> > Liebe Kolleginnen und Kollegen,
> >
> > der METS/MODS-Validator ist nun weitestgehend fertig und kann unter
> folgender URL getestet werden:
> >
> > http://194.95.142.95/fileadmin/statics/validator/metsmods.php
> >
> > Der Validator basiert auf den kürzlich von den Göttinger Kollegen
> freigegebenen METS- und MODS-Profilen für den Einsatz im Rahmen des
> DFG-Viewers und ZVDD. Die Validierung findet dabei in mehreren
> Schritten statt und gibt bei invaliden Dokumenten Hinweise zum Fehler
> aus.
> >
> > Eine Integration in die Webseite des DFG-Viewers soll im Laufe der
> kommenden Woche erfolgen.
> >
> > Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde
> ich mich freuen.
> >
> > Viele Grüße aus Dresden
> > Sebastian Meyer
> >
> > --
> > ___________________________________________________
> >
> > Sebastian Meyer
> >
> > Abteilung Informationstechnologie
> > 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/
> > ___________________________________________________
> >
> >
>
>
> --
> 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
11:27 a.m.
Lieber Herr Meyer,
Meyer, Sebastian schrieb:
Danke!
Ach ja, nur der Neugierde halber, welcher Parser werkelt hier im
Hinetrgrund, saxon, libxml?
Beste Gruesse,
Ihr
Th. Staecker
> --
> ___________________________________________________
> Sebastian Meyer
> Abteilung Informationstechnologie
> 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: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
>> viewer.de] Im Auftrag von Dr. Thomas Staecker
>> Gesendet: Donnerstag, 4. Dezember 2008 15:10
>> An: technik(a)dfg-viewer.de
>> Betreff: Re: [DFG-Viewer] METS/MODS-Validator
>>
>> Lieber Herr Meyer,
>>
>> wunderbar! Sehr schönes tool. Auf die Schnelle eine erste kurze
>> Rückmeldung.
>>
>> Eine Fehlermeldung, die nach meiner Ansicht nicht ganz optimal ist:
>>
>> "Verstoß gegen ZVDD Vorgaben [1] (Teildokument #1)
>> Warnung! In relatedItem Elementen des Typs series wird die Verwendung
>> des part/detail/number Elements emfohlen."
>>
>> Es handelt sich dabei um Folgendes:
>>
>> <mods:relatedItem type="series" >
>> <mods:titleInfo>
>> <mods:title>Digitalisierung naturwissenschaftlicher, technischer und
>> medizinischer Texte der Leibnizzeit, Projekt der Herzog August
>> Bibliothek</mods:title>
>> </mods:titleInfo>
>> <mods:identifier type="purl"
>> >http://diglib.hab.de/?link=011</mods:identifier>
>> </mods:relatedItem>
>>
>>
>> part/detail/number zu verlangen ist ein wenig problematisch, wenn man
>> davon ausgeht, dass es eine gezählte Serie sein muss. Das ist aber bei
>> diesen Projekten eigentlich unnötig.
>>
>> Dann auch die Frage, ob es sprachlich "ZVDD Vorgaben" heissen muss,
>> wenn
>> es der validator des Viewers ist. Würde ich neutraler benennen:
>> "Verstoß
>> gegen [1]..."
>>
>> Dann:
>>
>> "Verstoß gegen ZVDD Vorgaben [3] (Teildokument #1)
>> Warnung! Das titleInfo Element sollte exakt 1 subTitle Element
>> enthalten, falls geeignete Daten vorliegen."
>>
>> Finde ich überflüssig ebenso wie
>>
>> "Verstoß gegen ZVDD Vorgaben [4] (Teildokument #1)
>> Warnung! Es wird empfphlen das nonSort Element in titleInfo Elementen
>> zu
>> verwenden."
>>
>> ebenso wie
>>
>> "Verstoß gegen ZVDD Vorgaben [7] (Teildokument #1)
>> Warnung! Das MODS Dokument sollte mind. 1 name Element mit dem type
>> Attributwert corporate enthalten, wenn geeignete Daten vorliegen."
>>
>> Insgesamt wäre es schön, wenn man zum Debugging die Zeilen der Fehler
>> bekäme.
>>
>> Zuletzt noch die neugierige Frage, welcher Parser zum Einsatz kommt.
>>
>>
>> Viele Gruesse,
>> Th. Staecker
>>
>>
>>
>>
>>
>> Meyer, Sebastian schrieb:
>>> Liebe Kolleginnen und Kollegen,
>>>
>>> der METS/MODS-Validator ist nun weitestgehend fertig und kann unter
>> folgender URL getestet werden:
>>> http://194.95.142.95/fileadmin/statics/validator/metsmods.php
>>>
>>> Der Validator basiert auf den kürzlich von den Göttinger Kollegen
>> freigegebenen METS- und MODS-Profilen für den Einsatz im Rahmen des
>> DFG-Viewers und ZVDD. Die Validierung findet dabei in mehreren
>> Schritten statt und gibt bei invaliden Dokumenten Hinweise zum Fehler
>> aus.
>>> Eine Integration in die Webseite des DFG-Viewers soll im Laufe der
>> kommenden Woche erfolgen.
>>> Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde
>> ich mich freuen.
>>> Viele Grüße aus Dresden
>>> Sebastian Meyer
>>>
>>> --
>>> ___________________________________________________
>>>
>>> Sebastian Meyer
>>>
>>> Abteilung Informationstechnologie
>>> 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/
>>> ___________________________________________________
>>>
>>>
>>
>> --
>> 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
--
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
Lieber Herr Staecker,
vielen Dank für Ihre Hinweise. Ich würde allen angesprochenen Punkten lediglich
sprachlich begegnen wollen. Statt von "ZVDD Vorgaben" zu sprechen, schlage ich
die allgemeinere Formulierung "Profil-Vorgaben" vor. Damit wäre der Validator
sowohl im Kontext des DFG-Viewers als auch im Kontext von ZVDD nutzbar.
Ja, das finde ich einen sehr guten Vorschlag.
Die anderen von Ihnen angemerkten Fehlermeldungen des
Validators würde ich gerne nicht völlig ausblenden, sondern lediglich sprachlich etwas
entschärfen: statt einen "Verstoß gegen Profil-Vorgaben" anzumahnen, könnte der
Validator lediglich einen neutralen "Hinweis" oder "Tipp" ausgeben.
Ja, ich habe mich eigentlich auch nur an dem Verstoss "gestossen". Tipp
ist sehr gut und lenkt den Nutzer, der es will, auf die richtige Spur.
Insgesamt wäre es schön, wenn man zum Debugging
die Zeilen der Fehler
bekäme.
Zumindest bei den Schema-basierten Prüfungen sollte das der Fall sein. Warum es bei den
anderen Prüfungen nicht funktioniert, weiß ich auch nicht. Da werde ich nochmal mit dem
Entwickler sprechen.
11:40 a.m.
Lieber Herr Staecker,
Ach ja, nur der Neugierde halber, welcher Parser
werkelt hier im
Hinetrgrund, saxon, libxml?
der Validator verwendet die DOM XML-Erweiterung von PHP (via libxml).
Viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] Im Auftrag von Dr. Thomas Staecker
> Gesendet: Mittwoch, 10. Dezember 2008 11:28
> An: technik(a)dfg-viewer.de
> Betreff: Re: [DFG-Viewer] METS/MODS-Validator
>
> Lieber Herr Meyer,
>
> Meyer, Sebastian schrieb:
> > Lieber Herr Staecker,
> >
> > vielen Dank für Ihre Hinweise. Ich würde allen angesprochenen Punkten
> lediglich sprachlich begegnen wollen. Statt von "ZVDD Vorgaben" zu
> sprechen, schlage ich die allgemeinere Formulierung "Profil-Vorgaben"
> vor. Damit wäre der Validator sowohl im Kontext des DFG-Viewers als
> auch im Kontext von ZVDD nutzbar.
>
> Ja, das finde ich einen sehr guten Vorschlag.
> > Die anderen von Ihnen angemerkten Fehlermeldungen des Validators
> würde ich gerne nicht völlig ausblenden, sondern lediglich sprachlich
> etwas entschärfen: statt einen "Verstoß gegen Profil-Vorgaben"
> anzumahnen, könnte der Validator lediglich einen neutralen "Hinweis"
> oder "Tipp" ausgeben.
>
> Ja, ich habe mich eigentlich auch nur an dem Verstoss "gestossen". Tipp
> ist sehr gut und lenkt den Nutzer, der es will, auf die richtige Spur.
> >
> >> Insgesamt wäre es schön, wenn man zum Debugging die Zeilen der
> Fehler
> >> bekäme.
> >
> > Zumindest bei den Schema-basierten Prüfungen sollte das der Fall
> sein. Warum es bei den anderen Prüfungen nicht funktioniert, weiß ich
> auch nicht. Da werde ich nochmal mit dem Entwickler sprechen.
> Danke!
>
Ach ja, nur der Neugierde halber, welcher Parser
werkelt hier im
Hinetrgrund, saxon, libxml?
> >
>
> Beste Gruesse,
> Ihr
> Th. Staecker
> > --
> > ___________________________________________________
> >
> > Sebastian Meyer
> >
> > Abteilung Informationstechnologie
> > 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: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-
> bounces@dfg-
> >> viewer.de] Im Auftrag von Dr. Thomas Staecker
> >> Gesendet: Donnerstag, 4. Dezember 2008 15:10
> >> An: technik(a)dfg-viewer.de
> >> Betreff: Re: [DFG-Viewer] METS/MODS-Validator
> >>
> >> Lieber Herr Meyer,
> >>
> >> wunderbar! Sehr schönes tool. Auf die Schnelle eine erste kurze
> >> Rückmeldung.
> >>
> >> Eine Fehlermeldung, die nach meiner Ansicht nicht ganz optimal ist:
> >>
> >> "Verstoß gegen ZVDD Vorgaben [1] (Teildokument #1)
> >> Warnung! In relatedItem Elementen des Typs series wird die
> Verwendung
> >> des part/detail/number Elements emfohlen."
> >>
> >> Es handelt sich dabei um Folgendes:
> >>
> >> <mods:relatedItem type="series" >
> >> <mods:titleInfo>
> >> <mods:title>Digitalisierung naturwissenschaftlicher, technischer und
> >> medizinischer Texte der Leibnizzeit, Projekt der Herzog August
> >> Bibliothek</mods:title>
> >> </mods:titleInfo>
> >> <mods:identifier type="purl"
> >> >http://diglib.hab.de/?link=011</mods:identifier>
> >> </mods:relatedItem>
> >>
> >>
> >> part/detail/number zu verlangen ist ein wenig problematisch, wenn
> man
> >> davon ausgeht, dass es eine gezählte Serie sein muss. Das ist aber
> bei
> >> diesen Projekten eigentlich unnötig.
> >>
> >> Dann auch die Frage, ob es sprachlich "ZVDD Vorgaben" heissen
muss,
> >> wenn
> >> es der validator des Viewers ist. Würde ich neutraler benennen:
> >> "Verstoß
> >> gegen [1]..."
> >>
> >> Dann:
> >>
> >> "Verstoß gegen ZVDD Vorgaben [3] (Teildokument #1)
> >> Warnung! Das titleInfo Element sollte exakt 1 subTitle Element
> >> enthalten, falls geeignete Daten vorliegen."
> >>
> >> Finde ich überflüssig ebenso wie
> >>
> >> "Verstoß gegen ZVDD Vorgaben [4] (Teildokument #1)
> >> Warnung! Es wird empfphlen das nonSort Element in titleInfo
> Elementen
> >> zu
> >> verwenden."
> >>
> >> ebenso wie
> >>
> >> "Verstoß gegen ZVDD Vorgaben [7] (Teildokument #1)
> >> Warnung! Das MODS Dokument sollte mind. 1 name Element mit dem type
> >> Attributwert corporate enthalten, wenn geeignete Daten vorliegen."
> >>
> >> Insgesamt wäre es schön, wenn man zum Debugging die Zeilen der
> Fehler
> >> bekäme.
> >>
> >> Zuletzt noch die neugierige Frage, welcher Parser zum Einsatz kommt.
> >>
> >>
> >> Viele Gruesse,
> >> Th. Staecker
> >>
> >>
> >>
> >>
> >>
> >> Meyer, Sebastian schrieb:
> >>> Liebe Kolleginnen und Kollegen,
> >>>
> >>> der METS/MODS-Validator ist nun weitestgehend fertig und kann unter
> >> folgender URL getestet werden:
> >>> http://194.95.142.95/fileadmin/statics/validator/metsmods.php
> >>>
> >>> Der Validator basiert auf den kürzlich von den Göttinger Kollegen
> >> freigegebenen METS- und MODS-Profilen für den Einsatz im Rahmen des
> >> DFG-Viewers und ZVDD. Die Validierung findet dabei in mehreren
> >> Schritten statt und gibt bei invaliden Dokumenten Hinweise zum
> Fehler
> >> aus.
> >>> Eine Integration in die Webseite des DFG-Viewers soll im Laufe der
> >> kommenden Woche erfolgen.
> >>> Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde
> >> ich mich freuen.
> >>> Viele Grüße aus Dresden
> >>> Sebastian Meyer
> >>>
> >>> --
> >>> ___________________________________________________
> >>>
> >>> Sebastian Meyer
> >>>
> >>> Abteilung Informationstechnologie
> >>> 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/
> >>> ___________________________________________________
> >>>
> >>>
> >>
> >> --
> >> 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
> >
>
>
> --
> 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
5:21 p.m.
Kurze Frage zu der eigentlichen Validierung:
Ist die irgendwie konfigurierbar oder ist die hard-codiert?
Ich frage vor dem Hintergrund, dass ja immer mal wieder verlangt wird, maschine-readable
METS-Profile generieren zu koennen, die dann u.a. auch zur Validierung genutzt werden
sollen.
Bislang gibt es dort nichts in den METS-Profilen. Mir ist auch nicht klar wie ein Ansatz
aussehen koennte. Daher die Frage, wie der Validator das macht.
Ciao
Markus
-----Original Message-----
From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-viewer.de] On Behalf
Of Meyer, Sebastian
Sent: 10 December 2008 10:41
To: technik(a)dfg-viewer.de
Subject: Re: [DFG-Viewer] METS/MODS-Validator
Lieber Herr Staecker,
Ach ja, nur der Neugierde halber, welcher Parser
werkelt hier im
Hinetrgrund, saxon, libxml?
der Validator verwendet die DOM XML-Erweiterung von PHP (via libxml).
Viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] Im Auftrag von Dr. Thomas Staecker
> Gesendet: Mittwoch, 10. Dezember 2008 11:28
> An: technik(a)dfg-viewer.de
> Betreff: Re: [DFG-Viewer] METS/MODS-Validator
>
> Lieber Herr Meyer,
>
> Meyer, Sebastian schrieb:
> > Lieber Herr Staecker,
> >
> > vielen Dank für Ihre Hinweise. Ich würde allen angesprochenen Punkten
> lediglich sprachlich begegnen wollen. Statt von "ZVDD Vorgaben" zu
> sprechen, schlage ich die allgemeinere Formulierung "Profil-Vorgaben"
> vor. Damit wäre der Validator sowohl im Kontext des DFG-Viewers als
> auch im Kontext von ZVDD nutzbar.
>
> Ja, das finde ich einen sehr guten Vorschlag.
> > Die anderen von Ihnen angemerkten Fehlermeldungen des Validators
> würde ich gerne nicht völlig ausblenden, sondern lediglich sprachlich
> etwas entschärfen: statt einen "Verstoß gegen Profil-Vorgaben"
> anzumahnen, könnte der Validator lediglich einen neutralen "Hinweis"
> oder "Tipp" ausgeben.
>
> Ja, ich habe mich eigentlich auch nur an dem Verstoss "gestossen". Tipp
> ist sehr gut und lenkt den Nutzer, der es will, auf die richtige Spur.
> >
> >> Insgesamt wäre es schön, wenn man zum Debugging die Zeilen der
> Fehler
> >> bekäme.
> >
> > Zumindest bei den Schema-basierten Prüfungen sollte das der Fall
> sein. Warum es bei den anderen Prüfungen nicht funktioniert, weiß ich
> auch nicht. Da werde ich nochmal mit dem Entwickler sprechen.
> Danke!
>
Ach ja, nur der Neugierde halber, welcher Parser
werkelt hier im
Hinetrgrund, saxon, libxml?
> >
>
> Beste Gruesse,
> Ihr
> Th. Staecker
> > --
> > ___________________________________________________
> >
> > Sebastian Meyer
> >
> > Abteilung Informationstechnologie
> > 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: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-
> bounces@dfg-
> >> viewer.de] Im Auftrag von Dr. Thomas Staecker
> >> Gesendet: Donnerstag, 4. Dezember 2008 15:10
> >> An: technik(a)dfg-viewer.de
> >> Betreff: Re: [DFG-Viewer] METS/MODS-Validator
> >>
> >> Lieber Herr Meyer,
> >>
> >> wunderbar! Sehr schönes tool. Auf die Schnelle eine erste kurze
> >> Rückmeldung.
> >>
> >> Eine Fehlermeldung, die nach meiner Ansicht nicht ganz optimal ist:
> >>
> >> "Verstoß gegen ZVDD Vorgaben [1] (Teildokument #1)
> >> Warnung! In relatedItem Elementen des Typs series wird die
> Verwendung
> >> des part/detail/number Elements emfohlen."
> >>
> >> Es handelt sich dabei um Folgendes:
> >>
> >> <mods:relatedItem type="series" >
> >> <mods:titleInfo>
> >> <mods:title>Digitalisierung naturwissenschaftlicher, technischer und
> >> medizinischer Texte der Leibnizzeit, Projekt der Herzog August
> >> Bibliothek</mods:title>
> >> </mods:titleInfo>
> >> <mods:identifier type="purl"
> >> >http://diglib.hab.de/?link=011</mods:identifier>
> >> </mods:relatedItem>
> >>
> >>
> >> part/detail/number zu verlangen ist ein wenig problematisch, wenn
> man
> >> davon ausgeht, dass es eine gezählte Serie sein muss. Das ist aber
> bei
> >> diesen Projekten eigentlich unnötig.
> >>
> >> Dann auch die Frage, ob es sprachlich "ZVDD Vorgaben" heissen
muss,
> >> wenn
> >> es der validator des Viewers ist. Würde ich neutraler benennen:
> >> "Verstoß
> >> gegen [1]..."
> >>
> >> Dann:
> >>
> >> "Verstoß gegen ZVDD Vorgaben [3] (Teildokument #1)
> >> Warnung! Das titleInfo Element sollte exakt 1 subTitle Element
> >> enthalten, falls geeignete Daten vorliegen."
> >>
> >> Finde ich überflüssig ebenso wie
> >>
> >> "Verstoß gegen ZVDD Vorgaben [4] (Teildokument #1)
> >> Warnung! Es wird empfphlen das nonSort Element in titleInfo
> Elementen
> >> zu
> >> verwenden."
> >>
> >> ebenso wie
> >>
> >> "Verstoß gegen ZVDD Vorgaben [7] (Teildokument #1)
> >> Warnung! Das MODS Dokument sollte mind. 1 name Element mit dem type
> >> Attributwert corporate enthalten, wenn geeignete Daten vorliegen."
> >>
> >> Insgesamt wäre es schön, wenn man zum Debugging die Zeilen der
> Fehler
> >> bekäme.
> >>
> >> Zuletzt noch die neugierige Frage, welcher Parser zum Einsatz kommt.
> >>
> >>
> >> Viele Gruesse,
> >> Th. Staecker
> >>
> >>
> >>
> >>
> >>
> >> Meyer, Sebastian schrieb:
> >>> Liebe Kolleginnen und Kollegen,
> >>>
> >>> der METS/MODS-Validator ist nun weitestgehend fertig und kann unter
> >> folgender URL getestet werden:
> >>> http://194.95.142.95/fileadmin/statics/validator/metsmods.php
> >>>
> >>> Der Validator basiert auf den kürzlich von den Göttinger Kollegen
> >> freigegebenen METS- und MODS-Profilen für den Einsatz im Rahmen des
> >> DFG-Viewers und ZVDD. Die Validierung findet dabei in mehreren
> >> Schritten statt und gibt bei invaliden Dokumenten Hinweise zum
> Fehler
> >> aus.
> >>> Eine Integration in die Webseite des DFG-Viewers soll im Laufe der
> >> kommenden Woche erfolgen.
> >>> Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde
> >> ich mich freuen.
> >>> Viele Grüße aus Dresden
> >>> Sebastian Meyer
> >>>
> >>> --
> >>> ___________________________________________________
> >>>
> >>> Sebastian Meyer
> >>>
> >>> Abteilung Informationstechnologie
> >>> 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/
> >>> ___________________________________________________
> >>>
> >>>
> >>
> >> --
> >> 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
> >
>
>
> --
> 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
**************************************************************************
Experience the British Library online at www.bl.uk
The British Library's new interactive Annual Report and Accounts 2007/08 :
www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It
is intended for the addressee(s) only. If you are not the intended recipient, please
delete this e-mail and notify the postmaster(a)bl.uk : The contents of this e-mail must not
be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not
necessarily reflect those of the British Library. The British Library does not take any
responsibility for the views of the author.
*************************************************************************
12:09 p.m.
Hallo Liebe Zielgruppe,
Ich denke auch, dass es nicht sinnvoll ist von ZVDD-Vorgaben zu sprechen, denn immerhin
werden die METS Dateien ja gegenueber einem Profil validiert. IMHO muss man das aber nicht
bei jeder Fehlermeldung wiederholen. Wenn zu Beginn des validierungslaufes klar gemacht
wird, nach welchen Regeln validiert wird. Die Versionsnummer des Profiles duerfte dabei ja
auch ne Rolle spielen.
Ferner hielte ich es fuer sinnvoll zu unterscheiden in:
- ERROR: Alle Meldungen, die auf eine Inkompatibilitaet zwischen Profile und METS Datei
hindeuten sowie natuerlich alle non-wellformed und non-schema-compliant Fehler, die vom
XML Parser verursacht werden.
Dateien, die ERROR Meldungen erzeugen koennen nicht vollstaendig im ZVDD indexiert und im
DFG Viewer angezeigt werden. D.h. nicht alle Seiten sind vorhanden bzw. referenziert,
Reihenfolgeinformationen fehlen, keine Deskriptiven Metadaten fuer bestimmte Strukturtypen
etc.
- WARNING: Meldungen, die Eigenartigkeiten entdecken, die zu einer unvollstaendigen
Anzeige und Indexierung fuehren. Darunter wuerde ich bspw. Metadaten verstehen, die
eigentlich da sein sollten, allerdings nicht vorhanden sind.
- HINT: Das sind im wesentlichen Meldungen, die derzeit als Warning markiert sind.
Meldungen, die auf Annahmen basieren, wie bspw. "1 name Element mit dem type
Attributwert corporate enthalten, wenn geeignete Daten vorliegen".
- DEBUG: Meldungen, die fuer alle neugierigen Menschen interessant sein koennten, die
ueberhaupt mal sehen moechten, was ueberhaupt validiert wird.
Der Nutzer sollte auswaehlen koennen, ob er zu den ERROR und WARNINGs auch HINT und DEBUG
Meldungen angezeigt haben moechte.
Des weiterren mal die Frage:
Haben wir ein Set an fehlerhaften METS Dokumenten, mit denen wir den Validator testen
koennen?
Woher wissen wir sonst, dass der Validator auch alle Fehler entsprechend meldet?
Ist es technisch ueberhaupt moeglich die Zeile gemeldet zu bekommen, wenn es sich um
semantische Fehler handelt, die vermutlich bereits validiert werden, nachdem der XML
Inhalt de-serialisiert wurde und sich bereits in einem Objektmodell befindet?
Ciao
markus
-----Original Message-----
From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-viewer.de] On Behalf
Of Meyer, Sebastian
Sent: 10 December 2008 10:06
To: technik(a)dfg-viewer.de
Subject: Re: [DFG-Viewer] METS/MODS-Validator
Lieber Herr Staecker,
vielen Dank für Ihre Hinweise. Ich würde allen angesprochenen Punkten lediglich sprachlich
begegnen wollen. Statt von "ZVDD Vorgaben" zu sprechen, schlage ich die
allgemeinere Formulierung "Profil-Vorgaben" vor. Damit wäre der Validator sowohl
im Kontext des DFG-Viewers als auch im Kontext von ZVDD nutzbar.
Die anderen von Ihnen angemerkten Fehlermeldungen des Validators würde ich gerne nicht
völlig ausblenden, sondern lediglich sprachlich etwas entschärfen: statt einen
"Verstoß gegen Profil-Vorgaben" anzumahnen, könnte der Validator lediglich einen
neutralen "Hinweis" oder "Tipp" ausgeben.
Insgesamt wäre es schön, wenn man zum Debugging die
Zeilen der Fehler
bekäme.
Zumindest bei den Schema-basierten Prüfungen sollte das der Fall sein. Warum es bei den
anderen Prüfungen nicht funktioniert, weiß ich auch nicht. Da werde ich nochmal mit dem
Entwickler sprechen.
Viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] Im Auftrag von Dr. Thomas Staecker
> Gesendet: Donnerstag, 4. Dezember 2008 15:10
> An: technik(a)dfg-viewer.de
> Betreff: Re: [DFG-Viewer] METS/MODS-Validator
>
> Lieber Herr Meyer,
>
> wunderbar! Sehr schönes tool. Auf die Schnelle eine erste kurze
> Rückmeldung.
>
> Eine Fehlermeldung, die nach meiner Ansicht nicht ganz optimal ist:
>
> "Verstoß gegen ZVDD Vorgaben [1] (Teildokument #1)
> Warnung! In relatedItem Elementen des Typs series wird die Verwendung
> des part/detail/number Elements emfohlen."
>
> Es handelt sich dabei um Folgendes:
>
> <mods:relatedItem type="series" >
> <mods:titleInfo>
> <mods:title>Digitalisierung naturwissenschaftlicher, technischer und
> medizinischer Texte der Leibnizzeit, Projekt der Herzog August
> Bibliothek</mods:title>
> </mods:titleInfo>
> <mods:identifier type="purl"
> >http://diglib.hab.de/?link=011</mods:identifier>
> </mods:relatedItem>
>
>
> part/detail/number zu verlangen ist ein wenig problematisch, wenn man
> davon ausgeht, dass es eine gezählte Serie sein muss. Das ist aber bei
> diesen Projekten eigentlich unnötig.
>
> Dann auch die Frage, ob es sprachlich "ZVDD Vorgaben" heissen muss,
> wenn
> es der validator des Viewers ist. Würde ich neutraler benennen:
> "Verstoß
> gegen [1]..."
>
> Dann:
>
> "Verstoß gegen ZVDD Vorgaben [3] (Teildokument #1)
> Warnung! Das titleInfo Element sollte exakt 1 subTitle Element
> enthalten, falls geeignete Daten vorliegen."
>
> Finde ich überflüssig ebenso wie
>
> "Verstoß gegen ZVDD Vorgaben [4] (Teildokument #1)
> Warnung! Es wird empfphlen das nonSort Element in titleInfo Elementen
> zu
> verwenden."
>
> ebenso wie
>
> "Verstoß gegen ZVDD Vorgaben [7] (Teildokument #1)
> Warnung! Das MODS Dokument sollte mind. 1 name Element mit dem type
> Attributwert corporate enthalten, wenn geeignete Daten vorliegen."
>
Insgesamt wäre es schön, wenn man zum Debugging die
Zeilen der Fehler
bekäme.
>
> Zuletzt noch die neugierige Frage, welcher Parser zum Einsatz kommt.
>
>
> Viele Gruesse,
> Th. Staecker
>
>
>
>
>
> Meyer, Sebastian schrieb:
> > Liebe Kolleginnen und Kollegen,
> >
> > der METS/MODS-Validator ist nun weitestgehend fertig und kann unter
> folgender URL getestet werden:
> >
> > http://194.95.142.95/fileadmin/statics/validator/metsmods.php
> >
> > Der Validator basiert auf den kürzlich von den Göttinger Kollegen
> freigegebenen METS- und MODS-Profilen für den Einsatz im Rahmen des
> DFG-Viewers und ZVDD. Die Validierung findet dabei in mehreren
> Schritten statt und gibt bei invaliden Dokumenten Hinweise zum Fehler
> aus.
> >
> > Eine Integration in die Webseite des DFG-Viewers soll im Laufe der
> kommenden Woche erfolgen.
> >
> > Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde
> ich mich freuen.
> >
> > Viele Grüße aus Dresden
> > Sebastian Meyer
> >
> > --
> > ___________________________________________________
> >
> > Sebastian Meyer
> >
> > Abteilung Informationstechnologie
> > 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/
> > ___________________________________________________
> >
> >
>
>
> --
> 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
**************************************************************************
Experience the British Library online at www.bl.uk
The British Library's new interactive Annual Report and Accounts 2007/08 :
www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It
is intended for the addressee(s) only. If you are not the intended recipient, please
delete this e-mail and notify the postmaster(a)bl.uk : The contents of this e-mail must not
be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not
necessarily reflect those of the British Library. The British Library does not take any
responsibility for the views of the author.
*************************************************************************
12:27 p.m.
Lieber Markus,
Ferner hielte ich es fuer sinnvoll zu unterscheiden
in:
...
das wird zum Teil bereits getan. XML-Dokumente, die nicht wohlgeformt sind oder kein
METS-Root-Element besitzen, werden gar nicht weiter validiert, sondern gleich als ungültig
zurückgewiesen. Nur wenn das Dokument grundsätzlich METS-XML ist, wird eingehender
geprüft. So gesehen gibt es also bereits eine Unterscheidung zwischen "Error"
und "Warnung".
Des weiterren mal die Frage:
Haben wir ein Set an fehlerhaften METS Dokumenten, mit denen wir den
Validator testen koennen?
Woher wissen wir sonst, dass der Validator auch alle Fehler
entsprechend meldet?
Das ist eine berechtigte Frage. Anbei deshalb einige fehlerhafte Beispiele, die der
Entwickler des Validators uns zu Testzwecken mitgeliefert hat.
Viele Grüße
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] Im Auftrag von Enders, Markus
> Gesendet: Mittwoch, 10. Dezember 2008 12:10
> An: technik(a)dfg-viewer.de
> Betreff: Re: [DFG-Viewer] METS/MODS-Validator
>
> Hallo Liebe Zielgruppe,
>
> Ich denke auch, dass es nicht sinnvoll ist von ZVDD-Vorgaben zu
> sprechen, denn immerhin werden die METS Dateien ja gegenueber einem
> Profil validiert. IMHO muss man das aber nicht bei jeder Fehlermeldung
> wiederholen. Wenn zu Beginn des validierungslaufes klar gemacht wird,
> nach welchen Regeln validiert wird. Die Versionsnummer des Profiles
> duerfte dabei ja auch ne Rolle spielen.
>
> Ferner hielte ich es fuer sinnvoll zu unterscheiden in:
>
> - ERROR: Alle Meldungen, die auf eine Inkompatibilitaet zwischen
> Profile und METS Datei hindeuten sowie natuerlich alle non-wellformed
> und non-schema-compliant Fehler, die vom XML Parser verursacht werden.
> Dateien, die ERROR Meldungen erzeugen koennen nicht vollstaendig im
> ZVDD indexiert und im DFG Viewer angezeigt werden. D.h. nicht alle
> Seiten sind vorhanden bzw. referenziert, Reihenfolgeinformationen
> fehlen, keine Deskriptiven Metadaten fuer bestimmte Strukturtypen etc.
>
> - WARNING: Meldungen, die Eigenartigkeiten entdecken, die zu einer
> unvollstaendigen Anzeige und Indexierung fuehren. Darunter wuerde ich
> bspw. Metadaten verstehen, die eigentlich da sein sollten, allerdings
> nicht vorhanden sind.
>
> - HINT: Das sind im wesentlichen Meldungen, die derzeit als Warning
> markiert sind. Meldungen, die auf Annahmen basieren, wie bspw. "1 name
> Element mit dem type Attributwert corporate enthalten, wenn geeignete
> Daten vorliegen".
>
> - DEBUG: Meldungen, die fuer alle neugierigen Menschen interessant sein
> koennten, die ueberhaupt mal sehen moechten, was ueberhaupt validiert
> wird.
>
>
> Der Nutzer sollte auswaehlen koennen, ob er zu den ERROR und WARNINGs
> auch HINT und DEBUG Meldungen angezeigt haben moechte.
>
Des weiterren mal die Frage:
Haben wir ein Set an fehlerhaften METS Dokumenten, mit denen wir den
Validator testen koennen?
Woher wissen wir sonst, dass der Validator auch alle Fehler
entsprechend meldet?
>
> Ist es technisch ueberhaupt moeglich die Zeile gemeldet zu bekommen,
> wenn es sich um semantische Fehler handelt, die vermutlich bereits
> validiert werden, nachdem der XML Inhalt de-serialisiert wurde und sich
> bereits in einem Objektmodell befindet?
>
> Ciao
> markus
>
>
> -----Original Message-----
> From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] On Behalf Of Meyer, Sebastian
> Sent: 10 December 2008 10:06
> To: technik(a)dfg-viewer.de
> Subject: Re: [DFG-Viewer] METS/MODS-Validator
>
> Lieber Herr Staecker,
>
> vielen Dank für Ihre Hinweise. Ich würde allen angesprochenen Punkten
> lediglich sprachlich begegnen wollen. Statt von "ZVDD Vorgaben" zu
> sprechen, schlage ich die allgemeinere Formulierung "Profil-Vorgaben"
> vor. Damit wäre der Validator sowohl im Kontext des DFG-Viewers als
> auch im Kontext von ZVDD nutzbar.
> Die anderen von Ihnen angemerkten Fehlermeldungen des Validators würde
> ich gerne nicht völlig ausblenden, sondern lediglich sprachlich etwas
> entschärfen: statt einen "Verstoß gegen Profil-Vorgaben" anzumahnen,
> könnte der Validator lediglich einen neutralen "Hinweis" oder
"Tipp"
> ausgeben.
>
> > Insgesamt wäre es schön, wenn man zum Debugging die Zeilen der Fehler
> > bekäme.
>
> Zumindest bei den Schema-basierten Prüfungen sollte das der Fall sein.
> Warum es bei den anderen Prüfungen nicht funktioniert, weiß ich auch
> nicht. Da werde ich nochmal mit dem Entwickler sprechen.
>
> Viele Grüße
> Sebastian Meyer
>
> --
> ___________________________________________________
>
> Sebastian Meyer
>
> Abteilung Informationstechnologie
> 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: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> > viewer.de] Im Auftrag von Dr. Thomas Staecker
> > Gesendet: Donnerstag, 4. Dezember 2008 15:10
> > An: technik(a)dfg-viewer.de
> > Betreff: Re: [DFG-Viewer] METS/MODS-Validator
> >
> > Lieber Herr Meyer,
> >
> > wunderbar! Sehr schönes tool. Auf die Schnelle eine erste kurze
> > Rückmeldung.
> >
> > Eine Fehlermeldung, die nach meiner Ansicht nicht ganz optimal ist:
> >
> > "Verstoß gegen ZVDD Vorgaben [1] (Teildokument #1)
> > Warnung! In relatedItem Elementen des Typs series wird die Verwendung
> > des part/detail/number Elements emfohlen."
> >
> > Es handelt sich dabei um Folgendes:
> >
> > <mods:relatedItem type="series" >
> > <mods:titleInfo>
> > <mods:title>Digitalisierung naturwissenschaftlicher, technischer und
> > medizinischer Texte der Leibnizzeit, Projekt der Herzog August
> > Bibliothek</mods:title>
> > </mods:titleInfo>
> > <mods:identifier type="purl"
> > >http://diglib.hab.de/?link=011</mods:identifier>
> > </mods:relatedItem>
> >
> >
> > part/detail/number zu verlangen ist ein wenig problematisch, wenn man
> > davon ausgeht, dass es eine gezählte Serie sein muss. Das ist aber
> bei
> > diesen Projekten eigentlich unnötig.
> >
> > Dann auch die Frage, ob es sprachlich "ZVDD Vorgaben" heissen muss,
> > wenn
> > es der validator des Viewers ist. Würde ich neutraler benennen:
> > "Verstoß
> > gegen [1]..."
> >
> > Dann:
> >
> > "Verstoß gegen ZVDD Vorgaben [3] (Teildokument #1)
> > Warnung! Das titleInfo Element sollte exakt 1 subTitle Element
> > enthalten, falls geeignete Daten vorliegen."
> >
> > Finde ich überflüssig ebenso wie
> >
> > "Verstoß gegen ZVDD Vorgaben [4] (Teildokument #1)
> > Warnung! Es wird empfphlen das nonSort Element in titleInfo Elementen
> > zu
> > verwenden."
> >
> > ebenso wie
> >
> > "Verstoß gegen ZVDD Vorgaben [7] (Teildokument #1)
> > Warnung! Das MODS Dokument sollte mind. 1 name Element mit dem type
> > Attributwert corporate enthalten, wenn geeignete Daten vorliegen."
> >
> > Insgesamt wäre es schön, wenn man zum Debugging die Zeilen der Fehler
> > bekäme.
> >
> > Zuletzt noch die neugierige Frage, welcher Parser zum Einsatz kommt.
> >
> >
> > Viele Gruesse,
> > Th. Staecker
> >
> >
> >
> >
> >
> > Meyer, Sebastian schrieb:
> > > Liebe Kolleginnen und Kollegen,
> > >
> > > der METS/MODS-Validator ist nun weitestgehend fertig und kann unter
> > folgender URL getestet werden:
> > >
> > > http://194.95.142.95/fileadmin/statics/validator/metsmods.php
> > >
> > > Der Validator basiert auf den kürzlich von den Göttinger Kollegen
> > freigegebenen METS- und MODS-Profilen für den Einsatz im Rahmen des
> > DFG-Viewers und ZVDD. Die Validierung findet dabei in mehreren
> > Schritten statt und gibt bei invaliden Dokumenten Hinweise zum Fehler
> > aus.
> > >
> > > Eine Integration in die Webseite des DFG-Viewers soll im Laufe der
> > kommenden Woche erfolgen.
> > >
> > > Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde
> > ich mich freuen.
> > >
> > > Viele Grüße aus Dresden
> > > Sebastian Meyer
> > >
> > > --
> > > ___________________________________________________
> > >
> > > Sebastian Meyer
> > >
> > > Abteilung Informationstechnologie
> > > 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/
> > > ___________________________________________________
> > >
> > >
> >
> >
> > --
> > 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
>
> ***********************************************************************
> ***
>
> Experience the British Library online at www.bl.uk
>
> The British Library's new interactive Annual Report and Accounts
> 2007/08 : www.bl.uk/knowledge
>
> Help the British Library conserve the world's knowledge. Adopt a Book.
> www.bl.uk/adoptabook
>
> The Library's St Pancras site is WiFi - enabled
>
> ***********************************************************************
> **
>
> The information contained in this e-mail is confidential and may be
> legally privileged. It is intended for the addressee(s) only. If you
> are not the intended recipient, please delete this e-mail and notify
> the postmaster(a)bl.uk : The contents of this e-mail must not be
> disclosed or copied without the sender's consent.
>
> The statements and opinions expressed in this message are those of the
> author and do not necessarily reflect those of the British Library. The
> British Library does not take any responsibility for the views of the
> author.
>
> ***********************************************************************
> **
5:17 p.m.
Hallo Sebastian,
Werde mir die Beispiel mal anschauen. Allerdings frage ich mich, ob es eine Dokumentation
gibt, was der Validator alles validiert und auf welchen Erfahrungen eine solche Liste
basiert.
Ciao
Markus
**************************************************************************
Experience the British Library online at www.bl.uk
The British Library's new interactive Annual Report and Accounts 2007/08 :
www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It
is intended for the addressee(s) only. If you are not the intended recipient, please
delete this e-mail and notify the postmaster(a)bl.uk : The contents of this e-mail must not
be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not
necessarily reflect those of the British Library. The British Library does not take any
responsibility for the views of the author.
*************************************************************************
das wird zum Teil bereits getan. XML-Dokumente, die
nicht wohlgeformt sind oder kein METS-Root-Element besitzen, werden gar nicht weiter
validiert, sondern gleich als ungültig zurückgewiesen. Nur wenn das Dokument grundsätzlich
METS-XML ist, wird eingehender geprüft. So gesehen gibt es also bereits eine
Unterscheidung zwischen "Error" und "Warnung".
Hm, nein das was du beschreibst stellt eine andere Ebene da. Im Prinzip hast du doch
folgendes Vorgehen:
1) Validierung der XML Serialisierung anhand eines oder mehrerer Schema(s).
2) Ueberpruefung des DOM-Trees (oder eines anderen Objektbaums), und Validierung der METS
Semantik:
(a) zeigen <fptr> auf Dateien
(b) zeigen DMDIDs auf dmdSec
etc...
3) Ueberpruefung des spezifischen Datenmodells
(a) sind zwei StructMaps vorhanden
(b) sind Verlinkungen entsprechend gesetzt
(c) sind entsprechende Attributwerte richtig gesetzt (ORDER und ORDERLABEL bspw.)
4) Ueberpruefung der Extension Schemas
Also Ueberpruefung der deskriptiven Metadaten etc.
In all diesen Bereichen kann es "Errors", "Warnings" und
"Hints" geben. Beispiel:
1) Error: wenn Dokument nicht wellformed und nicht validierbar
Hint: wenn anderer Prefix als "mets" wird benutzt. <blafasel:mets>
wurde zu einem Hint (ggfs. auch zu einer Warning) fuehren, auch wenn der namespace
entsprechend fuer den Prefix deklariert ist
Das laesst sich beispielhaft sicherlich fortsetzen...
Wobei ich mich frage, was der Validator nun eigentlich wirklich ueberprueft. Fehler kann
es ja schliesslich viele geben...
Des weiterren
mal die Frage:
Haben wir ein Set an fehlerhaften METS Dokumenten, mit denen wir den
Validator testen koennen?
Woher wissen wir sonst, dass der Validator auch alle Fehler
entsprechend meldet?
Das ist eine berechtigte Frage. Anbei deshalb einige fehlerhafte Beispiele, >die der
Entwickler des Validators uns zu Testzwecken mitgeliefert hat. 
1:28 p.m.
Hallo *,
Ich denke auch, dass es nicht sinnvoll ist von
ZVDD-Vorgaben zu sprechen, denn immerhin werden die METS Dateien ja gegenueber einem
Profil validiert. IMHO muss man das aber nicht bei jeder Fehlermeldung wiederholen. Wenn
zu Beginn des validierungslaufes klar gemacht wird, nach welchen Regeln validiert wird.
Die Versionsnummer des Profiles duerfte dabei ja auch ne Rolle spielen.
Ferner hielte ich es fuer sinnvoll zu unterscheiden in:
- ERROR: Alle Meldungen, die auf eine Inkompatibilitaet zwischen Profile und METS Datei
hindeuten sowie natuerlich alle non-wellformed und non-schema-compliant Fehler, die vom
XML Parser verursacht werden.
Dateien, die ERROR Meldungen erzeugen koennen nicht vollstaendig im ZVDD indexiert und im
DFG Viewer angezeigt werden. D.h. nicht alle Seiten sind vorhanden bzw. referenziert,
Reihenfolgeinformationen fehlen, keine Deskriptiven Metadaten fuer bestimmte Strukturtypen
etc.
- WARNING: Meldungen, die Eigenartigkeiten entdecken, die zu einer unvollstaendigen
Anzeige und Indexierung fuehren. Darunter wuerde ich bspw. Metadaten verstehen, die
eigentlich da sein sollten, allerdings nicht vorhanden sind.
- HINT: Das sind im wesentlichen Meldungen, die derzeit als Warning markiert sind.
Meldungen, die auf Annahmen basieren, wie bspw. "1 name Element mit dem type
Attributwert corporate enthalten, wenn geeignete Daten vorliegen".
- DEBUG: Meldungen, die fuer alle neugierigen Menschen interessant sein koennten, die
ueberhaupt mal sehen moechten, was ueberhaupt validiert wird.
Der Nutzer sollte auswaehlen koennen, ob er zu den ERROR und WARNINGs auch HINT und DEBUG
Meldungen angezeigt haben moechte.
Alles sinnvoll und gut, aber sollen die primären Nutzer wirklich
Menschen sein?
Ist es nicht besser die Oberfläche und den eigentlichen Dienst
voneinander zu entkoppeln?
In Dresden würde dann lediglich die Oberfläche angeboten, dahinter
stünde ein interner Dienst. Herr Heiligenhaus und auch wir könnten die
Implementierung des Dienstes herunterladen und in unsere Systeme
integrieren...
Aber dafür ist es vermutlich schon zu spät.
Christian
--
----------------
Christian Mahnke
----------------
Center for Retrospective Digitization
Goettingen State and University Library (SUB)
University of Goettingen
Papendiek 14
37073 Goettingen, Germany
web: http://gdz.sub.uni-goettingen.de/
phone: +49 (0)551 39 - 4917
skype: christian.mahnke
mail: mahnke(a)sub.uni-goettingen.de
2:28 p.m.
Moin,
Alles sinnvoll und gut, aber sollen die primären Nutzer
wirklich
Menschen sein?
Meine Meinung:
Ja, der primaere Nutzer soll zunaechst der Mensch sein. Insbesondere der Entwickler, der
METS Daten fuer ZVDD und DFG-Viewer generiert.
Spaeter kann dieses Tool auch genutzt werden, um Daten automatisch zu validieren.
Aber dafür ist es vermutlich schon zu spät.
Wieso, hat wer an der Uhr gedreht?
Ciao
Markus
**************************************************************************
Experience the British Library online at www.bl.uk
The British Library's new interactive Annual Report and Accounts 2007/08 :
www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It
is intended for the addressee(s) only. If you are not the intended recipient, please
delete this e-mail and notify the postmaster(a)bl.uk : The contents of this e-mail must not
be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not
necessarily reflect those of the British Library. The British Library does not take any
responsibility for the views of the author.
*************************************************************************
6:31 p.m.
Der menschlichen Perspektive ;-) möchte ich mich anschliessen. Das Tool
bietet eine bequeme Möglichkeit, die Validität der eigenen Dateien zu
überprüfen. Gewiss, kann man das Schema auch in irgendeinen x-beliebigen
Editor einbauen, aber manche haben eben einen solchen nicht flugs zur
Hand. Kurz, ein hilfreiches Angebot.
Viele Gruesse,
Th. Stäcker
Enders, Markus schrieb:
Moin,
--
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
Alles sinnvoll und gut, aber sollen die primären
Nutzer wirklich
Menschen sein?
Meine Meinung:
Ja, der primaere Nutzer soll zunaechst der Mensch sein. Insbesondere der Entwickler, der
METS Daten fuer ZVDD und DFG-Viewer generiert.
Spaeter kann dieses Tool auch genutzt werden, um Daten automatisch zu validieren.
Aber dafür ist es vermutlich schon zu spät.
Wieso, hat wer an der Uhr gedreht?
Ciao
Markus
**************************************************************************
Experience the British Library online at www.bl.uk
The British Library's new interactive Annual Report and Accounts 2007/08 :
www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally privileged.
It is intended for the addressee(s) only. If you are not the intended recipient, please
delete this e-mail and notify the postmaster(a)bl.uk : The contents of this e-mail must not
be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not
necessarily reflect those of the British Library. The British Library does not take any
responsibility for the views of the author.
************************************************************************* 
12 Dec
12 Dec
10:17 a.m.
Am Mittwoch, 3. Dezember 2008 schrieb Meyer, Sebastian:
Liebe Kolleginnen und Kollegen,
Hallo,
noch ein paar technische Anmerkungen zum Validator:
- Bei bei sehr vielen MODS-Sections ist eine Fehlersuche mit solchen Angaben
schwierig:
SCHNIPP---------
Verstoß gegen ZVDD Vorgaben [12] (Teildokument #15)
Warnung! Es wird empfphlen das nonSort Element in titleInfo Elementen zu
verwenden.
SCHNAPP-------
Heir wäre eine direkte Verlinkung in die XML-Datei wünschenswert, zumindest
aber eine Ausgabe der MODS Section ID. Ein formatierte Ausgabe des XML wäre
auch hilfreich.
- Bei der Ausgabe des XML sollte die original Kodierung und die verwendenten
Zeichen beibehalten werden.
SCHNIPP-----original------
<mods:publisher>Московское математическое общество</mods:publisher>
SCHAPP------original--------
wird zu
SCHIPP-------Validator------
<mods:publisher>
МоÑковÑкое
математичеÑкое
общеÑтво</mods:publisher>
SCHAPP------original--------
- Für einen Großteil unseres Bestandes (ca. 9.000 Zeitschriftenbände) ist eine
Prüfung nicht möglich, da bei einer Größe zwischen 150 - 1.000 MODS-Sections
der Validater bzw. der Webserver in einen Timeout läuft - hier scheidet die
Variante Hochladen, Prüfen, Ergebnis ausliefern also aus.
Viele Grüße aus Göttingen
Jochen Kothe
der METS/MODS-Validator ist nun weitestgehend fertig und kann unter
folgender URL getestet werden:
http://194.95.142.95/fileadmin/statics/validator/metsmods.php
Der Validator basiert auf den kürzlich von den Göttinger Kollegen
freigegebenen METS- und MODS-Profilen für den Einsatz im Rahmen des
DFG-Viewers und ZVDD. Die Validierung findet dabei in mehreren Schritten
statt und gibt bei invaliden Dokumenten Hinweise zum Fehler aus.
Eine Integration in die Webseite des DFG-Viewers soll im Laufe der
kommenden Woche erfolgen.
Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde ich
mich freuen.
Viele Grüße aus Dresden
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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/
___________________________________________________
--
Niedersächsische Staats-
und Universitätsbibliothek
Platz der Göttinger Sieben 1
37073 Göttingen
Projekt: DigiZeitschriften.de
http://www.digizeitschriften.de
Projekt: IMPACT
http://www.impact-project.eu
Projekt: DigiWunschbuch.de
http://www.digiwunschbuch.de
Email: kothe(a)sub.uni-goettingen.de
16 Dec
16 Dec
2:10 p.m.
Liebe Zielgruppe,
nicht, dass ich Zeit haette, aber ein METS Validator ist schon interessant. Zumal wir hier
mit sehr aehnlichen Problemen kaempfen. Ich habe den Validator zunaechst mal mit der Datei
"metsmods-ok.xml" getestet. Diese validiert lt. Validator, nur paar Warnings
"Verstoss gegen ZVDD Vorgaben".
Was einem auffaellt: In der Datei wird das MODS Schema "mods-3-0.xsd"
referenziert. In der Ausgabe auf dem Bildschirm behauptet der Validator, es wuerde gegen
"http://www.loc.gov/mods/v3/mods-3-3.xsd" validiert werden.
Verwunderung macht sich breit.... Wonach validiert er denn nun?
Und wieso 3.3? Das MODS Anwendungsprofil bezieht sich lt. Profil auf 3.2... IMHO sollte in
der XML-Datei MODS 3.2 referenziert werden und dagegen auch validiert werden.
Aber man kann ja mal ein Blick auf die Datei werfen. Dabei entdeckt man dann folgendes:
Eigenartigerweise sind Grundlage der Testdaten METS Daten die gar nicht aus dem DFG
Kontext kommen, sondern wohl in Berkeley entstanden sind. Deswegen sieht die
Rights-Sektion auch anders aus.
Fast alle URLs zu den extension schemas wie MODS, metsrights etc. Sind falsch gesetzt,
bzw. auch die namespace-Angaben sind falsch.
- URLs wie "http://www.loc. gov/mods/v3" sind nicht nur unschoen sondern koennen
auch nicht gefunden werden. Eine Schema-Validierung kann in Folge dessen auch nicht
stattfinden. Das sehe zumindest ich, wenn ich die Datei in Oxygene oeffne.
- Habe die URLs mal korrigiert und - surprise, surprise mal paar interessante Ergebnisse
gefunden:
Target Namespace fur MIX ist falsch:
- sollte eigentlich http://www.loc.gov/mix/v20 sein (lt. xml schema), ist aber nur auf
http://www.loc.gov/mix/ gesetzt
- Sobald man das mal macht - es gibt einige Fehler. Der MIX Record ist nicht compliant mit
dem MIX schema. Keine Ahnung warum.
MODS Metadaten Record hat auch einen Fehler:
- <mods:typeOfResource> enthaelt einen Fehler; der Wert " still image "
ist nicht zugelassen. Der Wert muss auch einer ennumerated list kommen - und der
entsprechende Wert ist nunmal "still image" (man beachte die Leerzeichen).
- Gibt es einen Grund warum das veraltete 3.0 Schema benutzt wird und nicht 3.2 oder 3.3?
IMHO sollte hier 3.2. benutzt werden, da dies immerhin vom MODS Anwendungsprofil
vorgeschrieben wird.
Habe die entsprechenden URLs mal korrigiert und die MIX records rausgeschmissen. Die sind
ja weder fuer das METS noch fuer das MODS Profil verbindlich vorgeschrieben.
Angehangen mal die "korrigierte" Version.
So wie die Validierung beginnt, geht es auch weiter: Der Validator scheint ja nichtmal auf
xml-Schema Ebene zu validieren, sonst haetten entsprechende Fehler auffallen muessen.
Ueber weitere Fehler wie bspw. fehlerhafte Pointer innerhalb einer METS Datei (AMDID
verweist auf eine dmdSec) gibt es natuerlich auch keine Fehlermeldungen (hab ich anhand
einer modifizierten Datei getestet). D.h. der Validator validiert anscheinend nichtmal auf
Ebene des METS-Datenmodells korrekt.
Eine Ebene tiefer, d.h. auf formeller Ebene des METS Anwendungsprofils darf man ebenfalls
nichts erwarten. Das Anwendungsprofil legt fest:
"Das Seitenbasierte Dokumentenmodell zeichnet sich durch zwei <structMap>
Elemente aus." Und ferner "Das Seitenbasierte Dokumentmodell ist das
Minimalmodell, welches vom DFG-Viewer unterstüzt wird."
IMHO wurde genau dafuer der DFG-Viewer gebaut: Seitenweises blaettern. D.h. die METS Datei
muss eine logische und eine physische Struktur besitzten, da entweder das Seitebasierte
oder das komplexe Dokumentenmodell implementiert sein muss.
Diese validierbare METS Datei hat jedoch keine logische Struktur. Sie besitzt eine
physische Struktur, wobei dessen Strukturdaten keineswegs dem entsprechend, was das METS
Anwednungsprofil vorsieht. Eine <structLink> Sektion fehlt in der METS Datei
natuerlich auch. Wird alles nicht angemeckert durch den Validator.
Wenn also die dritte Ebene (formelle Ebene des METS Anwendungsprofils) nicht validiert
wird, kann die vierte Ebene (Semantik des METS Anwendungsprofils) erst recht nicht
validiert werden. Hierbei wuerde es um Attributwert sowie entsprechende Abhaengigkeiten
zwischen Attributwerden und XML Strukturen (in METS und den Extension-Schemas) gehen.
Ich weiss nicht, ob es sich lohnt, den Sourcecode des Validators zu besorgen. IMHO koennen
dort max. 5% dessen was eine Validierung ausmacht drin stecken. Der Validator ist
vollkommen unbrauchbar :-(
Das verwundert mich ehrlich gesagt nicht. XML ist fuer viele Leute ja nun schon schwierig
genug. METS ist nochmal eine andere Stufe - erst Recht, wenn es dann noch um die
Einbindung von Extensions Schemas geht. Meiner Erfahrung nach ist es recht schwer Arbeiten
dieser Art auszulagern. Das Wissen und Verstaendnis von externen Firmen auf diesem Gebiet
ist nicht gegeben. METS Dateien zu generieren und zu parsen ist fuer viele schon mit einem
hohen Lernaufwand verbunden. Eine Validierung ist nochmal etwas anderes und IMHO
wesentlich komplizierter.
Ich denke ohne aufwendige Requirement-Dokumente wird man hier nicht auskommen. IMHO sollte
fuer jeder der 4 Validierungslevel genau festgelegt werden, welche Elemente und Semantiken
eigentlich validiert werden sollen, und ob das Ergebnis einer fehlerhaften Teilvalidierung
ein Error, Warning, Hint etc ist. Ich weiss nicht, ob solche Requirement-Dokumente der
Entwicklung des aktuellen Validators zu Grunde lagen. (ich vermute eher nicht).
Allerdings waere es fuer alle hilfreich zu diskutieren, was wir eigentlich validieren
wollen. Nur das METS/MODS Profil soweit es der DFG-Viewer braucht? Oder sollte nicht
eigentlich das komplette Profil validiert werden?
Andere Dienste, wie bspw. ein PDF-Konvertierdienst koennten naemlich ganz andere Teile
benoetigen als bspw. der DFG-Viewer. Der aktuelle Validator meckert bspw. ein Fehlen von
"<mods:identifier
type="urn">urn:nbn:gbv-7-PPN481399712</mods:identifier>" nicht an.
Fuer den Viewer mag das nicht wichtig sein. Fuer andere Dienste aber durchaus.
Ich wuerde sagen: Zurueck auf Los und nochmal anfangen.
Ansonsten allen Diskutierenden schoene Weihnachten... Haben wir ja gleich was zu tun nach
der Ruhepause ;-)
Ciao
Markus
-----Original Message-----
From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-viewer.de] On Behalf
Of Meyer, Sebastian
Sent: 03 December 2008 15:12
To: technik(a)dfg-viewer.de
Subject: [DFG-Viewer] METS/MODS-Validator
Liebe Kolleginnen und Kollegen,
der METS/MODS-Validator ist nun weitestgehend fertig und kann unter folgender URL getestet
werden:
http://194.95.142.95/fileadmin/statics/validator/metsmods.php
Der Validator basiert auf den kürzlich von den Göttinger Kollegen freigegebenen METS- und
MODS-Profilen für den Einsatz im Rahmen des DFG-Viewers und ZVDD. Die Validierung findet
dabei in mehreren Schritten statt und gibt bei invaliden Dokumenten Hinweise zum Fehler
aus.
Eine Integration in die Webseite des DFG-Viewers soll im Laufe der kommenden Woche
erfolgen.
Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde ich mich freuen.
Viele Grüße aus Dresden
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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/
___________________________________________________
**************************************************************************
Experience the British Library online at www.bl.uk
The British Library's new interactive Annual Report and Accounts 2007/08 :
www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It
is intended for the addressee(s) only. If you are not the intended recipient, please
delete this e-mail and notify the postmaster(a)bl.uk : The contents of this e-mail must not
be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not
necessarily reflect those of the British Library. The British Library does not take any
responsibility for the views of the author.
*************************************************************************
2:38 p.m.
Hallo Markus,
uiuiui, das ist ja ein ziemlich niederschmetterndes Urteil. Aber du hast natürlich recht.
Ich muss zugeben, dass ich so intensiv bisher gar nicht getestet habe. Nachdem der
Validator meine Testdateien korrekt validiert hat und auch die absichtlich eingebauten
Fehler gefunden hat, habe ich mich damit zufrieden gegeben. Allerdings habe ich auch nicht
daran gedacht, bei so grundlegenden Dingen wie der Schema-Referenzierung und den
Namespaces mal nachzuhaken, weil ich das für XML-Grundwissen hielt, das auch ein nicht
METS-affiner Entwickler beherrschen sollte.
Ich denke ohne aufwendige Requirement-Dokumente wird
man hier nicht
auskommen. IMHO sollte fuer jeder der 4 Validierungslevel genau
festgelegt werden, welche Elemente und Semantiken eigentlich validiert
werden sollen, und ob das Ergebnis einer fehlerhaften Teilvalidierung
ein Error, Warning, Hint etc ist. Ich weiss nicht, ob solche
Requirement-Dokumente der Entwicklung des aktuellen Validators zu
Grunde lagen. (ich vermute eher nicht).
Naja, der Entwicklung lagen die METS/MODS-Profile und -Dokumentationen zugrunde. Darin
sind ja eigentlich sämtliche Pflichtfelder, deren Beziehungen und möglichen Belegungen
klar erläutert. In sofern hat meines Erachtens eigentlich nur die Festlegung gefehlt, was
als Error, Warning bzw. Hint zu behandeln ist (wobei auch das implizit gegeben ist:
Pflichtelemente erzeugen Errors, optionale Felder Warnings und Empfehlungen Hints - aber
da ist eine differenziertere Betrachtung zweifellos sinnvoll).
Ein Manko war sicher, dass wir dem Entwickler nur sehr begrenzt Beispieldateien zur
Verfügung stellen konnten. Wir produzieren ja selbst noch nicht nativ METS, sondern
konvertieren unser internes Format on the fly in sehr rudimentäres METS (ohne
Strukturdaten, ohne Download-Verknüpfungen, etc.), bevor es an den DFG-Viewer geht. In
sofern habe ich selbst keine Beispiele für umfangreiche METS-Dokumente, die den
Anforderungen der Profile entsprechen und eine möglichst große Bandbreite von
Möglichkeiten abbilden.
Vielleicht können wir über die Technik-Liste ja mal eine Reihe solcher Beispiele sammeln?
Das wäre sicher nicht nur für Entwickler solcher Tools interessant und hilfreich, sondern
auch für Kollegen, die selbst vor der Aufgabe stehen, ihre Digitalisate in METS zu
packen.
Mit deiner Erlaubnis würde ich deine Ausführungen gerne an den Entwickler weiterleiten.
Viele Grüße
Sebastian
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] Im Auftrag von Enders, Markus
> Gesendet: Dienstag, 16. Dezember 2008 14:10
> An: technik(a)dfg-viewer.de
> Betreff: Re: [DFG-Viewer] METS/MODS-Validator
>
> Liebe Zielgruppe,
>
> nicht, dass ich Zeit haette, aber ein METS Validator ist schon
> interessant. Zumal wir hier mit sehr aehnlichen Problemen kaempfen. Ich
> habe den Validator zunaechst mal mit der Datei "metsmods-ok.xml"
> getestet. Diese validiert lt. Validator, nur paar Warnings "Verstoss
> gegen ZVDD Vorgaben".
>
> Was einem auffaellt: In der Datei wird das MODS Schema "mods-3-0.xsd"
> referenziert. In der Ausgabe auf dem Bildschirm behauptet der
> Validator, es wuerde gegen "http://www.loc.gov/mods/v3/mods-3-3.xsd"
> validiert werden.
> Verwunderung macht sich breit.... Wonach validiert er denn nun?
> Und wieso 3.3? Das MODS Anwendungsprofil bezieht sich lt. Profil auf
> 3.2... IMHO sollte in der XML-Datei MODS 3.2 referenziert werden und
> dagegen auch validiert werden.
>
> Aber man kann ja mal ein Blick auf die Datei werfen. Dabei entdeckt man
> dann folgendes:
>
> Eigenartigerweise sind Grundlage der Testdaten METS Daten die gar nicht
> aus dem DFG Kontext kommen, sondern wohl in Berkeley entstanden sind.
> Deswegen sieht die Rights-Sektion auch anders aus.
>
> Fast alle URLs zu den extension schemas wie MODS, metsrights etc. Sind
> falsch gesetzt, bzw. auch die namespace-Angaben sind falsch.
> - URLs wie "http://www.loc. gov/mods/v3" sind nicht nur unschoen
> sondern koennen auch nicht gefunden werden. Eine Schema-Validierung
> kann in Folge dessen auch nicht stattfinden. Das sehe zumindest ich,
> wenn ich die Datei in Oxygene oeffne.
> - Habe die URLs mal korrigiert und - surprise, surprise mal paar
> interessante Ergebnisse gefunden:
>
> Target Namespace fur MIX ist falsch:
> - sollte eigentlich http://www.loc.gov/mix/v20 sein (lt. xml
> schema), ist aber nur auf http://www.loc.gov/mix/ gesetzt
> - Sobald man das mal macht - es gibt einige Fehler. Der MIX
> Record ist nicht compliant mit dem MIX schema. Keine Ahnung warum.
>
> MODS Metadaten Record hat auch einen Fehler:
> - <mods:typeOfResource> enthaelt einen Fehler; der Wert " still image
"
> ist nicht zugelassen. Der Wert muss auch einer ennumerated list kommen
> - und der entsprechende Wert ist nunmal "still image" (man beachte die
> Leerzeichen).
> - Gibt es einen Grund warum das veraltete 3.0 Schema benutzt wird und
> nicht 3.2 oder 3.3? IMHO sollte hier 3.2. benutzt werden, da dies
> immerhin vom MODS Anwendungsprofil vorgeschrieben wird.
>
> Habe die entsprechenden URLs mal korrigiert und die MIX records
> rausgeschmissen. Die sind ja weder fuer das METS noch fuer das MODS
> Profil verbindlich vorgeschrieben.
>
> Angehangen mal die "korrigierte" Version.
> So wie die Validierung beginnt, geht es auch weiter: Der Validator
> scheint ja nichtmal auf xml-Schema Ebene zu validieren, sonst haetten
> entsprechende Fehler auffallen muessen.
>
> Ueber weitere Fehler wie bspw. fehlerhafte Pointer innerhalb einer METS
> Datei (AMDID verweist auf eine dmdSec) gibt es natuerlich auch keine
> Fehlermeldungen (hab ich anhand einer modifizierten Datei getestet).
> D.h. der Validator validiert anscheinend nichtmal auf Ebene des METS-
> Datenmodells korrekt.
>
> Eine Ebene tiefer, d.h. auf formeller Ebene des METS Anwendungsprofils
> darf man ebenfalls nichts erwarten. Das Anwendungsprofil legt fest:
> "Das Seitenbasierte Dokumentenmodell zeichnet sich durch zwei
> <structMap> Elemente aus." Und ferner "Das Seitenbasierte
> Dokumentmodell ist das Minimalmodell, welches vom DFG-Viewer unterstüzt
> wird."
>
> IMHO wurde genau dafuer der DFG-Viewer gebaut: Seitenweises blaettern.
> D.h. die METS Datei muss eine logische und eine physische Struktur
> besitzten, da entweder das Seitebasierte oder das komplexe
> Dokumentenmodell implementiert sein muss.
> Diese validierbare METS Datei hat jedoch keine logische Struktur. Sie
> besitzt eine physische Struktur, wobei dessen Strukturdaten keineswegs
> dem entsprechend, was das METS Anwednungsprofil vorsieht. Eine
> <structLink> Sektion fehlt in der METS Datei natuerlich auch. Wird
> alles nicht angemeckert durch den Validator.
>
> Wenn also die dritte Ebene (formelle Ebene des METS Anwendungsprofils)
> nicht validiert wird, kann die vierte Ebene (Semantik des METS
> Anwendungsprofils) erst recht nicht validiert werden. Hierbei wuerde es
> um Attributwert sowie entsprechende Abhaengigkeiten zwischen
> Attributwerden und XML Strukturen (in METS und den Extension-Schemas)
> gehen.
>
> Ich weiss nicht, ob es sich lohnt, den Sourcecode des Validators zu
> besorgen. IMHO koennen dort max. 5% dessen was eine Validierung
> ausmacht drin stecken. Der Validator ist vollkommen unbrauchbar :-(
>
> Das verwundert mich ehrlich gesagt nicht. XML ist fuer viele Leute ja
> nun schon schwierig genug. METS ist nochmal eine andere Stufe - erst
> Recht, wenn es dann noch um die Einbindung von Extensions Schemas geht.
> Meiner Erfahrung nach ist es recht schwer Arbeiten dieser Art
> auszulagern. Das Wissen und Verstaendnis von externen Firmen auf diesem
> Gebiet ist nicht gegeben. METS Dateien zu generieren und zu parsen ist
> fuer viele schon mit einem hohen Lernaufwand verbunden. Eine
> Validierung ist nochmal etwas anderes und IMHO wesentlich
> komplizierter.
>
Ich denke ohne aufwendige Requirement-Dokumente wird
man hier nicht
auskommen. IMHO sollte fuer jeder der 4 Validierungslevel genau
festgelegt werden, welche Elemente und Semantiken eigentlich validiert
werden sollen, und ob das Ergebnis einer fehlerhaften Teilvalidierung
ein Error, Warning, Hint etc ist. Ich weiss nicht, ob solche
Requirement-Dokumente der Entwicklung des aktuellen Validators zu
Grunde lagen. (ich vermute eher nicht).
>
> Allerdings waere es fuer alle hilfreich zu diskutieren, was wir
> eigentlich validieren wollen. Nur das METS/MODS Profil soweit es der
> DFG-Viewer braucht? Oder sollte nicht eigentlich das komplette Profil
> validiert werden?
>
> Andere Dienste, wie bspw. ein PDF-Konvertierdienst koennten naemlich
> ganz andere Teile benoetigen als bspw. der DFG-Viewer. Der aktuelle
> Validator meckert bspw. ein Fehlen von "<mods:identifier
> type="urn">urn:nbn:gbv-7-PPN481399712</mods:identifier>"
nicht an. Fuer
> den Viewer mag das nicht wichtig sein. Fuer andere Dienste aber
> durchaus.
>
> Ich wuerde sagen: Zurueck auf Los und nochmal anfangen.
>
> Ansonsten allen Diskutierenden schoene Weihnachten... Haben wir ja
> gleich was zu tun nach der Ruhepause ;-)
>
> Ciao
> Markus
>
> -----Original Message-----
> From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] On Behalf Of Meyer, Sebastian
> Sent: 03 December 2008 15:12
> To: technik(a)dfg-viewer.de
> Subject: [DFG-Viewer] METS/MODS-Validator
>
> Liebe Kolleginnen und Kollegen,
>
> der METS/MODS-Validator ist nun weitestgehend fertig und kann unter
> folgender URL getestet werden:
>
> http://194.95.142.95/fileadmin/statics/validator/metsmods.php
>
> Der Validator basiert auf den kürzlich von den Göttinger Kollegen
> freigegebenen METS- und MODS-Profilen für den Einsatz im Rahmen des
> DFG-Viewers und ZVDD. Die Validierung findet dabei in mehreren
> Schritten statt und gibt bei invaliden Dokumenten Hinweise zum Fehler
> aus.
>
> Eine Integration in die Webseite des DFG-Viewers soll im Laufe der
> kommenden Woche erfolgen.
>
> Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde ich
> mich freuen.
>
> Viele Grüße aus Dresden
> Sebastian Meyer
>
> --
> ___________________________________________________
>
> Sebastian Meyer
>
> Abteilung Informationstechnologie
> 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/
> ___________________________________________________
>
> ***********************************************************************
> ***
>
> Experience the British Library online at www.bl.uk
>
> The British Library's new interactive Annual Report and Accounts
> 2007/08 : www.bl.uk/knowledge
>
> Help the British Library conserve the world's knowledge. Adopt a Book.
> www.bl.uk/adoptabook
>
> The Library's St Pancras site is WiFi - enabled
>
> ***********************************************************************
> **
>
> The information contained in this e-mail is confidential and may be
> legally privileged. It is intended for the addressee(s) only. If you
> are not the intended recipient, please delete this e-mail and notify
> the postmaster(a)bl.uk : The contents of this e-mail must not be
> disclosed or copied without the sender's consent.
>
> The statements and opinions expressed in this message are those of the
> author and do not necessarily reflect those of the British Library. The
> British Library does not take any responsibility for the views of the
> author.
>
> ***********************************************************************
> **
6:30 p.m.
Hallo Sebastian,
uiuiui, das ist ja ein ziemlich niederschmetterndes
Urteil. Aber du hast natürlich recht.
Not your fault. Ich halte einen METS Validator nicht fuer so wirklich einfach.
Allerdings habe ich auch nicht daran gedacht, bei so
grundlegenden Dingen wie der Schema-Referenzierung und den Namespaces mal nachzuhaken,
weil ich das für XML-Grundwissen hielt, das auch ein nicht METS-affiner Entwickler
beherrschen sollte.
Nein, Nein. Ich habe auch hier von Dienstleistern schon METS Dateien erhalten, die nicht
validiert haben. Es ist a) anscheinend zu viel verlangt mal auf nen Knopf zum validieren
zu druecken und b) haben einige XML-Parser/Editor anscheinend noch Probleme beim
validieren von XML Dateien, die Namespaces mischen.
Die Version von XML-Spy, die wir hier einsetzen validiert eine METS Datei, auch wenn die
extension schemas nicht validieren. Es wird kein Fehler festgestellt. Natuerlich sind den
entsprechenden namespaces auch xml schema zugeordnet.
Oxygene dagegen macht das besser.
Besser man trifft weniger Annahmen was XML Erfahrung bei den Entwicklern angeht.
Naja, der Entwicklung lagen die METS/MODS-Profile und
-Dokumentationen zugrunde. Darin sind ja eigentlich sämtliche Pflichtfelder, deren
Beziehungen und möglichen Belegungen klar erläutert. In sofern hat meines Erachtens
eigentlich nur die Festlegung gefehlt, was als Error, Warning bzw. Hint zu behandeln ist
(wobei auch das implizit gegeben ist: Pflichtelemente erzeugen Errors, optionale Felder
Warnings und Empfehlungen Hints - aber da ist eine differenziertere Betrachtung zweifellos
sinnvoll).
Das Problem beim validieren ist, dass man mehr ueber METS wissen muss. Das Profile
beschreibt ja, was erlaubt ist bzw. vorhanden sein muss. Zum validieren muss aber auch
wissen, was NICHT erlaubt ist. Das steht so nicht unbedingt immer explizit im Profil.
Bspw. die Tatsache, dass DMDID auch immer auf dmdSec zeigen sollten.
Auch muessen die Abhaengigkeiten klar sein. Die sind nicht immer so klar im Profil
herausgearbeitet - zumal wir hier ja auch noch zwei Profile haben.
Bestimmte Metadaten sind ebend gerade vom Strukturtyp abhaengig. Teilweise ist sogar der
Aufbau der METS-Datei vom obersten logischen Strukturtyp abhaengig: Zeitschriften und
Mehrbaendige Werke koennen bspw. <mptr> Elemente haben. Seiten aber bspw. nicht,
obwohl formal natuerlich alles ein <div> Element ist.
Der Viewer mag da zwar sehr tolerant sein, jedoch bspw. schon bei einer PDF-Generierung
bei dem die Inhalte fuer die PDF-Metadatenfelder aus unterschiedlichen MODS-Elementen
eines Strukturtyps zusammengesucht und gemergt werden muessen kann dies von Bedeutung
sein.
Ein Manko war sicher, dass wir dem Entwickler nur sehr
begrenzt Beispieldateien zur Verfügung stellen konnten. Wir produzieren ja selbst noch
nicht nativ METS, sondern konvertieren unser internes Format on the fly in sehr
rudimentäres METS (ohne Strukturdaten, ohne Download-Verknüpfungen, etc.), bevor es an den
DFG-Viewer geht.
Ich denke, mehr Beispiele wuerden das Verstaendnis ders Entwicklers foerdern. Ich frage
mich gerade, Stefan Funk nicht zwei Beispiel an die XML-Version des Profils gehangen
hatte.... Ist die eigentlich auch irgendwo downloadbar?
Ein formelles Requirement-Dokument fuer den Entwickler waere vermutlich trotzdem
praktisch.
Vielleicht können wir über die Technik-Liste ja mal
eine Reihe solcher Beispiele sammeln? Das wäre sicher nicht nur für Entwickler solcher
Tools interessant und hilfreich, sondern auch für Kollegen, die selbst vor der Aufgabe
stehen, ihre Digitalisate in METS zu packen.
Sehr gute Idee.
Mit deiner Erlaubnis würde ich deine Ausführungen gerne an den Entwickler weiterleiten.
Klar doch.
Ciao
Markus
**************************************************************************
Experience the British Library online at www.bl.uk
The British Library's new interactive Annual Report and Accounts 2007/08 :
www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It
is intended for the addressee(s) only. If you are not the intended recipient, please
delete this e-mail and notify the postmaster(a)bl.uk : The contents of this e-mail must not
be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not
necessarily reflect those of the British Library. The British Library does not take any
responsibility for the views of the author.
*************************************************************************
22 Dec
22 Dec
7:33 p.m.
Lieber Markus, liebe Kollegen,
es gibt auch noch andere Probleme. Z.B. wird der dv-Namespace wird nicht
geprueft, z.B. ist dies gültig:
<dv:linksxxx xmlns:dv="http://dfg-viewer.de/">
Anbei ein Codeschnipsel, der das behebt. Im METS -Schema muss neben dem
Namespace dies ergaenzt werden:
<xsd:import namespace="http://dfg-viewer.de/"
schemaLocation="dfg-dv.xsd"/>
Mein Kopf sieht uebrigens so aus:
<xsd:schema targetNamespace="http://www.loc.gov/METS/"
xmlns="http://www.loc.gov/METS/"
xmlns:mods="http://www.loc.gov/mods/v3"
xmlns:dv="http://dfg-viewer.de/"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="http://www.w3.org/1999/xlink"
schemaLocation="http://www.loc.gov/standards/xlink/xlink.xsd"/>
<xsd:import namespace="http://www.loc.gov/mods/v3"
schemaLocation="dfg-mods.xsd"/>
<xsd:import namespace="http://dfg-viewer.de/"
schemaLocation="dfg-dv.xsd"/>
Man müsste noch etwas staerker in METS eingreifen, wenn man auf das
Vorhandensein von <dv:rights> und <dv:links> pruefen will (Lokalisierung
von mdSecType). Gleiches gilt für MODS. Es waere auch zu überlegen, was
genau von diesen 6 Elementen des dv-NS da sein muss.
Ein bisschen frage ich mich mittlerweile auch, was die Firma eigentlich
gemacht hat ;-) Zumindest wird nicht zuverlässig geprüft, was nach
unseren Verabredungen minimal da sein muss, und das war doch vermutlich
irgendwie die Idee des Validators.
Viele Gruesse und ein schönes Weihnachtsfest,
Thomas
Enders, Markus schrieb:
Liebe Zielgruppe,
nicht, dass ich Zeit haette, aber ein METS Validator ist schon interessant. Zumal wir
hier mit sehr aehnlichen Problemen kaempfen. Ich habe den Validator zunaechst mal mit der
Datei "metsmods-ok.xml" getestet. Diese validiert lt. Validator, nur paar
Warnings "Verstoss gegen ZVDD Vorgaben".
Was einem auffaellt: In der Datei wird das MODS Schema "mods-3-0.xsd"
referenziert. In der Ausgabe auf dem Bildschirm behauptet der Validator, es wuerde gegen
"http://www.loc.gov/mods/v3/mods-3-3.xsd" validiert werden.
Verwunderung macht sich breit.... Wonach validiert er denn nun?
Und wieso 3.3? Das MODS Anwendungsprofil bezieht sich lt. Profil auf 3.2... IMHO sollte
in der XML-Datei MODS 3.2 referenziert werden und dagegen auch validiert werden.
Aber man kann ja mal ein Blick auf die Datei werfen. Dabei entdeckt man dann folgendes:
Eigenartigerweise sind Grundlage der Testdaten METS Daten die gar nicht aus dem DFG
Kontext kommen, sondern wohl in Berkeley entstanden sind. Deswegen sieht die
Rights-Sektion auch anders aus.
Fast alle URLs zu den extension schemas wie MODS, metsrights etc. Sind falsch gesetzt,
bzw. auch die namespace-Angaben sind falsch.
- URLs wie "http://www.loc. gov/mods/v3" sind nicht nur unschoen sondern
koennen auch nicht gefunden werden. Eine Schema-Validierung kann in Folge dessen auch
nicht stattfinden. Das sehe zumindest ich, wenn ich die Datei in Oxygene oeffne.
- Habe die URLs mal korrigiert und - surprise, surprise mal paar interessante Ergebnisse
gefunden:
Target Namespace fur MIX ist falsch:
- sollte eigentlich http://www.loc.gov/mix/v20 sein (lt. xml schema), ist aber nur auf
http://www.loc.gov/mix/ gesetzt
- Sobald man das mal macht - es gibt einige Fehler. Der MIX Record ist nicht compliant
mit dem MIX schema. Keine Ahnung warum.
MODS Metadaten Record hat auch einen Fehler:
- <mods:typeOfResource> enthaelt einen Fehler; der Wert " still image "
ist nicht zugelassen. Der Wert muss auch einer ennumerated list kommen - und der
entsprechende Wert ist nunmal "still image" (man beachte die Leerzeichen).
- Gibt es einen Grund warum das veraltete 3.0 Schema benutzt wird und nicht 3.2 oder 3.3?
IMHO sollte hier 3.2. benutzt werden, da dies immerhin vom MODS Anwendungsprofil
vorgeschrieben wird.
Habe die entsprechenden URLs mal korrigiert und die MIX records rausgeschmissen. Die sind
ja weder fuer das METS noch fuer das MODS Profil verbindlich vorgeschrieben.
Angehangen mal die "korrigierte" Version.
So wie die Validierung beginnt, geht es auch weiter: Der Validator scheint ja nichtmal
auf xml-Schema Ebene zu validieren, sonst haetten entsprechende Fehler auffallen muessen.
Ueber weitere Fehler wie bspw. fehlerhafte Pointer innerhalb einer METS Datei (AMDID
verweist auf eine dmdSec) gibt es natuerlich auch keine Fehlermeldungen (hab ich anhand
einer modifizierten Datei getestet). D.h. der Validator validiert anscheinend nichtmal auf
Ebene des METS-Datenmodells korrekt.
Eine Ebene tiefer, d.h. auf formeller Ebene des METS Anwendungsprofils darf man ebenfalls
nichts erwarten. Das Anwendungsprofil legt fest:
"Das Seitenbasierte Dokumentenmodell zeichnet sich durch zwei <structMap>
Elemente aus." Und ferner "Das Seitenbasierte Dokumentmodell ist das
Minimalmodell, welches vom DFG-Viewer unterstüzt wird."
IMHO wurde genau dafuer der DFG-Viewer gebaut: Seitenweises blaettern. D.h. die METS
Datei muss eine logische und eine physische Struktur besitzten, da entweder das
Seitebasierte oder das komplexe Dokumentenmodell implementiert sein muss.
Diese validierbare METS Datei hat jedoch keine logische Struktur. Sie besitzt eine
physische Struktur, wobei dessen Strukturdaten keineswegs dem entsprechend, was das METS
Anwednungsprofil vorsieht. Eine <structLink> Sektion fehlt in der METS Datei
natuerlich auch. Wird alles nicht angemeckert durch den Validator.
Wenn also die dritte Ebene (formelle Ebene des METS Anwendungsprofils) nicht validiert
wird, kann die vierte Ebene (Semantik des METS Anwendungsprofils) erst recht nicht
validiert werden. Hierbei wuerde es um Attributwert sowie entsprechende Abhaengigkeiten
zwischen Attributwerden und XML Strukturen (in METS und den Extension-Schemas) gehen.
Ich weiss nicht, ob es sich lohnt, den Sourcecode des Validators zu besorgen. IMHO
koennen dort max. 5% dessen was eine Validierung ausmacht drin stecken. Der Validator ist
vollkommen unbrauchbar :-(
Das verwundert mich ehrlich gesagt nicht. XML ist fuer viele Leute ja nun schon schwierig
genug. METS ist nochmal eine andere Stufe - erst Recht, wenn es dann noch um die
Einbindung von Extensions Schemas geht. Meiner Erfahrung nach ist es recht schwer Arbeiten
dieser Art auszulagern. Das Wissen und Verstaendnis von externen Firmen auf diesem Gebiet
ist nicht gegeben. METS Dateien zu generieren und zu parsen ist fuer viele schon mit einem
hohen Lernaufwand verbunden. Eine Validierung ist nochmal etwas anderes und IMHO
wesentlich komplizierter.
Ich denke ohne aufwendige Requirement-Dokumente wird man hier nicht auskommen. IMHO
sollte fuer jeder der 4 Validierungslevel genau festgelegt werden, welche Elemente und
Semantiken eigentlich validiert werden sollen, und ob das Ergebnis einer fehlerhaften
Teilvalidierung ein Error, Warning, Hint etc ist. Ich weiss nicht, ob solche
Requirement-Dokumente der Entwicklung des aktuellen Validators zu Grunde lagen. (ich
vermute eher nicht).
Allerdings waere es fuer alle hilfreich zu diskutieren, was wir eigentlich validieren
wollen. Nur das METS/MODS Profil soweit es der DFG-Viewer braucht? Oder sollte nicht
eigentlich das komplette Profil validiert werden?
Andere Dienste, wie bspw. ein PDF-Konvertierdienst koennten naemlich ganz andere Teile
benoetigen als bspw. der DFG-Viewer. Der aktuelle Validator meckert bspw. ein Fehlen von
"<mods:identifier
type="urn">urn:nbn:gbv-7-PPN481399712</mods:identifier>" nicht an.
Fuer den Viewer mag das nicht wichtig sein. Fuer andere Dienste aber durchaus.
Ich wuerde sagen: Zurueck auf Los und nochmal anfangen.
Ansonsten allen Diskutierenden schoene Weihnachten... Haben wir ja gleich was zu tun nach
der Ruhepause ;-)
Ciao
Markus
-----Original Message-----
From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-viewer.de] On
Behalf Of Meyer, Sebastian
Sent: 03 December 2008 15:12
To: technik(a)dfg-viewer.de
Subject: [DFG-Viewer] METS/MODS-Validator
Liebe Kolleginnen und Kollegen,
der METS/MODS-Validator ist nun weitestgehend fertig und kann unter folgender URL
getestet werden:
http://194.95.142.95/fileadmin/statics/validator/metsmods.php
Der Validator basiert auf den kürzlich von den Göttinger Kollegen freigegebenen METS- und
MODS-Profilen für den Einsatz im Rahmen des DFG-Viewers und ZVDD. Die Validierung findet
dabei in mehreren Schritten statt und gibt bei invaliden Dokumenten Hinweise zum Fehler
aus.
Eine Integration in die Webseite des DFG-Viewers soll im Laufe der kommenden Woche
erfolgen.
Über reges Testen, Hinweise auf Fehler und andere Anmerkungen würde ich mich freuen.
Viele Grüße aus Dresden
Sebastian Meyer
--
___________________________________________________
Sebastian Meyer
Abteilung Informationstechnologie
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/
___________________________________________________
**************************************************************************
Experience the British Library online at www.bl.uk
The British Library's new interactive Annual Report and Accounts 2007/08 :
www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally privileged.
It is intended for the addressee(s) only. If you are not the intended recipient, please
delete this e-mail and notify the postmaster(a)bl.uk : The contents of this e-mail must not
be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not
necessarily reflect those of the British Library. The British Library does not take any
responsibility for the views of the author.
*************************************************************************
5627
days inactive
5646
days old
16 comments
6 participants
participants (6)
-
Christian Mahnke -
Dr. Thomas Staecker -
Enders, Markus -
Jochen Kothe -
Meyer, Sebastian -
staecker