Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New fields, a request. #260

Closed
textbrowser opened this issue Dec 7, 2022 · 21 comments
Closed

New fields, a request. #260

textbrowser opened this issue Dec 7, 2022 · 21 comments

Comments

@textbrowser
Copy link
Owner

To manage the documents properly, we would need 3 additional fields:

purchase date (date type fields)
date of reform (exit) (date type fields)
origin of the documents (text - if possible enumeration database)
@meteos77
Copy link
Contributor

Distinguishing fields between
the material description (unimarc 215)
and
the literary description (unimarc 330)

@meteos77
Copy link
Contributor

meteos77 commented May 4, 2023

the material description
Unimarc_215_to_Marc21_300

@meteos77
Copy link
Contributor

meteos77 commented May 4, 2023

the literary description
Unimarc_330-to_Marc21_520

@textbrowser
Copy link
Owner Author

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.

@textbrowser
Copy link
Owner Author

And maybe enumerations too which require database, interface, and logic revisions. Then assignment into book items. Yup, huge.

@textbrowser
Copy link
Owner Author

Print revisions.

@meteos77
Copy link
Contributor

meteos77 commented Aug 1, 2023

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.

@textbrowser
Copy link
Owner Author

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. :)

@meteos77
Copy link
Contributor

meteos77 commented Aug 1, 2023

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 :-)

@textbrowser
Copy link
Owner Author

Please provide sample ISBNs which cover the new fields.

@meteos77
Copy link
Contributor

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

@textbrowser
Copy link
Owner Author

Please map:
date_of_reform -> field?
etc.

And are 215 + 330 UNIMARC? If so, what are 330 + 520 for?

@meteos77
Copy link
Contributor

meteos77 commented Sep 1, 2023

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.

Traduction-Recommandation-995.pdf

@meteos77
Copy link
Contributor

meteos77 commented Sep 1, 2023

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.

@textbrowser
Copy link
Owner Author

:)

@meteos77
Copy link
Contributor

meteos77 commented Sep 3, 2023

Is my answer right?

@meteos77
Copy link
Contributor

meteos77 commented Sep 3, 2023

Zone300

source : https://www.marc21.ca

@meteos77
Copy link
Contributor

meteos77 commented Sep 3, 2023

Zone520

source : https://www.marc21.ca

@textbrowser
Copy link
Owner Author

Nope not yet.

@textbrowser
Copy link
Owner Author

OK, so if the librarian will be supplying the information, we don't need to modify the queries to retrieve that information. All done!

@textbrowser
Copy link
Owner Author

OK, now I can include your new translations after you're set and then prepare a release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants