Dublin Core and the Cataloguing of University Heritage: A Reality Based on Sustainability

The University of Barcelona (UB) has a rich and diverse heritage that has been built up since its foundation in 1450. Currently, it consists of various collections that fall into the following groups: a) Collection of scientific tools and instruments of the University of Barcelona; b) Heterogeneous faculty collections; c) Art collections; d) Biodiversity and geodiversity collections; e) Special collections (human heritage, intangible heritage, criminology etc.).

These collections, many of which can already be consulted at the Virtual Museum of the UB (hereinafter, MVUB), have extremely specific characteristics that can be applied to most of the university heritage. They are mostly gathered in the various articles previously written about the constitution of the MVUB [1], [2], [3], [4] but for a good understanding of the issue, they are summarized here:

• Great heterogeneity. We can find examples of almost all types of heritage established by UNESCO [5], and we specifically add human heritage, understood as those people who have left their mark on the institution. It is an environment where institutions coexist under the common umbrella of the term GLAM [6], [7].
• Distribution in various collections, not always connected to each other and rarely constituted as a museum (understood as an establishment). In the case of the UB, there is no legally established museum [8], but the competent vice-rectorate promotes common policies such as the recent regulation [9], which has allowed the formalization of various processes and actions related to heritage management. There is also a heritage advisory committee, and periodic meetings are held with all responsible parties.
• Description and management of collections conducted by non-specialized personnel without full dedication to the collection, except for specific heritage collections of libraries and archives. In the case of the UB, each collection usually has a responsible person who is often a professor specialized in the research area of the collection, performing these curatorial tasks part-time in combination with other tasks related to teaching, management, and research.
• Immense variety of metadata schemes. Standard metadata schemes are usually only found in libraries and archives and also in institutions with a specific museum structure. In the case of the UB, the work done by the library (CRAI) and the archive is combined at the MVUB with the work done by the responsible parties of the different collections, under the direction of a heritage technician and the advice of a metadata specialist from the Faculty of Information and Audiovisual Media of the UB.
• Immense variety of software and cataloguing tools, including analogic ones.

This diverse situation made it necessary at the time to select a metadata scheme that met some essential characteristics:

• Simplicity. The learning curve had to be low, as cataloguers are not metadata experts and do not work full-time on it. In fact, the UB had already had a failed attempt to create a virtual museum with the Museum Plus tool, which was not well received by those responsible due to the complexity of the processes.
• Interoperability. It was necessary to integrate our heritage with other aggregator initiatives such as Catalomica, Hispana, or Europeana.
• Expandability. It was necessary to add fields that would allow minimal heritage management. However, it was not sustainable to fully apply the CIDOC CRM conceptual model. The previous MVUB had tried it and had not succeeded.
• Adaptation to LOD (Linked Open Data), both in terms of the structure of the scheme and the values of controlled languages.

The first step taken was to narrow down the possible existing schemas in the GLAM world. MARC21 and EAD/ISAD(G) were discarded mainly for two reasons:

• Limited suitability to the context: although we do have documents, most of our collections consist of objects.
• Complexity of learning and implementation in a work environment with part-time staff.

In the case of CDWA, the framework was appropriate for the context, but it was very extensive and complex. Moreover, it only had a small "encoded" part, known as CDWA Lite, an old adaptation of CDWA that had already been incorporated into LIDO and is no longer maintained.

What was CDWA Lite? CDWA Lite was an XML schema to describe core records for works of art and material culture based on CDWA and CCO. CDWA Lite records were intended for contribution to union catalogs and other repositories using the Open Archives Initiative (OAI) harvesting protocol. In 2010, the CDWA Lite schema was enlarged and integrated into the Lightweight Information Describing Objects (LIDO) schema, available on the CIDOC site [11].

Having ruled out complex schemes like MARC 21, EAD, or the CDWA framework, only two "competitors" remained as the possible structural standard to be used for the creation of the new MVUB: LIDO and DCMI Metadata Terms.

LIDO was characterized by having "inherited" from the "big" schemes in the cultural heritage environment some very valuable elements for description: the treatment of dates, materials or techniques, or events associated with the object is better than what Dublin Core can do, as it aligns with the CIDOC CRM data model, specific to cultural heritage.

However, LIDO is not designed for cataloguing, but for exchange. It maintains an XML structure (based on complex types, elements, and attributes) that results in a verbose output with a steep learning curve. This led us to discard it. We needed a scheme that could quickly become friend of our cataloguers.

In this sense, Dublin Core, also adapted to LOD and the semantic web, was much more useful to us. It certainly had shortcomings in terms of management and description of heritage elements, as well as properties that generated interpretation doubts, but we considered that, with an application profile and a good data dictionary, these could be resolved. Moreover, Dublin Core was the most widely used exchange scheme thanks to its widespread use within the OAI PMH protocol, and therefore, we could find numerous usage experiences in similar environments as well as a better alignment with aggregators like Catalomica, Hispana, or Europeana.

The data model that was globally adopted was a simplified version of the one proposed for cultural heritage by CDWA [10] and Cataloging Cultural Objects (CCO) [11], tools that also act as content standards in the MVUB.

This model avoided breaking the one-to-one principle that normally occurs between the original and its digital copy.

Of the 7 original entities, our model retained Work Records and Image Records. Source Records entity was not included because it was not sustainable for us to catalogue completely the bibliography used. A citation is sufficient, and for this, we only need a repeatable field (dcterms:isReferencedBy) to place these values.

Therefore, our model, as shown in figure 2, would consist of:

