interessant, da wir gerade in den letzten Tagen den SRU-Service in etwas
größerem Maßstab angezapft haben, vielleicht haben Sie ja bereits in den
Logs eine kleine Anfrage-Spitze bemerkt -- wir haben einfach mal unseren
Komplettbestand abgeglichen ;-)
Habe grad mal unser Anfrage-Skript auf den neuen Server gelenkt,
funktioniert beim ersten Drübersehen problemlos.
Wir versuchen hier lokal, als kleine Forschungsbibliothek ohne
Verbundanbindung im Rahmen unserer Möglichkeiten die bestehenden Angebote so
gut es geht wahrzunehmen; der SRU-Service vom GBV ist da für uns auf jeden
Fall eine interessante Option.
Können Sie etwas dazu sagen, wie lange der alte Service noch verfügbar sein
wird?
Beste Grüße,
Daniel Zimmel
--
Daniel Zimmel Tel. +49 228 91416-17
Max-Planck-Institut zur
Erforschung von Gemeinschaftsgütern, Bonn ||/| Bibliothek
> --
> Sie haben diese Nachricht erhalten, da Sie der Google
> Groups-Gruppe bibcode beigetreten sind.
> Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden
> Sie eine E-Mail an bib...@googlegroups.com.
> Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine
> E-Mail an bibcode+u...@googlegroups.com.
> Besuchen Sie die Gruppe unter
> http://groups.google.com/group/bibcode?hl=de, um weitere
> Optionen zu erhalten.
Der Prototyp der neuen SRU funktioniert wirklich gut, allerdings sind
mir zwei Dinge aufgefallen.
1/ Der Standardwert für maximumRecords ist 0, d.h. wenn der Parameter
in der Suchanfrage weggelassen wird, liefert die SRU keine
Records. Nicht wirklich ein Problem, nur etwas unerwartet.
2/ Möglicherweise hat sich ein Fehler in der Konfiguration
eingeschlichen, denn ich kann bei einer erfolgreichen Suche mit mehr
als 1000 Treffern die Records ab Position 1001 nicht abrufen. Die SRU
behauptet trotzig, dass zum Beispiel der Record 1001 einer Suche mit
3440 Treffern "out of range" sei.
#+begin_src xml
<?xml version="1.0" encoding="UTF-8"?>
<zs:searchRetrieveResponse xmlns:zs="http://www.loc.gov/zing/srw/">
<zs:version>1.1</zs:version>
<zs:numberOfRecords>3440</zs:numberOfRecords>
<zs:diagnostics xmlns:diag="http://www.loc.gov/zing/srw/diagnostic/">
<diag:diagnostic>
<diag:uri>info:srw/diagnostic/1/61</diag:uri>
<diag:message>First record position out of range</diag:message>
</diag:diagnostic>
</zs:diagnostics>
</zs:searchRetrieveResponse>
#+end_src
Was natürlich bei 3440 zs:numberOfRecords nicht stimmen kann. Ist
dieses Problem bekannt?
Beste Grüße,
-- David Maus
--
David Maus
Projekt HAB 2.0
Herzog August Bibliothek - D-38299 Wolfenbuettel
Phone: +49-5331-808-379
Email: ma...@hab.de
#+begin_src fundamental
Z> open z3950.gbv.de:20010/hab_opc
Connecting...OK.
Sent initrequest.
Connection accepted by v3 target.
ID : Pica tolkzp
Name : Pica tolkzp Z39.50 Gate (YAZ Proxy)
Version: 4.0 (DBV-OSI II API 2.2)/1.3.5
Options: search present delSet scan sort extendedServices namedResultSets
Z> find @attr 1=1016 helmstedt
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 21954, setno 3
records returned: 0
Z> show 21954
Sent presentRequest (21954+1).
Records: 1
[hab_opc]Record type: USmarc
00790nam a22001932i 4500
001 149932782
003 DE-601
005 20061213152656.0
008 940428 000 0 ger d
040 $a GyGoGBV $b ger $e rakwb
041 0 $a ger
100 1 $a Ruer, Julius Wilhelm $0 (DE-601)145020010.
245 10 $a Nachrichten \374ber die Jrrenanstalt zu Marsberg im
Herzogthum Westfalen, nebst Bemerkungen \374ber die Behandlung der
Jrren / $c Wilhelm Ruer.
260 3 $a o.O., $c s.a.
300 $a 8\260
500 $a Aus: Zeitschrift f\374r psychische \304rzte. Bd 2. 1818. H. 1.
951 $a MED Qd. 2.1.4.10 / Marsberg $a MED Gl. / Geschichte und
Beschreibung einzelner Krankenanstalten und medizinischer Institute $2
50
900 $a GBV $b HAB Wolfenb\374ttel <23> $d M: Mx 136 (4) $x L $z LC
954 $a 50 $b 12273209X $c 01 $d M: Mx 136 (4) $e b $x 0023
nextResultSetPosition = 0
Z> exit
#+end_src
Da fällt dann zwar kein PicaXML raus, aber die Transformation von
Pica+ nach PicaXML ist kein großer Schritt.
@gbv: Wenn die Beschränkung auf maximal 1000 Records besteht, dann
sollte aus meiner Sicht die SRU Schnittstelle diese Beschränkung auch
gegenüber einem Client kenntlich machen.
Soweit ich die Specs verstanden habe ist das allerdings nicht so ohne
weiteres möglich; Entweder müsste in der searchRetrieveResponse die
Anzahl der Treffer auf 1000 korrigiert werden oder, vielleicht besser,
ab dem 1001ten Eintrag anstelle der Records eine Diagnostic als
Surrogat geliefert werden:
http://www.loc.gov/standards/sru/specs/search-retrieve.html
#+begin_quote
The records parameter in the response is a sequence of record
elements, each of which contains either a record or a surrogate
diagnostic explaining why that particular record could not be
transferred. If the record schema is unknown or the record cannot be
rendered in that schema, then the server MUST return a diagnostic.
#+end_quote
Beste Grüße,
-- David
Thank you very much for trying the new SRU service and providing feedback.
In response to your message, we have improved the server so that it will
present hits beyond the first 1000.
This even works for those databases hosted on gso.gbv.de (e.g. the main GVK
database) that are restricted to the first 1000 hits when accessed through
other interfaces. We may have to reconsider this particular exception if it
turns out to cause performance problems, in which case we will change the
server so that it responds with surrogate diagnostics instead.
Please try the new version and let us know if you find any problems.
Best regards,
Jaap
On Thu, Jun 23, 2011 at 11:40:43AM +0200, David Maus wrote:
> Einen Hinweis off-list und einige kb Recherche sp�ter scheint es mir
> nicht an der PSI "an sich" zu liegen. F�r den Zugriff auf unsere
> Katalogdaten mittels z39.50 gibt es diese Einschr�nkung zu meiner
> Da f�llt dann zwar kein PicaXML raus, aber die Transformation von
> Pica+ nach PicaXML ist kein gro�er Schritt.
>
> @gbv: Wenn die Beschr�nkung auf maximal 1000 Records besteht, dann
> sollte aus meiner Sicht die SRU Schnittstelle diese Beschr�nkung auch
> gegen�ber einem Client kenntlich machen.
>
> Soweit ich die Specs verstanden habe ist das allerdings nicht so ohne
> weiteres m�glich; Entweder m�sste in der searchRetrieveResponse die
> Anzahl der Treffer auf 1000 korrigiert werden oder, vielleicht besser,
> ab dem 1001ten Eintrag anstelle der Records eine Diagnostic als
> Surrogat geliefert werden:
>
> http://www.loc.gov/standards/sru/specs/search-retrieve.html
> #+begin_quote
> The records parameter in the response is a sequence of record
> elements, each of which contains either a record or a surrogate
> diagnostic explaining why that particular record could not be
> transferred. If the record schema is unknown or the record cannot be
> rendered in that schema, then the server MUST return a diagnostic.
> #+end_quote
>
> Beste Gr��e,
> -- David
> --
> David Maus
> Projekt HAB 2.0
> Herzog August Bibliothek - D-38299 Wolfenbuettel
> Phone: +49-5331-808-379
> Email: ma...@hab.de
>
> --
> Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe bibcode beigetreten sind.
> Wenn Sie Nachrichten in dieser Gruppe posten m�chten, senden Sie eine E-Mail an bib...@googlegroups.com.
> Wenn Sie aus dieser Gruppe austreten m�chten, senden Sie eine E-Mail an bibcode+u...@googlegroups.com.
At Mon, 27 Jun 2011 11:47:43 +0200,
Jaap Lutz wrote:
>
> Hi David,
>
> Thank you very much for trying the new SRU service and providing feedback.
>
> In response to your message, we have improved the server so that it will
> present hits beyond the first 1000.
>
> This even works for those databases hosted on gso.gbv.de (e.g. the main GVK
> database) that are restricted to the first 1000 hits when accessed through
> other interfaces. We may have to reconsider this particular exception if it
> turns out to cause performance problems, in which case we will change the
> server so that it responds with surrogate diagnostics instead.
>
> Please try the new version and let us know if you find any problems.
Hi Jaap,
Thanks a bunch, this is great news. Now I can focus on the SRU client
library instead of fiddling with Yaz' PHP bindings which are APITA to
install on my MS Windows based system.
If there are any performance related problems with our database
(opac-de-23) feel free to drop a message so I can look into it.
Best,