Replies: 10 comments 5 replies
-
|
I would start with |
Beta Was this translation helpful? Give feedback.
-
|
You can customize record types here: For example, you can define a new type of print record by defining a new MARC template for that bibliographic type. This allows you to enter different types of Sources (in our configuration we have nine different source types, for example -- some manuscript, some print, some as contents of a manuscript or print.) So you might create a new record type "001_book" or "002_journal_issue" with a default template, and then continue to customize from there. |
Beta Was this translation helpful? Give feedback.
-
|
Certainly, but at the same time, this list is duplicated (or triplicated) in several places:
I found that when trying to create record_types for Publications. And talking about "hardcoded configuration", as this discussion is about, my opinion is that record_types is one of them. |
Beta Was this translation helpful? Give feedback.
-
|
There is actually a fourth place too ;) |
Beta Was this translation helpful? Give feedback.
-
Oh, yes; that one, right? |
Beta Was this translation helpful? Give feedback.
-
|
I understand it well if the conclusion is that your plans are to abandon the current Publications record type and to fusion it with Sources, and have a single one? In that case, would it be the Record type what would differentiate between a musical source and a secondary literature? Even more, between all types of musical sources and all types of secondary literature (currently not yet developed)? In that case, would the "main author" field be named (and indexed as) "composer" or author" depend on that record type? |
Beta Was this translation helpful? Give feedback.
-
|
I’m not sure the idea is getting across—the plan is not to “abandon” anything. In Muscat, the primary record type is “Sources”. What fields go in sources is completely configurable. “Publications” was never intended to be a primary record type — it was always meant as a way of holding bibliographic references (e.g. a scholarly bibliography) for a source, or for other types of records. We are not abandoning Publications, or merging them. They are still used for bibliographic references (“Secondary literature”) In other words: if you are using Muscat to catalogue anything, Sources should be the table where most of your data lives. If you need to reconfigure sources to relabel the fields to non-music specific things, then you should do that, instead of trying to make “Publications” into a parallel primary record type. That is definitely not supported. We can help if you need to untie some of the things in Sources that might be hard coded to music, like “composer” labels. Muscat should, with the right configuration, be able to output MARC that is generic. As in all things Muscat, @xhero has the final word for this, though. |
Beta Was this translation helpful? Give feedback.
-
|
But then, what is the fate of #1043? Because if Publications grow with more templates, as there was an agreement that it would be a good think (#1013), it will grow as much as Sources (as it was heading to), it needs Persons and Institutions and any other authority records. The complexity or diversity of secondary literature needs different templates. So, what do you mean with 'That is definitely not supported'? If in secondary literature we have templates for journal articles, academic conferences, doctoral theses, books, reports, etc. that fit with a typical institutional or research repository, how I can justify to replicate those templates with sources if I have them as secondary literature? Moreover if the opac is externalised to, say, an external Blacklight system? It seems an unnecessary duplication of efforts. |
Beta Was this translation helpful? Give feedback.
-
|
I guess all I'm trying to do is to warn you that you're using Muscat in a way that it was not intended to be used, so we can't really support it if you get so far and need more extensive changes. Certainly you can try to use the 'Publications' model, and for the most part it might work, but we also want to be clear that we can't really support changing the core Muscat functions to make this work either, since we can't support re-designing these behaviours. I think there was some misunderstanding, on our part about your intentions to create a parallel 'main' record type, which only became clear when you submitted #1106 -- we're sorry for this miscommunication. Also, since the changes you made are to the Blacklight configuration, then you are free to do what you like if you hook up your own independent Blacklight installation (as in our discussion in #1113). This is another advantage of decoupling the cataloguing interface from the OPAC. Out of curiosity, is there a reason why you can't use 'Source' as your primary record type, with the appropriate template and configuration changes? Why do you need to use the "Publication" record type (other than the fact that the name and the current configuration map more closely to your material)? (This is, of course, presuming we can work out the places where 'Source' is hardcoded with music-specific assumptions, and fix those for you, which goes back to @xhero 's initial discussion message.) |
Beta Was this translation helpful? Give feedback.
-
|
To explain a bit further: we have not plans to abandon anything, but we are trying to think of a layout for the data that can fit well in Muscat. Muscat is very "source" based - in the sense that this is the central element that it is catalogued. We choose the "source" name as it is relatively neutral (it was called "manuscript" originally), but you can think of it more as a generic "data" model. The rest of Muscat is basically built to add authority data to Sources, and you can see the different level of complexity from Sources in respect to the other authority files. This complexity comes mostly as database relationships (and code to make them work), indexes and scripts for maintenance. So while we can "upgrade" any other authority file to be "central" as sources we would basically end up with a copy of it - at least, a similar enough copy. So as @ahankinson mentioned we could work towards identifying the parts of Source that are hardcoded with music specific stuff and work out how to make it configurable for other needs. In this way we would still have a central data model without having to create copies of it. |
Beta Was this translation helpful? Give feedback.
-
|
I'm obviously willing to make things easy, and to collaborate, because I'm convinced that we all can benefit of a shared work. For example, I had been writing this documentation for my own understanding and to help other newcomers to Muscat. It is not finished and the last paragraphs should go to another document specific for editors, and not all links work well (they do work well in our local Redmine instance, but for some reason Github Textile parser does not recognise the same links as clickable urls), and it exemplifies well my current paradox: So, now there are two bibliographic record types and several (currently only for Sources) document types. What should we do now with Publications, specifically about #1043? Maybe we could use the same document types (editor template) for both record types (Sources and Publications)? This way we would not duplicate efforts (following the DRY principle) and we could use Sources as primary bibliographic record types and you, as RISM, could have the same templates for Publications? I haven't thought enough about it to evaluate whether it is feasible, but it comes up as a possible solution. The only big difference would be the https://github.com/rism-digital/muscat/blob/master/config/marc/default/source/template_configuration.yml file that lists the valid document types of each instance (with some obvious small differents here and there about this or that tag or subfield). |
Beta Was this translation helpful? Give feedback.
-
|
This situation raises and old idea that I had months ago. To use Muscat as a research and institutional repository, I thought two choices: either using Publications model, or using the EDITOR_PROFILE, and maybe the MARC configuration variables as set in: https://github.com/rism-digital/muscat/blob/develop/config/sample_application.rb#L52 In fact, that was my purpose with my #936 and related patches. This way, creating a new EDITOR_PROFILE, called, for example, I'll try to update my work where I left it. |
Beta Was this translation helpful? Give feedback.
-
|
What about just calling it bibrecord? |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure about renaming it, it would be huge endeavour of reworking (Muscat is basically a source cataloguing application) and then we would end up with the same identical functionality. I think probably we should use the configurable labels to show users a different name (as we do for Publications that is called Secondary Literature) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it seems perfectly reasonable, thanks. |
Beta Was this translation helpful? Give feedback.
-
Or "Central bibliographic record" as @ahankinson named them ;)
The Source module has some hardcoded stuff in it, plus some "hardcoded configuration". It could be worth identifying what is there so that the model can be more easily adapted.
Beta Was this translation helpful? Give feedback.
All reactions