{"word_count": 802, "character_count": 4790}
In terms of data architecture, we should all love surrogates. Still, they seem to me to be one of the most difficult concept to explain to people who don't deal with organizing digital data. Today's post is a first attempt  to explain this (hoping to be as pedagogical as possible!).It seems to be a common point of view amongst traditional humanists that having different entry points (say dates or persons or places) in a database or in a digital edition would mean that there is no underlying order to it. This might even be one major obstacle to conceiving edition projects that should be both online and paper. Digitally, working along a chronological highway (starting from the earliest document and working towards the latest one) is not optimal, whereas it still is the main and almost only recognized way of conceiving a paper edition. There already are big corpora such as Alexander von Humboldt's papers for which it has been approached differently, but it remains a minority.Let me take as an example the corpus of the letters from Chamisso to de La Foye we are editing in our current class. Our basis corpus are the 104 letters contained in the de La Foye papers of the Staatsbibliothek (all of which are letters from Chamisso to de La Foye), to which we have to add 2 letters from de La Foye to Chamisso from the Chamisso papers (also Staatsbibliothek) and one letter from Chamisso to de La Foye from the Freies Deutsches Hochstift. These are the 3 manuscript sources we could identify for this correspondence (maybe there will come some additional material from Krakow, I haven't had time to ask there yet).Apart from those manuscript sources, we have print sources: mainly 3 print editions (Hitzig, Palm, Riegel) that contain partly the same letters as those we have as manuscripts, partly others. I schematically summed up the possibilities this implies in a small drawing à la Laurent:My first entry ("Single Document")  shows that for each document you can either refer to one single source or to several sources (in which case you can collationate, e.g. compare text versions). What I have not drawn on the picture, although it is also a valid case as well, is the one in which you have no physical document left, but you know there has be one at some point. For instance, if Chamisso writes "thank you for your letter of September 4th" and there is neither a manuscript nor a print document dated September 4th of that year, you can still assume there has been such a letter. Maybe you will even find the document at some point; manuscripts are known to pop up when you least expect them to: having looked for them for years and finally given up, they suddenly are there, on the most unexpected shelf. In that case you create a surrogate, an placeholder for this presumable letter of September 4th. This allows, when it comes to point 2 ("Architecture") and you want to have an overview of the totality of the correspondence, to reconstruct the maximum information you have.In this second point of my drawing ("Architecture"), you can see the interest of identifying the nature of the documents we are referring to. For manuscripts, for prints and for "empty" surrogates, the metadata can contain enough information to create a real data architecture. The metadata information (source, persons, organization, repository, places, keywords, document description) are not only arbitrary things you can look for when using the search engine: they actually structure the whole architecture. And as a mean of organizing data, they also are a way of determining the workflow.Working in cooperation with the Staatsbibliothek, we have for instance harmonized our metadata so that we can exchange information with the kalliope autograph database. This allows us as well as the database to collect surrogates that might happen to be "filled" later. Both our digital edition and the digital library of the Staatsbibliothek take advantage of that. The maximum reachable complexity and completeness in data architecture allows everyone, in the end, to spare a lot of time.Another example could be that the keywording can allow to identify particular fields of competence (botany for instance when it comes to Chamisso and de La Foye). By identifying such recurring themes, you can assess much faster how many documents would require the help of a botany expert and plan your work accordingly.To sum up my point: we should love surrogates because they allow complex and complete data architecture; not only are they a key to organizing data, they are also a time saver in that the whole data management allows a greater optimization of the workflow. Convinced?And here's a thought for my father, still at the hospital fighting for his life: no surrogates there, just plain love.&#160;