Should secondary literature have more than one template?

[fjorba]

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?

[MFalletta]

Great idea! I agree

[jenniferward]

Me too!
If it helps, I made a very short guide (aimed at Muscat contributors) that talks about the different types of secondary literature in Muscat. It briefly explains fields needed for different types of materials - it might give you some ideas:
http://www.rism.info/fileadmin/content/community-content/Muscat_EN/Secondary_lit_brief_guide.pdf

[fjorba]

Thank you, I'll take it into account.

[xhero]

I think it is doable, you would add a record_type like in source right?

[fjorba]

My idea was to mimick source model as much as possible, with the obvious changes (composer to author, for example).

I think it is doable, you would add a record_type like in source right?

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.

[ahankinson]

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.

[fjorba]

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.

[xhero]

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.
To make it work as source, you will probably need to add a record_type attribute to keep information on the proper template, and then as in source select the right tags to display (all of them should exist in the tag configuration). You will also need to make the appropriate "empty" templates used when creating a new source. I think that should be it!

[fjorba]

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.

[xhero]

I'm not sure I follow completely. record_type is used to attach a template to a source, and a template being basically a selection and grouping of marc tags. Since marc specification for authority files and bibliographic records is different, it seems to me the templates are something that should be tailored to each particular model they are used on.

[fjorba]

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.

[jenniferward]

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.

[fjorba]

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:

1. Create the infrastructure to allow different templates (a future pull request to be linked to this issue).
2. Have a single default template (the current one), to start with. All current records stay here, with the corresponding record_type for this default template (probably in a the same pull request above).
3. Create a second, specific template. I would start with journal article, because it has less variability.
4. Change journal articles from the default record_type to this future journal article record type. At the same time, change the dubious tags to better tags (current 240 to 245, and 520 to 362, for example). That should have a specific issue, of course (related to Secondary literature: change 240 to 245 #626). I don't think that I can do it, probably it should be done with a maintenance script run by your team.
5. Create a third template, maybe monograph.
6. Do the same changes with monograph records.
7. Continue until all secondary literature records have their specific record type and their tags corrected.

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.

[jenniferward]

To address the first part of your question: Yes, it's similar in nature in that the tag is incorrect.
Not to further complicate matters, but I should point out that 520 is called "Contents note" in the Secondary Literature, but "Contents note" in MARC is more correctly 505. A 520 note would be more of a summary. Both 505 and 520 would likely be useful for publications, though.

[fjorba]

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

[xhero]

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.

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.
The default_mapping maps the template to the template file. It used to me automagic but we decided it was less confusing to have the mapping explicit. The names 000_collection are the template files to read.