How easily can Linked Art data be retrieved for inclusion in Quire?
Sasha Tan considers modelling, versioning, and local practice, and how software tools can help
Particularly given the collaborative and ongoing nature of Linked Art’s development as a metadata standard, developing a singular cross-institutional solution connecting Linked Art data to Quire is not without its challenges. On a technical level, such a solution essentially necessitates that equivalent data-fields across different records are stored in predictable ways. At the same time however, different institutions may employ different versions of the Linked Art specification; they may have different preferences reflecting equally valid interpretations of the same specification; and their implementations each occur in the context of their respective institutional circumstances and constraints. Throughout my placement with the EES2 team, I spoke with individuals working at various stages of the cultural heritage data life-cycle in order to get to grips with some of these issues. Their insights would subsequently inform the development of latool.js, a software tool which streamlines the retrieval of Linked Art data for various purposes including data validation, research, and publication via Quire.
Firstly, as I learnt from speaking with Dr Robert Sanderson, the chair of the Linked Art editorial board, different implementations of Linked Art may not necessarily structure equivalent data in consistent ways. For instance, older versions of the Linked Art specification—and hence, institutions who have implemented Linked Art based on these versions—use the CIDOC-CRM property ‘value’ to store information which would instead be stored in a ‘content’ property in more recent versions. This is because the CIDOC-CRM property ‘P190: has_symbolic_content’ was only introduced after the earliest versions of the Linked Art specification had been released. Institutions who have modelled their data based on earlier versions of the specification however may not necessarily have the resources to dedicate towards updating their resources each time a new version is released. Hence such issues persist in different forms across various institutions. These issues thus necessitate that previous versions of the Linked Art specification also be taken into account when developing software for the purposes of enabling cross-institutional integration of Linked Art with Quire.
Moreover, even institutions referencing the same version of the Linked Art specification may make different but equally valid modelling choices which entail that equivalent data-fields are not structured in precisely the same ways across records. For instance, between Getty Museum and LUX records, creator information is stored in the paths produced_by.carried_out_by and produced_by.part.carried_out_by respectively, and similar variations exist across other data-fields and other institutions. Hence, data retrieval software cannot simply traverse a fixed path when interfacing with these records, as various institutions commonly introduce structural variations in their data. Similarly, institutions may also elect to use different controlled vocabulary terms for equivalent data; for instance, while donor credits for an artwork may be identified by one institution using the Getty AAT entry for ‘credit line,’ another institution may instead elect to use the entry for ‘acknowledgments’ instead. Such variations must likewise be accounted for.
During my conversations with various parties at the Ashmolean Museum, I was acquainted first-hand with how such variations may arise even within the same institution, or indeed the same department within an institution. During the initial phase of my placement, I collaborated with Dr Andrew Shapland—the curator of the Ashmolean’s Labyrinth: Knossos, Myth & Reality exhibition—to create Linked Art data for several objects from the exhibition. During this process, I also received training in MuseumPlus, the content management system used by the Ashmolean, and had the opportunity to speak with the Ashmolean’s digital collections team.
During these meetings, I noted the point that between records, the metadata available for what appeared to be highly similar objects were not entirely consistent. One work of pottery for instance might bear the object type ‘kylix type B’ whilst another might simply be called ‘pot’; likewise, while one might be said to be made of ‘ceramic,’ the other would instead be assigned ‘clay.’ As I came to learn from both Dr Shapland and the digital collections team, the museum’s records represent the accumulated work of countless individual curators inputting content into a repository which has itself migrated across multiple content management systems over the course of many years. Moreover, if an object had at some point been moved between two departments with differing record-keeping standards, this would potentially translate to a difference in how its features were recorded. In such ways, even records within the same institution—let alone records between institutions—cannot always be expected to be consistent with one another, despite the best efforts of institutions to align data standards. This being the case, variations in cultural heritage data simply come with the territory, and software interfacing with such data ought to adopt an inclusive and pragmatic approach cognisant of the variations in data which inevitably arise within and between institutions.
Bearing all of these considerations in mind, latool.js has been developed to accommodate a broad range of institutional and versioning-based variations, of which the above discussion has discussed only a handful. Intended to be both robust and flexible in its data retrieval approach, the tool serves not only those interested in rendering Linked Art data fit for publication via Quire, but also those wishing to use Linked Art data for research or data validation purposes.
