BnF SRU Server

[meteos77]

with firefox I get a result
with BiblioteQ I can't translate in the bibliteq.conf file

the [SRU-2] for the BbnF server
it respects the version 1.2 of SRU according to the notice

[SRU-2]
name = Bibliothèque nationale de France
proxy_host =
proxy_password =
proxy_port =
proxy_type = None
proxy_username =
url_isbn = "https://catalogue.bnf.fr/api/SRU?version=1.2&operation=searchRetrieve&query=bib.isbn adj %1"

or
url_isbn = "https://catalogue.bnf.fr/api/SRU?version=1.2&operation=searchRetrieve&query=bib.isbn adj "978-2-211-21125-3""

problem with quotation marks?

isbn-13 : 9782355848858

https://catalogue.bnf.fr/api/SRU?version=1.2&operation=searchRetrieve&query=bib.isbn adj "9782355848858"

[textbrowser]

Try url_isbn = "https://catalogue.bnf.fr/api/SRU?version=1.2&operation=searchRetrieve&query=bib.isbn adj '%1'".

[textbrowser]

a732c4d

:)

[meteos77]

SRU Query Error
An SRU entry may not yet esist for the provided ISBN(s)

[textbrowser]

You have to reload biblioteq.conf or restart the program.

[textbrowser]

[meteos77]

same problem as with Z3950 - UTF8 / ISO8859-15

[meteos77]

it's ok with ISO8859-15

[meteos77]

the interpretation on the other hand does not work well
ex : 9791027607129
the title is not taken ...

there are 5 xml export formats

By default, the output format is unimarcXchange (Unimarc encapsulated in MarcXchange).

Unimarc format with analytics (encapsulated in MarcXchange) : "unimarcXchange-anl".
&recordSchema=unimarcXchange-anl

Intermarc format (encapsulated in MarcXchange)
&recordSchema=intermarcXchange

Intermarc format with analytics (encapsulated in MarcXchange) : "intermarcXchange-anl
&recordSchema=intermarcXchange-anl

Dublin Core format: "dublincore".
&recordSchema=dublincore

Translated with www.DeepL.com/Translator (free version)

[textbrowser]

Peruse biblioteq_marc.cc and see what needs to be added / fixed. :)

[meteos77]

all that concerns unimarc is not filled :-)
is MARC21 the format of the library of congress ?

[textbrowser]

My level of interest in parsing (and correcting the parsers) reached zero many years ago. :P

[textbrowser]

I have received numerous requests to correct / amend the parsers and whenever I do, something is broken for some obscure library or example or XML format.

[textbrowser]

I hope you're not upset with my emotional resistance to parsing. :)

[textbrowser]

I will look after correcting the new ticket.

[textbrowser]

People don't understand the complexities of library software. Or catalogs. It's an unclear frontier.

[meteos77]

there are a lot of standards and for me it's a lot of liners not too much evolution so the standards coexist for a very very long time
which doesn't facilitate development.
between 2 national libraries, they could respect the same version of standard or have a compatible standard during the transition.

[textbrowser]

Did I mention SQL? I did, right? I think I mentioned SQL. Now I'm mentioning SQL. :)

[textbrowser]

If you were able to connect to their database and extract the specific fields, it would be splendid. It's what their interface does. But they hide the databases through formats upon formats. It's quite a stupid solution because of security. Or something.

[textbrowser]

In BQ, you don't need BQ. You can write your own software to do whatever extraction and manipulation you need. BQ presents the data. That's it. Well, a little bit more than that.

[textbrowser]

I would prefer a library to parse these fields so I can simply issue results.value(field). The present solution requires that I maintain several complex parsers.

[meteos77]

We didn't understand each other, I thought you were interested in the unimarc standard.
for me BiblioteQ, perfectly meets our needs concerning Z3950 and SRU

[meteos77]

my message from 3 days ago
the Unimarc parser for Z3950 works very well it allows to retrieve the records without any problem

[textbrowser]

I didn't see this message. :)

[meteos77]

I'm going to sleep :-)

[textbrowser]

Are you at the library?

[meteos77]

by adding the format &recordSchema=intermarcXchange to the SRU line,
I have the Title OK ; Authors OK ;Place of Publication OK - Publisher KO

[textbrowser]

"Automatic" parsing? I will look at all of that again. Maybe it can be improved.

[meteos77]

