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

Move Sigla to 024 #1590

Open
ahankinson opened this issue May 29, 2024 · 11 comments
Open

Move Sigla to 024 #1590

ahankinson opened this issue May 29, 2024 · 11 comments

Comments

@ahankinson
Copy link
Contributor

This is a proposal to move the sigla field in institutions from 110 $g to 024. This move will allow for the capture of obsolete sigla, as well as 024 being a more appropriate field for this kind of data. (024 is "Other Standard Identifier", whereas 110 $g is "Miscellaneous Information")

The new arrangement would be:

  • $a: Non-Repeatable. Holds the current siglum for an institution
  • $2: Non-Repeatable. Would be the source of identifier, likely the string rism
  • $q: Non-Repeatable. Would be the string siglum to mark the RISM identifier as a RISM siglum
  • $z: Repeatable. Would hold all previous sigla that were assigned to that institution.

So, the 024 for https://rism.online/institutions/30077306 would be:

=024  ## $aV-CVbav $2rism $qsiglum $zI-RVat

One feature that was requested in the discussions of this change was that the Siglum entry be visually kept with the header information in 110 and not held in the "General" 024 section. This is to keep all the institution's "vitals" in one place.

So a user-friendly implementation might have a dedicated 024 entry in institutions in the same block as the 110, with $2 and $q already filled in when the record is saved, and the cataloger only needs to supply the values for $a and $z.

The data would need to be migrated. Since we don't have any formal way of tracking former sigla, there is no data to be migrated for $z, and these values would need to be supplied post hoc.

We would also need to inform the BSB of the potential change in data, and modify RISM Online once the data migration has happened.

@lpugin
Copy link
Contributor

lpugin commented Jun 12, 2024

Since it seems difficult to find a dedicated place for the RISM sigla in MARC and that having it in 024 in Muscat would need tailored developments, maybe we can consider the following option:

  1. We use an internal 094 modelled after 024 that is a non-repeatable and with the subfields as suggested above by @ahankinson. That is, a non-repeatable$a for the current siglum, and a repeatable $z for olim sigla.
  2. In Muscat, 094 is labelled "RISM siglum information" and placed close to 110. 110 $g is removed in Muscat.
  3. In the export to MarcXML (SRU, BSB, VIAF), 094 is converted to 024 with an additional $2 (one problem is that rism is not an official code, though. This needs to be clarified.). 110 $g would be added in the export.

The compromise would be:

  • No custom development for handling siglum instances of 024 in Muscat
  • A dedicated place for curating sigla in Muscat
  • Proper MARC use (024) and siglum in 110 for backward compatibility and clarity

@lpugin
Copy link
Contributor

lpugin commented Jun 12, 2024

(There is here a fax number where we can request for a new code to be added)

@lpugin
Copy link
Contributor

lpugin commented Jun 12, 2024

Looking at the possible places for the sigla, I previously thought about 035. @ahankinson pointed out that this would not be acceptable because 035 is meant to be a number. However, looking at some usage of it, I can see that, for example, LC and GND use it with values that are not strictly speaking a number. See this example. GND will have things like (DE-588c)7617194-2. So if we are looking at an alternative to the proposal I made above, then 035 looks like an acceptable option to me.

@ahankinson
Copy link
Contributor Author

035 doesn't seem to have a $q for an application note, or a $2 for the source / assigning authority. The convention seems to be to put that in the front of the number, e.g., (CaBVaU)2835210335, which I don't think we want to do?

@lpugin
Copy link
Contributor

lpugin commented Jun 12, 2024

Yes, you are right. I guess it would be something like (rism)V-CVbav, or (DE-633)V-CVbav - Edit: but that does not mean when need to have it maintained like this in Muscat.

@ahankinson
Copy link
Contributor Author

Yeah, it would be (DE-633)V-CVbav.

We can always do something different in Muscat, but the docs do explicitly say:

MARC code (enclosed in parentheses) of the organization originating the system control number, followed immediately by the number.

@lpugin
Copy link
Contributor

lpugin commented Jun 12, 2024

What I am saying is that the export can add the (DE-633). In the internal MARC data and in the editor we would have only V-CVbav. Only the exported MARC would show (DE-633)V-CVbav. That is something we do in other places (e.g., $0 being 123 in the internal MARC, and sources/123 in the exported MARC.

@xhero
Copy link
Contributor

xhero commented Jun 19, 2024

Standby: waiting for report from RISM C people

@jenniferward
Copy link
Contributor

Reply from Series C group: Taking as an example https://muscat.rism.info/admin/institutions/30006007?view=MARC21

=024 8#$aGR-NApl$zGR-Npl
=110 1#$aPeleponnēsiako Laographiko Hidryma$cNáfplion

@xhero
Copy link
Contributor

xhero commented Jul 17, 2024

This is how the propose it should be?

@jenniferward
Copy link
Contributor

Yes, that is their proposal: Delete 110$g and store current sigla and old sigla in 024.

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

7 participants