Closed textbrowser closed 1 year ago
Distinguishing fields between the material description (unimarc 215) and the literary description (unimarc 330)
the material description
the literary description
Huge work. 3 fields: two database engines. PQ: two files. SQ: two files. SQ: upgrade process. Display fields in main table. Search revisions. Export revisions. Import revisions. Book revisions (interface and logic). And then there are the MARC / UNI parsers.
And maybe enumerations too which require database, interface, and logic revisions. Then assignment into book items. Yup, huge.
Print revisions.
Every library wants to have software that can store all the elements it needs to manage its requirements. We know that it's a big job for you to add fields, as many functionalities are affected each time, and we thank you very much for adding some of them (public, volume_number).
With your description of things to do and the example of the new volume_number field, I've tried to create a new field physical_description.
Status two database engines. PQ: two files. file: SQL/postgresql_create_schema.sql -> not tested. file: SQL/postgresql_update_schema.sql -> untested.
SQ: two files. => OK SQ: upgrade process. => OK Display fields in main table. => OK Search revisions. => NOK Export revisions. => OK Import revisions. => OK Book revisions (interface and logic) interface UI => OK logic ??
MARC / UNI parsers. -> It's hard! And maybe enumerations too which require database, interface, and logic revisions. Then assignment into book items. Print revisions.
Could you please help me with the Search functionality as I haven't found what's causing the problem.
Will try to have your new fields completed by the end of August. There will be a single commit which can be considered as documentation. So, it has to be correct. :)
It will be great to have the commit in the form of documentation. I'm already pretty happy with myself ... even if it's just a copy of volume_number :-)
Please provide sample ISBNs which cover the new fields.
with the Sudoc server (French): 978-2295-0068-99 = fields 300 & 520 978-2379-2219-41 = fields 300 & 520
With addition of a Bnf Z39.50 server with analytical records (330) (biblioteq.conf)
[Z39.50-8]
name = BnF Z3950
database_name = TOUT-ANA1-UTF8
format = utf-8
hostname = z3950.bnf.fr
port = 2211
proxy_host =
proxy_port =
record_syntax = UNIMARC
timeout = 10
username = Z3950
password = Z3950_BNF
The same isbns 978-2295-0068-99 = fields 215 & 330 978-2379-2219-41 = fields 215 & 330
Please map: date_of_reform -> field? etc.
And are 215 + 330 UNIMARC? If so, what are 330 + 520 for?
date_of_reformation; origin; date_of_purchase are information such as condition or location, it is the library that knows when it bought the book or when it was reformed, and where the book comes from.
I intend to use these fields for the unimarc 995$a (origin) ; 995$m (purchase_date) ; 995$n (date_of_reform) but this concerns the unimarc files (.pan) supplied by our central library with the French recommendation (995) for the exchange of information between libraries.
Marc21 300 : Physical Description Marc21 520 : Description (Summary)
Unimarc 215 : Physical Description Unimarc 330 : Description (Summary)
To test the 330, you need to add the info (biblioteq.conf) for the Bnf server that provides this field with the TOUT-ANA1-UTF8 database.
:)
Is my answer right?
source : https://www.marc21.ca
source : https://www.marc21.ca
Nope not yet.
OK, so if the librarian will be supplying the information, we don't need to modify the queries to retrieve that information. All done!
OK, now I can include your new translations after you're set and then prepare a release.
To manage the documents properly, we would need 3 additional fields: