-
Notifications
You must be signed in to change notification settings - Fork 16
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
Should secondary literature have more than one template? #1013
Comments
Great idea! I agree |
Me too! |
Thank you, I'll take it into account. |
I think it is doable, you would add a record_type like in source right? |
My idea was to mimick source model as much as possible, with the obvious changes (composer to author, for example).
I have a prototype working in my local machine, but now I don't remember the details, it was just a proof of concept that I could do it. It was running some weeks ago, I'll have to refresh my memory. But yes, if you count on record_type being there, I'll double check that it is there. Obviously I'll require your review, and I'll appreciate your comments. |
A heads-up that there are some changes coming for languages (#1004) that will probably affect this work, since (I believe) you will need a "Labels" file that gives the translations for each field. |
What a nice moment for such a change! (Yes, I'm sure it is never a good moment for such a change...) Do you consider that I should your patch before I publish mine, so I can understand how it affects the rest of the cataloguing files? My idea is to prepare the infrastructure for choosing templates for 7.0. If I can create a new one (maybe starting with journal article), great, but that would be a second step. |
I think at the end it should not really change that much on the implementation side of things for the templates, as the languages are managed (more or less) transparently in the backend. |
Thanks, I haven't really started yet, but I'll keep that in mind. However, I do have a first question: would you prefer a single, unified, record_type list for both bibliographic (sources or secondary literature) records, or two lists? Intuitively, I would say a single one, like there is a single authority record list for persons, institutions, etc. However, I'd probably say that it should be a configuration file, not a model, db table and so on, as it is closely tied to configuration files, and so it belongs to installation data, not to (user supplied) bibliographic information. |
I'm not sure I follow completely. |
I was referring to (re)use the same RECORD_TYPES list in https://github.com/rism-ch/muscat/blob/develop/lib/marc_source.rb. Should I? I digged somewhat into this list when debugging #934, but then I found some redundancy with default_mapping in https://github.com/rism-ch/muscat/blob/develop/config/marc/default/source/template_configuration.yml#L60. |
Something related but separate: Could you @fjorba perhaps take a look at Secondary Literature's field 520 in the context of your activities here? It's called "Contents note" but this is incorrect. The field is meant to describe dates of publication, like for serials, and indeed that's what it has been used for if you look at the data (example: https://muscat.rism.info/admin/catalogues/50005776). This corresponds to MARC 362 instead. |
Is this change from 520 tags to 362 (I agree about it, but 520 should also exist) like the one from 240 to 245 in #626 (I also agree), @jenniferward? I don't know how do you handle those corrections, and how do you coordinate Muscat data with the public RISM opac, and I feel very insecure about proposing anything. However, a possible path to correct those tags could be:
But, again, this may not be the way you work at the ZR and the Muscat develoment team, so I'm just guessing. So sorry if I'm completely wrong with my proposal. |
To address the first part of your question: Yes, it's similar in nature in that the tag is incorrect. |
Thank you, @jenniferward. Maybe this new template mechanism could be a good moment to review the current used tags and subfields for secondary literature? For example, besides the tags you have mentioned, for journal articles, the title of the journal, issn, related parts should go to 773, as stated in the standard (https://www.loc.gov/marc/bibliographic/bd773.html) rather than the current 760 (https://www.loc.gov/marc/bibliographic/bd760.html). The LoC examples are clear enough. 760 could be used for monographs (although we don't use it in any of our systems). I know that changes tags affect many other parts, like indexing, display, etc., but what I'd like to know if you all think that the right moment can be now, as we create specific templates for different document types. I don't know either (I haven't had the time to investigate it) if this use of 773 in secondary literature conflicts with the current use in sources (that I suspect that should be 760, but that's another story). |
I don't think we should necessarily reuse those templates, as they are very specific to musical sources. At the end a template is really just a list of tags to show/not show for a particular record and they are tailored to the different data types. |
Currently, in Muscat there are different templates for sources, because different document types require different fields (Marc tags and subfields) and defaults. I think that secondary literature should have the same capability, because the document types are so different that they require different fields (for example: a journal article and a book monograph).
I volunteer to prepare the infrastructure for that, now that the two models are aligned (#987). My proposal is to start with a list of a single document type, the current one (we can call it Default, to start with), but that would open the door to easily create others.
What do you think?
The text was updated successfully, but these errors were encountered: