Body and Orbit
An architecture for knowledge that outlives its language
This event is part of a demonstration of what Lera offers for running knowledge events. Its content is written with care and draws on real sources, but the conference has not taken place, and apart from the convener its participants are fictional.
Since 1998 librarians have had an answer to the problem of translation that our software has still not taken seriously. The Functional Requirements for Bibliographic Records model distinguishes between ‘work’, ‘expression’, ‘manifestation’ and ‘item’. A translation is a new expression of the same work, not another work. Yet almost every content management system we use today makes a translation into a separate page. The two pages begin to drift apart on the very first day, and no structure says that they are still about the same thing.
In this talk I describe an architecture we built to address exactly this problem, and I also talk about its mistakes. Every piece of knowledge has a stable identity. Its body, the text, image or data that make up the work, is versioned and changes only through a new version. A translation is bound to a specific version of the body. If the body changes, the translation does not silently come loose from the original; it shows that it is out of date, and its translator is notified. Every part of the text has a key that is the same in all languages, so we can say exactly which English sentence corresponds to which Persian sentence.
Around the body turns a living orbit: translations, references, critiques, annotations and publication history. The orbit can grow every day without touching the body. This distinction is what makes judgement possible: we know which version a critique was written against, and we know that a published text is not changed behind our backs. In Literary Machines (1981), Ted Nelson spoke of ‘transclusion’: bringing one text into many places without making a new copy. We call the same idea ‘placement’: one piece can be present in a book, a course and a conference and still remain one piece.
Now for the mistakes. Our first versions created a separate piece for each language and, in practice, repeated the problem of the old systems. For simultaneous collaboration we first turned to data structures that allow automatic merging. But in a text where every sentence is a claim, automatic merging sometimes produces a claim that nobody wrote. In the end we chose a simpler rule: at any moment, each part of the text has only one editor. Another lesson was that the language of the interface and the language of the content must be two separate systems; someone working in a Persian interface may be editing an Arabic text, and neither should rearrange the other.
This architecture does not solve linguistic justice. It only provides a possibility without which linguistic justice is impossible in practice: that a Persian text and an English text stand as equals, stay bound to each other, and each has its own author and its own history.
Questions for discussion
- Does the boundary between a stable body and a living orbit make sense for every kind of knowledge, from poetry to data?
- When the original changes, who decides about the outdated translation: the translator, the author or the reader?
- What does the simplicity of the ‘one part, one editor’ rule cost collaboration?
References
IFLA Study Group on the Functional Requirements for Bibliographic Records. 1998. Functional Requirements for Bibliographic Records: Final Report. Munich: K. G. Saur.
Nelson, Theodor Holm. 1981. Literary Machines. Swarthmore, PA: Mindful Press.
Kleppmann, Martin, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. 2019. “Local-First Software: You Own Your Data, in Spite of the Cloud.” In Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward! 2019), 154–178.
Shapiro, Marc, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. 2011. “Conflict-Free Replicated Data Types.” In Stabilization, Safety, and Security of Distributed Systems (SSS 2011), Lecture Notes in Computer Science 6976, 386–400. Berlin: Springer.