if possible harmonize the version in 1.2 this will allow to detect problems on the 2 servers at the same time and do the work only once:-)

the dream is that everyone passes in 2.0 but ... in 2040 (I try to inquire at the Bnf)

[meteos77]

in biblioteq.conf add &recordSchema=intermarcXchange"

complete line 👍
url_isbn = "https://catalogue.bnf.fr/api/SRU?version=1.2&operation=searchRetrieve&query=bib.isbn adj '%1' &recordSchema=intermarcXchange"

the problem of encoding the configuration file is present
if UTF-8 the Bnf SRU does not work (the SRU Bnf output is in UTF-8 according to their documentation)
if ISO8859-15 SRU Ok but then accented characters are incorrectly presented.

statement: your query to the Library of Congress SRU service is in version 1.1 (searchRetrieve&version=1.1)

[textbrowser]

Committed.

[textbrowser]

OK, I'm now looking at the SRU query.

[textbrowser]

Will look at this later. It can be improved.

[textbrowser]

Parsing of UNIMARC data for books is not implemented. :) That's a problem.

[meteos77]

the Unimarc parser for Z3950 works very well it allows you to retrieve the records without any problem

[textbrowser]

I made a change so that UNIMARC is parsed using MARC21 for SRU. If you can find the UNIMARC standard for SRU, I'll add it.

[meteos77]

I made a small assessment of Z39.50 and SRU with the French servers.

bilan-Z3950-SRU-France.txt

for Z3950 Sudoc: from what I observe the codes 0098 and 009C would be there to specify that the title contains an article which is not used for classification in certain cataloguing.
the 1st one is for example
discreet charm of the intestine or the discreet charm of the intestine

request : delete these 2 useless codes in the titles
the Sudoc server propagates the 10/10 documents

for the Z3950 Bnf : problem of end of the title field, you take the 200 $a (title) and 200 $b (printed text)

request : remove the 200 $b from the title
the Bnf Z3950 server propagates the 9/10 documents

for the SRU Bnf : it's the one that works the best :-)
the BnF SRU server propagates the 9/10 documents

[meteos77]

for you the migratory birds
0098the009cmigratory birds

if your proposal is we delete the 2 ascii codes (0098 and 009c)
it's great but we keep "the"

[textbrowser]

Can you paste a sample MARC Tags for each query?

[meteos77]

what sample ?

[textbrowser]

You performed a query via Z39.50 Sudoc. Paste the results of the query. :)

[meteos77]

txt format

[meteos77]

9782330048815.txt

[meteos77]

9782330048815.txt
full version

[meteos77]

02560cam0 2200529 450
001 185219861
003 http://www.sudoc.fr/185219861
005 20210201142302.000
010 $a 978-2-330-04881-5 $b br. $d 21,80 EUR
035 $a (OCoLC)908129151
073 1 $a 9782330048815
100 $a 20150428h20152015m y0frey50 ba
101 1 $a fre $c ger
102 $a FR
105 $a a a 000yy
106 $a r
181 $6 z01 $c txt $2 rdacontent
181 $6 z02 $c sti $2 rdacontent
181 1 $6 z01 $a i# $b xxxe##
181 1 $6 z02 $a b# $b xb2e##
182 $6 z01 $c n $2 rdamedia
182 $6 z02 $c n $2 rdamedia
182 1 $6 z01 $a n
182 1 $6 z02 $a n
183 1 $6 z01 $a nga $2 RDAfrCarrier
200 1 $a �Le �charme discret de l'intestin $e tout sur un organe mal aimé $f Giulia Enders $g illustrations par Jill Enders $g traduit de l'allemand par Isabelle Liber
214 0 $a Arles $c Actes Sud $d DL 2015
215 $a 1 vol. (350 p.) $c ill., couv. ill. $d 22 cm

[textbrowser]

That does not include 200. :) OK, I'll create an example myself and test.

The idea is that BQ will remove everything between $b to the next field, including $b. This is for Z39.50. We can look at SRU later.

I will not be able to complete this today. Tomorrow's the release.

[meteos77]

9782330048815-Z3950-pb-200$b.txt

source Z3950 BnF server

[meteos77]

Anyway the BnF conf in Z39.50 is not included in the release so there will be no worries, I'm a step ahead :-)

[meteos77]

give all your energy in the output, my requests can wait

[meteos77]

for me the SRU server is the best ; the SRU file was to show you the difference