Linked Traces and AIO #2
Description
Hello all,
I'm Chris de Lisle, one of the editors of Attic Inscriptions Online. The idea of AIO and Pelagios interacting has been in the air for a long time, but has been held up because AIO doesn't have the capacity to output data as a dump file or an API. We've recently received some money which will allow us to do just that (provided that we do it by the beginning of June...). I've been in touch with Elton Barker and Simon Ranier about this and they've said that it would be good if AIO outputted data about its inscriptions in the Linked Traces format. Unfortunately, the Linked Traces format is still a work in progress, as you will know.
Therefore, I'm posting here the data that AIO plans to output, in the hope that we can come up with how/whether that data should map onto Linked Traces, so that I can ask my developer to action it (he has, rather sensibly, said, that he can't really do very much until he knows what the output should look like).
I think it is useful to work at the level of a given inscription, with the example of I Eleus 175 (https://www.atticinscriptions.com/inscription/IEleus/175).
Identifiers
- AIO id number: Every inscription has a unique id number (this one is “AIO_1325”), but it is mostly an under-the-hood thing.
- Inscription title: A plain text description “Sacrificial calendar from Eleusis”
- Translation sources / References: The various editions of the inscription (in this case, as you will see there are many of them), one of which is identified as “is the translated text” and therefore appears in bold at the top of the list on right. These are used to construct the URLs of the entries, so since this inscription is I Eleus. 175, the url becomes …/IEleus/175 . All of the references produce valid URLs – so since this inscription is also IG II2 1363, the link https://www.atticinscriptions.com/inscription/IGII2/1363 will lead to the same entry. A separate module translates (e.g) “IEleus” into a full reference (K. Clinton ed., Eleusis. The Inscriptions on Stone. IA Text. IB Plates. II Commentary, 2005 (I) and 2008 (II), Greek Archaeological Society - Athens) and provides a link to a Greek text on PHI, AIO itself, etc.
So, the translation source provides the “id” for Linked Traces. In an ideal world Linked Traces would be able to cope with the fact that these inscriptions have multiple alternative ids. We’d probably want “inscription title” to become the Linked Traces “title”. I think we probably do want to export the links to Greek texts, both for their utility value and because other projects are likely to be able to hook on to the PHI URLs in particular. Then we probably also want to output the full reference in some form or other.
Inscription text. AIO has an irregular epidoc realisation of English text and (in many cases) epidoc of the Greek too. At some point, AIO really should export this data, but the way it is stored makes that difficult and it’s not relevant to Linked Traces, so let’s not.
- Information about the authors of AIO’s translation and notes also exists and there is little point in exporting this when the text and notes are not being exported.
Dates: We store a “display date” in plain text (in this case “ca. 330 BC”) and “start date” and “end date” as numerical values (here “-340” and “-320”) which are used for searching. This seems to port fairly straightforwardly onto Linked Traces’ "lpo:when": {"timespans":[{"start": ####/####"}]} .
- We also have data on when the inscription entry on AIO was created and last updated. I don’t see the utility of exporting this, but it does fit straightforwardly into the “created” and “modified” tags.
Typology: We have two typologies, each of which comes with a Super type, a Sub type, and a display text. One of these is a “monument type” (e.g. “Stele”, “Base”, Altar”). The other is an “Inscription type” (e.g., “Sacrificial calendar”, “Decree”). I’m not sure of the value of exporting these since this typology suits our project very well, but if exported it might create expectations of standardisation with other projects.
- For external purposes it might make sense to export the “type” for all as “inscription” (which, as mentioned above, forms part of the URL for individual entries)
- The other material might form some type of “label” tag? As I say, I’m not sure…
Location data: We distinguish between “Findspot”, current location (“collection”), and “original location”. These three types can presumably be treated as “lpo:relation”s . Potentially tricky is that many/most inscriptions are formed of multiple fragments called “monument part”s, each of which may have separate “Findspots” and “collections”.
- Findspot and Original location: These call on the same list of locations, which consists of text (e.g. “Eleusis”) and a Pleiades url. In order to get geographic co-ordinates and other location data, one would have to call those from Pleiades… and that seems to me correct.
- Collection: This provides a “reference number” (e.g. “E 89b”) and calls on a separate set of “Monument collection”s (e.g. “Eleusis Museum”) to give the museum number (“Eleusis Museum E 89b”).
- Currently, the “Museum Collection” is just a piece of text. Essentially at the moment it is yet another form of “id” that has the potential to become a location. But it would be good to leave space for this to include some sort of UID for museums (does such a thing exist?) and for a link to the collection’s catalogue page for the individual object; I’m not sure that I see AIO adding either immediately, but in the long-term we should…
- Places mentioned in: This would be another “lpo:relation”. Currently, places within the translated texts of individual entries are marked up thus: Eleusis - we would want to export the material within the tag as a plaintext description of the place and the Pleiades ref.
- Exporting information from tags within an entry isn’t currently possible for AIO, so this is one of the major tasks for the developer that we have hired (it will hopefully provide the basis for exporting other things marked up in the inscription texts, principally s ).
So, that is the metadata that AIO has and perhaps laying it out like that will help us start to think about how best to line it up with the linked-traces format. As will be clear, I have one eye on how we export the data for Linked-Traces and one eye on how the work AIO does in this instance can form the basis of exports of our data for other purposes. I hope that’s all clear and useful and I am very grateful for advice!