Data model
The data model in Muscat is balanced between the distinct requirements of music source inventory on the one side and compatibility with non-music specific library systems on the other. From the beginning of the development of Muscat by the RISM-UK in 2002 the choice was made to work with the international Marc (or MarcXML) library format. Using MarcXML, which was also a requirement from the Swiss funding agency when supporting Muscat, is advantageous because it facilitates data exchange with Muscat, and this is valid for both directions. That is, for exporting data from Muscat into a library system, and for importing data from a library system into Muscat. Of course, these operations frequently require fine tuning and adjustments, but having the same underlying format greatly facilitates the process.
Resource classes
The data model in Muscat is based on different resource classes. Whenever possible, a class is mapped to a MarcXML record. The core class in Muscat is the source class, which embeds a MarcXML bibliographic record. The Marc data is stored directly in the system and indexed with Solr.
For prints, Muscat also makes a distinction at the model level between bibliographic records, which describe the editions, and holdings, which describe each preserved copy of an edition. A holding is also mapped to a MarcXML record. As a result, two types of hierarchies are bound to the source class. That is, sources can be hierarchically linked to represent collections and collection items, or sources can be hierarchically linked to the holdings of a print.
Having separate holdings in Muscat not only allows for fine-tuned user access management (see the page on user management) but also for information about each copy to be properly presented to the user.
The source is put in relation with the authority data, or foreign classes, also stored directly in the system. The foreign classes describe personal names, institutions, subject headings, titles / text incipits, liturgical festivals, secondary literature, places, and works.
When appropriate, the foreign classes are also mapped to corresponding authority MarcXML records. This is the case for personal names, institutions, secondary literature, and works. The corresponding Marc data is also embedded and indexed with Solr. Whenever possible, the authorities are linked to external data resources. See the page on authorities for more information.
Composite volumes
Muscat 5.0 allows composite volumes that include printed materials to be described through a parent record with links to the individual items. Parent records can now be created for (1) separately issued printed items bound together and (2) manuscripts bound together with printed items. This can be useful for projects willing to provide an in-depth description of how printed music editions are bound in their particular library. See, for example, record 1001056386, in which in which two printed items are bound together.
Application architecture
The application architecture of Muscat follows the common Model-View-Controller (MVC) design pattern implemented directly in the Ruby on Rails application framework. The design pattern offers a good separation of data model described above and the application. The application is organized as follow:
- The MarcXML data are loaded as an instantiated dataset where all the links between the objects are resolved and validated.
- The behavior of the Muscat application is implemented in the controllers that handle the application actions.
- The views, consisting of view partials, specify how the data is presented to the user through the user interface.
- The configurations for the layouts in the views (e.g., how the fields are grouped and ordered in the display for a manuscript description), the labels, or the translations, are stored separately.
- The cataloging interface and the Blacklight interface use the same view partials and the same configurations.
- The data indexed Solr is made available to the different search interfaces that use the same index instance.
Muscat offers a clear separation of the various components of the application, which makes it very easy to extend and to maintain. In Muscat 3.0, the cataloguing interface was heavily re-factored without having to do major changes to the views and to the controllers because their are independent components.
Furthermore, elements are available across the application and can be used by multiple components when these provide identical functionalities or have identical display needs. For example, the discovery interface in Muscat 3.0 could be very easily be replaced with Blacklight by using the same view partials and the same configurations as the ones of the cataloguing interface. This also means that a modification in the views or in the configurations, for a label or for the order of the fields for example, will automatically reflect in both interfaces.