The first two articles in this series described what a catalogue raisonné contains: numbered, documented works, prints, editions and provenance. This one asks a different question: can the catalogue leave the software that holds it?
Back to our fictional example. Jeanne Valory’s estate has spent three years documenting her work. A regional museum is considering acquiring some twenty vintage prints and asks for the records “in a format our collections management system can import”. A researcher would like the whole catalogue in a spreadsheet. And the family wonders what will become of all this work if, fifteen years from now, the software they use no longer exists.
Three requests, one requirement: the catalogue must be able to travel without losing what makes it valuable.
Open format, proprietary format
A proprietary format is defined by a vendor, for its own software. It may be excellent, but it reads well only in that software, and its full description is not necessarily public. As long as the vendor exists and maintains the product, all is well. The day it does not, the data is still there, but nobody really knows how to read it.
An open format is described by a public specification that anyone can read and implement. Data written in it does not depend on any particular program: another tool, written later by someone else, will be able to read it.
For a catalogue raisonné, which must outlast any piece of software, the rule is simple: the catalogue must be able to leave, at any time, in an open format, complete, with no strings attached. Tools will change; the cataloguing work should not have to be redone.
Three formats, three recipients
No single format suits everyone. Three open formats cover most needs, each for a different recipient.
CSV: the common floor
CSV (comma-separated values, described by RFC 4180) is a text file that every spreadsheet, every database and most programming languages can read. It is the humblest format and the most durable: a CSV file opens even in a plain text editor.
Its limit is that it is flat: rows and columns. A catalogue raisonné is not. A work has several prints, several exhibitions, several provenance links. A useful CSV export is therefore split into several tables linked by the work number: one for works, one for prints, one for exhibitions, one for publications, one for provenance. This is where the stability of the number, discussed in the first article, really matters: it is the key that ties the pieces together.
Two practical details matter more than one might think. The separator: a spreadsheet set to a French locale often expects a semicolon, because the comma is its decimal separator. And the encoding: a UTF-8 CSV must be recognised as such, or the accents in “Épreuve d’artiste” arrive garbled.
LIDO: the museum record
LIDO (Lightweight Information Describing Objects) is an XML schema designed for publishing and harvesting descriptions of collection objects. It is maintained by the CIDOC committee of ICOM, the International Council of Museums. It is an exchange format: it does not claim to describe everything a catalogue knows, but what a collections portal or another museum needs to understand an object.
A LIDO record describes an object: its identification, its titles, its description, and the events that concern it (its creation, with its author; its acquisitions; its exhibitions), along with the digital resources that represent it. For photography, a question arises at once: is the object the work, or the print? A museum does not acquire an image; it acquires a sheet of paper. A coherent export therefore produces one record per work and one per print, linked together.
CIDOC CRM: linked data
The CIDOC CRM (Conceptual Reference Model) is a conceptual model of cultural heritage information, standardised as ISO 21127 and also maintained by ICOM’s CIDOC committee. It is not a file format but an ontology: a way of describing objects, people, places, dates and above all the events that connect them. It is usually written in RDF, for instance in the Turtle syntax standardised by the W3C.
Its event-centred approach suits photography well. A handful of its classes are enough to say what matters:
- E22 Human-Made Object: the work, and each print;
- E65 Creation: the creation of the work, that is, the exposure;
- E12 Production: the making of each print, at its date, by its printer;
- E8 Acquisition: each transfer of ownership in the provenance;
- E39 Actor: photographers, printers, provenance parties;
- E52 Time-Span and E53 Place: when and where events took place.
The distinction between the creation of the work and the production of the print is exactly the one the first article drew between the work and the object. The CIDOC CRM has far more classes than these. For an exchange, a restricted profile filled in correctly beats a complete one filled in approximately: wrong linked data spreads as fast as right linked data.
From names to identifiers
A name is not enough to designate a person. Two photographers may share one; the same printer may be spelt three ways in three documents. In an exchange between institutions, that vagueness is costly: the museum receiving the record cannot tell whether the “J. Valory” in the provenance is the artist, her nephew, or a namesake.
That is what authority identifiers are for: numbers assigned by public reference files that designate a person or an organisation unambiguously. The most common in the heritage field are VIAF (the Virtual International Authority File, which aggregates those of national libraries), ULAN (the Getty’s Union List of Artist Names), Wikidata, ISNI and, for researchers, ORCID. A record that points to an identifier rather than to a bare name lets the receiving institution connect it to what it already knows.
This assumes, upstream, a well-kept directory of agents: one entry per person or organisation, duplicates found and merged with care (two namesakes can be two different people), and identifiers filled in where they exist.
What should not travel
Moving a catalogue does not mean sending everything. Part of what it contains has no business in a file handed to a third party:
- internal notes, written for oneself or the team;
- prices, holders and sensitive locations;
- confidential provenance, especially where one party is a living person;
- confidential works, which no one has yet decided to make public.
A good export leaves them out by default, and includes them only by explicit decision, for a specific recipient (an insurer, an heir), keeping a record of that decision. The reverse, exporting everything and relying on everyone’s vigilance to remove what is sensitive, always ends in a leak.
Metadata that travels with the image
There is another, quieter journey: that of the image itself. A file sent to a publisher, a gallery or a museum leaves without the catalogue. What it can carry is its metadata: title, author, rights, description, keywords.
Three families of metadata live side by side in image files:
- EXIF, published by CIPA and JEITA (CIPA DC-008): the technical data the camera records (capture date, camera, settings);
- IPTC, the press’s historical format for description and rights;
- XMP (Extensible Metadata Platform), standardised as ISO 16684-1: an extensible format that imaging software uses for description, keywords and rights.
Writing that metadata raises a delicate question: should the original file be modified? There are two ways.
The XMP sidecar. A small .xmp file placed next to the image, with the same name, that carries the metadata. The original file is not touched, not one byte. Many imaging programs can read these companion files. It is the safest route, and the only possible one for most RAW files. A well-written sidecar merges: it replaces only the properties it manages, and keeps those another program put there (development settings, for example).
Writing into the file, without re-encoding the pixels. For some formats (JPEG, TIFF, PNG, HEIC), metadata can be rewritten while copying the image data as is: no recompression, no loss, the image is identical down to the pixel. But the file itself is no longer the same: its bytes have changed, so its checksum (SHA-256, for example) changes too. If that original is kept or referenced somewhere by its checksum, it will show up as modified. It is a legitimate choice, but it must be explicit, confirmed, and the old checksum kept on record.
Either way, checking first avoids surprises: some IPTC fields have a limited length, and a title that is too long will be silently truncated by other software.
What we are building
Obscura Catalog, the macOS app we are preparing, is designed to export the catalogue as CSV, LIDO and CIDOC CRM, and to read and enrich the EXIF and XMP metadata of images. The pages LIDO, CIDOC-CRM, CSV exports and EXIF and XMP metadata present them, and the glossary defines each of these standards.
In short
- A catalogue raisonné must be able to leave at any time, complete, in an open format: it must outlive the software that holds it.
- CSV is the common floor; a useful export is split into tables linked by the work number.
- LIDO describes objects for museums and portals; in photography, work and print are two records.
- CIDOC CRM links objects, people, places and events; the creation of the work and the production of the print are two separate events.
- Authority identifiers (VIAF, ULAN, Wikidata, ISNI, ORCID) beat names.
- Confidential data is exported only by explicit decision.
- For the image, the XMP sidecar leaves the original untouched; writing into the file leaves the pixels untouched, but changes the checksum.
Previous article: Prints, editions, artist’s proofs: documenting what really exists
Next article in the series: A certificate of authenticity for a photograph: what it attests, and what it does not