• MVUB_Item (Work Records). This entity included the description of the work and its physical manifestation, as well as data related to the management of the piece. This "work" could be, for sustainability purposes, an individual piece or a set of pieces. Individual pieces that could be related would do so through a content relationship from the set to the piece (dcterms:hasPart). Individual descriptions of pieces would only be made in exceptional cases.
• Images (Image Records). Here we should think of multimedia materials (not individual images). This would include:
  • The digitized manifestations of the objects and their metadata.
  • The multimedia manifestations of intangible heritage.
• A set of auxiliary entities. These auxiliary entities would be the entry points for the controlled languages used by the MVUB. These controlled languages, all adapted to LOD, would initially only take the form of a list, but semantic enrichment could be considered in the future. They would be as follows:
  • ACTORS: a list of authorities based mainly on the URIs of VIAF and Wikidata (and derived labels). To be used in dcterms:creator, dcterms:contributor, dcterms:Publisher, and partially in dcterms:subject.
  • PLACES: a list of URIs and labels based mainly on the THUB, the thesaurus of the University of Barcelona. The URIs and labels of the THUB would feed dcterms:subject, if necessary, for example, to specify the places mentioned in a document.
  • SUBJECTS: in this case, the lists used would come from the THUB (dcterms:subject and dcterms:temporal).
  • MATERIALS & TECHNIQUES: in this case, URIs and labels from the AAT would be used, although they would be treated as two separate entities. They would feed metadadesub:techniques and metadadesub:materials since dcterms:format is not a controlled field but a descriptive one.
  • CLASSIFICATION: Nomenclature 4.0 would be used for classification, which, since dcterms does not have this concept, would be added to the application profile through a specific property called metadadesub:classification.
  • TYPE: URIs and labels from the Objects facet of the AAT (dcterms:type).

The present selection of properties refers only to the main entity: MVUB_Item (Work Records). Similarly, we will only discuss those fields that we have added or adapted to the needs of our environment. This means that properties such as dcterms:title, dcterms:creator, or dcterms:identifier will not be discussed here since they do not establish substantial modifications. However, Appendix 1 allows us to see the entire set of fields used.

When we opted for Dublin Core, we knew we needed some of the elements we had already seen during our analysis of LIDO and CIDOC CRM. Therefore, we added the following elements to our application profile [12]. If an equivalent Dublin Core term was identified, it was applied, always ensuring that a future simplification to Simple Dublin Core would not break the dumb-down principle. If no equivalent field was found, it was added to the group of custom fields, which we called metadadesub.

Below some of our main decisions.

• Dates. In date management, the concept of Display vs. Numeric Dates from cultural heritage schemes was very interesting to maintain. This means we had to be able to represent both a textual approximation and a normalized date. We used dcterms:date as the equivalent of display date, dcterms:created to manage the start date, and dcterms:issued to manage the end date.

• Materials and techniques. In museum pieces, this was an aspect that was meant to be documented. We used dcterms:format for the display, metadadesub:materials for controlled vocabularies related to materials, and metadadesub:techniques for controlled vocabularies related to techniques.
• Fields related to content analysis/contextualization. We used dcterms:type for the type of piece, dcterms:subject to broadly capture the disciplines of the works, dcterms:description to describe the work, metadadesub:classificacio for classification, and dcterms:temporal for the associated time period.
• Local and management fields. To select the necessary fields, we studied the needs expressed by the project management and analyzed the CIDOC CRM conceptual model.

Finally, regarding the values to be included in the fields, two levels of work were defined:

• Data Content Standards affecting the entire MVUB. The reference standard is CDWA. In our data dictionary, it was established how and when to address aspects that could generate more uncertainties.

• Data Value standards, affecting specific properties were selected. All of them belonged to the semantic web and linked data environment. This was made with the aim of integrating MVUB into this environment.

Currently, the MVUB is fully operational and has grown from 300 records (in 2020, the year it was migrated to the new system) to nearly 3,000 in the four years it has been in operation. Data is ingested in two ways:

1. Direct cataloguing in MVUB, which operates using Omeka S software. A significant portion of the collections are catalogued directly in MVUB. These typically include collections that previously lacked any cataloguing system, relied on manual methods, or are newly created collections beginning to manage their sets of assets, including cataloguing tasks.
2. Ingestion into MVUB from an Excel file mapped to the MVUB data dictionary and refined using Open Refine to eliminate inconsistencies. In this situation, we find university areas that usually work with more developed cataloguing structures (e.g., MARC21, EAD), typically the library or the archive.

There is an option to carry out preliminary cataloguing in a very simple way using a Word document that relates all the metadata schema fields, and once the information is completed, it is transferred to Omeka S. This method is highly suited for collection managers who lack training in documentation systems and need more continuous supervision.

The system's acceptance by collection managers has been very positive. For those who directly use Omeka S, training has been provided, and a communication channel for resolving doubts has been maintained. For centres that map their fields, meetings have been held to agree on equivalences between their fields and ours, and if deemed necessary, the mapping results have been shown to them before proceeding with ingestion.

Therefore, we consider our project to be valid in environments where there are no full-time staff structures, where there are significant budgetary constraints, and where the variety of items to be ingested is very high. It allows, with a low learning curve, the creation of an interoperable product adapted to linked data (and therefore capable of semantic enrichment), while covering the essential elements of management.

Currently, work is being done on adapting metadata schemas related to biodiversity and UB's human heritage, although in these cases, Dublin Core will not be used as it does not meet our needs. For biodiversity, a simplification of Darwin Core is being considered, and the analysis of human heritage has not yet begun, though FOAF or Wikidata are options being studied. In the future, it will be necessary to modify our application profile to include intangible heritage. Most likely, Dublin Core will once again be chosen.

Finally, one of the medium-term objectives is the improvement of content through semantic enrichment, which is likely to be very important for human heritage. Progress must also be made in data sharing with other institutions by installing specific modules in Omeka, as well as improving the data export capabilities of MVUB.