{"id":682,"date":"2025-09-19T21:02:33","date_gmt":"2025-09-19T21:02:33","guid":{"rendered":"https:\/\/duraeuroposarchive.org\/?p=682"},"modified":"2025-09-19T21:02:34","modified_gmt":"2025-09-19T21:02:34","slug":"data-modeling-for-contextualized-epigraphy","status":"publish","type":"post","link":"https:\/\/duraeuroposarchive.org\/ar\/data-modeling-for-contextualized-epigraphy\/","title":{"rendered":"Data modeling for Contextualized Epigraphy"},"content":{"rendered":"

Guest blog post by Ethan Clark, IDEA_Lab@EH Intern (Summer 2025)<\/p>\n\n\n\n

While I had an understanding of IDEA\u2019s general mission before getting involved this summer, I knew next to nothing about the project\u2019s methodology. What exactly was \u2018Linked Open Data\u2019 (LOD), and what could it offer that other means of information management for cultural heritage might not? At first, it sounded to me like abstract technical jargon, but Linked Open Data is nothing more than what it sounds like: a means of cataloguing data, <\/em>which in our case are the tens of thousands of artifacts, buildings, and information garnered from past excavations of Dura-Europos. LOD is then distinguished by being universally accessible (open<\/em>), and having metadata interconnected with all entries (linked<\/em>). IDEA works entirely within a LOD framework known as Wikidata, which structures an item\u2019s data in statements with a \u2018subject (item) \u2014 predicate (property) \u2014 object (value\/item) \u2014 qualifier\u2019 information flow.  For example, the Wikidata item for Dura-Europos includes a statement using the property \u2018inception\u2019<\/em>, value \u2018300 BCE\u2019<\/em> and property-item qualifier \u2018sourcing circumstances- circa.\u2019<\/em><\/p>\n\n\n\n

My workflow for the first few weeks centered around getting acquainted through hands-on experience. This initially consisted of filling gaps in existing entries, eventually creating new items using the project\u2019s established data models (i.e, information mapping blueprints for general categories of items), and then zeroing in on inscriptions as my area of focus. Inscriptions turned out to be a great case study of LOD\u2019s ability to democratize information, given how rife epigraphy can be with field-specific notations and terminology\u2014let alone the near-century old Dura scholarship. Wikidata was the perfect tool for streamlining this material into a faithful yet far more comprehensible form, and it was incredibly rewarding to adopt a fascinating but antiquated discipline in a modern digital context.\u00a0
\u00a0In the latter half of the summer, I shifted to a different project: researching and populating an entry for a triumphal arch and its accompanying inscription located just outside the city. This introduced me to architecture as a discipline, which I discovered had quite a bit of overlap with epigraphy. Their similarity somewhat makes sense, especially in situations like this one, where an inscription is itself an architectural element. But to my surprise, the architectural sources I worked with were often just as filled with jargon and conjecture as the epigraphical material I\u2019d worked with previously. Although I did successfully create a thorough entry after lots of trial, error, and consultation, a confluence of exceptions conspired to make modeling this arch uniquely thorny. For starters, even after sifting through every single triumphal arch listed in Wikidata, I was unable to find a single existing instance of the types of information I wished to reflect. Whereas I had previously had the luxury of referring to data models, I was now in far more uncertain territory. Several issues would arise throughout this process\u2014ambiguous location, outdated information, and a fragmented double-sided inscription, to name a few\u2014but the most exceptionally difficult to deal with was its myriad of individual components and each\u2019s uncertain present condition and whereabouts. How could we clearly reflect that the attic was never found but had to have existed, the molding was found in 1931 but is since unattested, and one of its pillars remains in situ<\/em> as of 2010? I eventually settled on making use of the \u2018state of conservation\u2019 property like so:<\/p>\n\n\n\n

\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n<\/figure>\n\n\n\n

My first foray into Linked Open Data this summer allowed me to see for myself how useful it could be as an archiving methodology. First and foremost, I now appreciate how crucial comprehensive data models are for projects of this magnitude. Not only do they standardize and streamline the creation of more basic entries, but lessons learned from trickier arch-style cases can then be integrated to improve the model going forward. The arch project also forced me to recognize the importance of clarity and concision when attempting to reflect complex information. At some points, I realized that my efforts to diligently reflect the detail of my source material had resulted in me replicating their inaccessibility\u2014one of the very issues that the project seeks to address. While it\u2019s important to try and incorporate as much info from our primary sources as possible, it\u2019s equally vital that this be done in a thoughtful and broadly understandable manner. Last but not least, this arch project enabled me to explore Wikidata\u2019s amazing data visualization and mass upload tools. During my aforementioned search for analogs to the arch, I noticed that most other Roman triumphal arch entries lacked metadata explicitly marking them as \u2018Roman\u2019. After manually identifying which of the arches were built in the Roman era, I added the appropriate \u2018culture- Ancient Rome\u2019 statement en masse using the software OpenRefine. With this statement in place, Wikidata\u2019s query service allowed me to map the location of every Roman triumphal arch item.<\/p>\n\n\n\n