Refactoring of works and GND compatibility

[lpugin]

Current status

• The GND work structure can be extended to accommodate the RISM needs; this includes (for example) the addition of the RISM incipits
• A prototype for the data exchange is in place, which means that, in the future, it will be possible to create or update GND records directly from Muscat

Some open questions

• How records will be kept in sync is not solved. The SRU interface used for the data exchange does not provide a ready-to-use solution for resolving conflicts, which will be very problematic
• Internationalization of the data still needs to be finalized; however, this can probably be achieved with additional data within the GND records (e.g., 530?)

Future direction for the RISM work dataset

• The RISM community sees the need to focus on establishing and curating a work dataset implementing a model based on musicological composer work catalogues
• Works within the dataset implementing this model will all have a link to the corresponding GND entries; the dataset, however, will remain by definition a subset of the GND
• The collaborative workflow that will be put in place for establishing and curating this dataset will also focus on establishing mapping with other work authority datasets (e.g., BnF or LC); this means that some of the mapping goals originally foreseen to be achieved through the current work data model in Muscat can be delegated to this new model

Adjustment to the current works in Muscat

• The current work model in Muscat should be redesigned to focus exclusively on links with the GND, which will allow for a more direct and more dynamic communication with the GND
• These GND-works within Muscat will use the GND work IDs, and a GND-work created in Muscat need to have the ID assigned by the GND
• The GND dataset will remain the master dataset; however, it should be possible for GND works to be created but also edited directly from Muscat
• When editing a GND-work in Muscat, the latest version will be pulled beforehand from the GND (potentially with a lock on the GND); this will avoid synchronization issues
• When a GND-work is saved in Muscat, it would trigger a synchronization process with GND; notifications can be used for cases where syncing failed (e.g., very rare cases where the GND records has been modified in between)
• Ideally RISM composer IDs would be stored in the GND record (500 $0)

[lpugin]

Update

Follow-up discussions on the topic have made the following points emerge:

1. A thematic catalog approach is reasonably scalable and backward compatible for the RISM dataset. This approach implies that we admit that not every source in RISM can be linked to a work, which appears to be perfectly acceptable. We could look at this in the same way we deal with anonymous sources (for the record, more than 25% of the manuscripts in RISM are anonymous). The fact that we cannot cover everything does not mean that what we can cover is not useful
2. However, a strict work catalogue approach is too restrictive to accommodate some additional use-cases we have in RISM. We need to allow for less strictly define works and to be able to interact with other datasets. We also need something that is not limited to GND. The direction expressed above has been revised in order to have a more generic solution.

Proposed solution

We introduce a concept of “work-node” in addition to works defined on the model of thematic catalogues. Work-nodes would form an internal dataset in Muscat in order to:

• Link to external authority data (GND, Expressions in FRBR catalogues, DIAMM compositions)
• Represent basic work data that do not exist in the thematic catalogue dataset and cannot be reasonably be published as such
• The work-node dataset would be constantly monitored and clean-up
• For all the above reasons, work-nodes will not be published as an authority dataset

Work-node creation and use

Work-nodes will act as "rich" links to external resources. By "rich" we mean that they will have a structured label composed of various pieces (a composer, a title, a key, etc.) pointing to an external resource (e.g. a GND work). This means that work-nodes should be created only if the resource is published elsewhere as a permanent URI (e.g., GND).

Within Muscat, a work-node will allow to regroup all the sources pointing to an external resource. This means that, for example, in RISM Online, we can make a work-node reference show 2 links:

• One link to the external authority record (e.g., GND)
• One link to see all the sources attached to the work-node

Clicking on the link to see all the sources attached to a work-node will apply it as a filter:

Use of work-nodes outside Muscat

Having work-nodes only within Muscat is not satisfactory. We need their linking capabilities to be exposed publicly, however, still without publishing additional IDs.

When exporting sources referencing a work-node to the OPAC, the ID used would be the outside resource ID (e.g., GND ID)
For data consumers, in MARC syntax, this would look like:

=930  1# $0_(GND)300694032

To make this more useful, additional data would be included

=930  1# $a_Graupner, Christoph $d_1683-1760 $t_Wie bald hast du gelitten $mV (4), strings, bc $0_(GND)300694032

This is very similar to the export we currently have for works with the difference that the external resource ID is being used.