New global config variable: MAIN_BIBLIOGRAPHIC_RECORD_TYPE

[fjorba]

Muscat was created for cataloguing musical manuscripts (Sources), but it
also allows cataloguing secondary literature (Publications). There is some
work going on to adapt Muscat to be used as institutional or research
repository, where the main bibliographic record type would be Publications.
This first patch allows to define this parameter, and just corrects the
public, Blacklight Solr interface.

[lpugin]

Isn't it possible to convert RISM::MAIN_BIBLIOGRAPHIC_RECORD_TYPE to model or class?

[fjorba]

I tried different approaches before publishing this one. This is the most concise approach I found, because this value can be used as such for sending queries to Solr in app/controllers/catalog_controller.rb. Otherwise, I should have to do a couple of conversions to string in redirect_legacy_values and again in configure_blacklight. So I stepped back and tried with a string, and now it is much shorter.

[xhero]

If understand correctly, you would like to use blacklight (/catalog) to display publications right? I'm not sure this is the best way, as the catalog controller is very tailored to the source model (i.e. indexed marc fields), so probably a better solution would to have a new one and we could configure what /catalog points to.

[fjorba]

Of the three test Muscats I have, one is using Sources (IFMuC) and the other two Publications (DDD and Traces), and this trick works, sort of. Certainly the brief records are too brief for our taste (see #991), and the indices are not adapted to it, but my impression is that it can be worked out.

However, I confess that I feel quite insecure when evaluating whether a new controller is needed or not; I'm still a Rails apprentice, so probably your criterium is more solid than mine.

Indices for publications have to be improved, as now they are specific for musical sources, but I was heading to discuss if Muscat should use the Traject gem (https://github.com/traject/traject) for creating them, as it knows all Marc21 semantics, it has been extensively tested with millions of records of the largest american universities catalogs using Blacklight, and handles all the punctuation and particularities you can think of. That should be another issue, of course, but I think we'd better goal for adopting Traject and just adapt for each model (Sources, in this case, as the exotic one). I don't know if this project should rethink whether a new model is needed or not.

[fjorba]

So, even if you think that are better alternatives, and I'm not discussing this, I still think that this patch is (a) small, (b) solves a specific case (mine, at least), and (c) helps anybody that is interested in evaluating Muscat as research or institutional repository that the things work quite naturally. And, as a result of (a), it is easily reversible.

[xhero]

The biggest problem I see with this approach is that the fields and facets in blacklight are still the source ones, and the variable just switches the filtering of the solr records but leaves the rest (and the set of partials used) the same.

[fjorba]

The biggest problem I see with this approach is that the fields and facets in blacklight are still the source ones, and the variable just switches the filtering of the solr records but leaves the rest (and the set of partials used) the same.

Sure, and that's why I needed to bring Traject (#1110) to light now.

I'm perfectly aware that this is a partial solution. But it does not incompatible with current Muscat instances (it does not hurt anybody), and it helps new adopters, even if we later need a different controller or solution.

Meanwhile, I can work locally polishing some of the rough edges, but my impression is that with Traject it would be possible to accomodate both bibliographic record types in a single controller (and minimising controllers is one of the things that Jonathan Rochkind says, in its Traject presentation, helps maintanability).

[fjorba]

In fact, this is a followup to #958 and #977.

[ahankinson]

Given the MARC fields are configurable for each type of thing, can't you change the MARC fields for your "Source" records to keep them as the primary record type, without changing it to the "Publication" type? It seems like you're trying to bypass the built-in Source records because their current configuration doesn't match what you need, but if you simply change the tag configuration for Source to match, then you don't need to do the switching.

The logic of the if statement is also a bit off. If I set RISM::MAIN_BIBLIOGRAPHIC_RECORD_TYPE = "FlimFlam", then it will default to choosing the Publication model. (i.e., it doesn't matter what the value of this is, as long as it isn't "Source") This is probably incorrect -- you would want to make the behaviour fit the logic exactly, and make Muscat raise some sort of error if it is doing something unintended. Otherwise if you misspell it, like Soruce, then Muscat will happily continue on using the Publication model.

[fjorba]

I've spend the last year considering different options to use Muscat as a institutional or research digital repository, and I've come to the conclusion that using Publications is much easier and less intrusive than adapting Sources. I've pushed several patches to Muscat with this explicit goal and so far the have mostly favorable accepted. Moreover, it probably will have some advantages for Muscat itself, like that Publications will be more flexible, and learn things, like having different templates. I think that the Sources path is not viable.

On the other hand, setting an invalid or misspelled value for RISM::MAIN_BIBLIOGRAPHIC_RECORD_TYPE should not be an argument, because this value is set once per installation, and at this moment less than 5 or 6 persons in the world have this responsability, and of their own good, they won't do such a thing. I haven't put the logic backwards (first Publication, else Source) because I do respect Muscat primary purpose, that is musical sources.

[ahankinson]

The critique wasn't about the possibility of misspelling, specifically -- it was about ensuring the logic is well-executed to ensure the result is always as expected. Specifically, this is 'stringly typed' logic.

I don't know much about Rails, specifically, but would the constantize method be useful here?

https://apidock.com/rails/String/constantize

[fjorba]

Maybe; but maybe it is too much of a hassle for a variable that is set once by one person, the admin, an used in probably 5-6 places by 3 or 4 programmers. I confess that I have a preference for minimising requirements and solutions.

[xhero]

I think there are several issues here which we should discuss separately.
For BL, my problem here is still that changing that parameter will not necessarily make the controller work or be scalable to use it with another model. For example, when different facets are going to be needed, should we do in the code:

if some_selector
  facets_for_selector
elsif some_selector2
  facets_for_selector2
else
  facets_for_default_selector
end

I don't think this is the best way to do it - particularly when it is possible to have a dedicated controller. We are also thinking of EOL-ing Blacklight, I've opened a discussion here: #1113, so we could think of a more clean and scalable solution.

For changing that particular parameter in the catalog_controller, that is something I would do at installation time in this case (and we do it for some other projects to add parameters). But as I said I'm not completely sure the catalog_controller will even properly render Publication models.

I'm also not a huge fan of stringly typed logic too - even if admittedly we use it in Muscat, mostly in legacy code and some other parts, but I'm trying slowly to refactor those.

The last thing is using Publication instead of Sources as the center of the Muscat universe. So Muscat is all built around the Source model - which represents a single musical source, and links to all of its associated data. This is for design and all the application is more or less structured in this way - in particular the database relationships. Now there is linking between the other authority files too, but it is all made keeping Source as the center of the dataset.
It is surely possible to fill in Publications and leave Sources empty but I'm not sure if it is a good solution to morph Publications in a different-named and duplicate Source model, and then have to bolt into muscat a mechanism to switch between the two. The patches submitted were greatly appreciated and actually useful to fix many issues we had, but it was not clear to me that Publication would be an alternative to the Source model. While it is probably doable to be properly implemented it would require quite some thought and engineering.

[ahankinson]

It also should probably be understood that "Source" is a legacy from when Muscat was a manuscript-only database. "Central bibliographic record" is probably how "Source" should now be understood -- everything hangs off of Sources, and sources can be manuscripts or prints. There's nothing music-specific about a source, except in how it's configured by default to meet specific RISM needs.

If you're using "Publications" simply because the name aligns better with the thing that you want to catalogue, then you'll probably end up twisting Muscat in all sorts of ways. As far as I can tell (and @xhero can correct me here!) they're really only meant as bibliographic references attached to things -- they are how you might construct a citation list of publications that talk about a specific source or person. They're not supposed to be a generic model in parallel to Sources.

[xhero]

Yup that is exactly the problem! But naming apart I also see @fjorba's side of the problem, to completely adapt Sources for other needs it requires modifying some hardcoded things we have there, we could open a discussion to brainstorm on this?

[xhero]

Here we go: #1115

BTW I'm not changing the name of the model from Sources 😉

[ahankinson]

Awww... CentralBibliographicItem just trips off the tongue so easily, though. :-D

[fjorba]

I'm impressed about the tsunami I've caused. And it was only a new variable...

Seriously now, yes, I think that what you explain makes sense. The more and more I have been advancing with the Publications model, the more and more I have been duplicating code with Sources. Of course, it was not in my hands even to think that you could unify them in a single one, but is a logical step.

If our experience with Invenio serves, yes, it is possible to have both types of bibliographic records in a single software application. The only real difference between sources (unique items, archive-like) bibliographic model and publication is the existence or not of holdings (852) tag, because 856 can coexist with or without 852. And, maybe, the name of the author vs composer (even professor!) field (but not the tag, that would be 100). Some tags make sense in for one record type and the other in the other one, but they are not incompatible.

So, yes, let's tranfer the discussion to #1115 and do whatever you think with this issue. I still need it for my systems, and for hypotetical newcomers, and you may or may not accept as interim solution.

[ahankinson]

That’s the thing: Sources are also used by us to catalogue prints. So it’s not even used by us for only unique archive items. There is a whole ‘holding’ setup to help deal with this.

[fjorba]

So, as the issue has taken another flight, let's close this one.