Digital approaches to the “Big Ancient Mediterranean”

DIGITAL APPROACHES TO THE "BIG ANCIENT MEDITERRANEAN"

Ryan Home

Introduction

There are an uncountable number of ways to approach the Mediterranean region, its history, and the peoples residing around it. The Mediterranean has been viewed as a unified whole, theorized as a space of networked micro-regions, or seen as lacking any significant unifying or organizational principle (Horden & Purcell 2000, pp. 10-49). Despite this diversity of academic approaches, over the past decade much of the digital scholarship on the ancient Mediterranean and Greco-Roman antiquity has embraced methodological and data standards to foster increased interoperability, data sharing, and discovery within a Linked Open Data (LOD) ecosystem. Seminars such as the Linked Ancient World Delta Institute (LAWDI), held at New York University and Drake in 2012-2013, and the Ancient Itineraries Institute, held at London and Athens in 2018-2019, have used LOD approaches to spur the theorization and development of new, innovative digital infrastructure for scholars of antiquity.1

However, there have been few attempts to combine Historical Geographic Information Systems (HGIS) and Social Network Analysis (SNA) into a unified, interactive model for the study of the ancient world. Although there has been extensive use of these technologies for research, especially in Archaeology, there has been far less attention and resources dedicated to creating open-access applications and sharing project data in the fields of History and Classics (Mostern & Arksey 2016, pp. 205-220; Mills 2017, pp. 380-382). Most work that has been offered digitally in these areas has dealt primarily with fixed locations and other physical features, or on social networks, which are treated on a schematic level, with only minimal interaction between the two parts.2 Geographically mapping social networks that represent individuals, without the aid of rich geodata, is rare. Some of this has to do with the limitations of the source materials; often all that remains of the ancient record is scraps of material, incomplete inscriptions, and other partially preserved sources. Another barrier has been technical; while there are different software projects that combine HGIS and SNA data sets, almost none have used ancient world data resources, focused on the unique needs of scholarship in Classical studies, or provided an extensible, customizable software base and interface to lower technical barriers for creating LOD applications. The Big Ancient Mediterranean (BAM) project fills this gap.3

BAM aims to use the growing body of LOD resources and scholarship by constructing a digital framework through which textual, geospatial, and network data can be developed and explored in a coordinated fashion. The “Big” in the Big Ancient Mediterranean has several meanings. It represents big data, not in the realm of scientific computation, but instead in reference to the ever-increasing open-access digital collection of textual, geospatial, and network data generated by scholars of the Classical and Mediterranean worlds. “Big” also evokes the macro-scale approach of much of this work; while we recognize the utility of small-scale approaches to ancient scholarship, BAM is envisioned as providing a set of tools that help to contextualize these studies within larger macroapproaches to ancient literature, geography, and connectivity. Finally, the “Big” describes the number of present and potential uses of the project, from tracing attestations of specific locations in literary sources, to exploring the development of garrisons from ~600 все to 200 ce, to serving as a tool for presentation and exploration of the ancient world in the classroom environment.

One of the primary goals of BAM is to bring together textual, geospatial, and network approaches, and as a result work on the project has necessitated the development of new tools and methodologies, especially to support our goal of offering a generalized and extensible framework. Our approach has adhered to two overriding principles: (1) to reuse software and methodologies wherever practicable and (2) to make the interface, both as a content creator and a viewer, as intuitive as possible.

This article serves as an introduction to BAM and the larger ancient world LOD ecosystem. It begins with an overview of LOD principles and their use in ancient studies. It then discusses the development of the BAM project and some of its outputs, and concludes with a discussion ofBAM’s future development and role within the rapidly developing community of ancient digital scholarship.

Linked open data and Mediterranean scholarship

The increasing use of linked open data (LOD) and other semantic web technologies have radically transformed the field of digital Classics. By presenting collections of freely available data which are connected to one another through various linking mechanisms, and the establishment of informal interest groups like Linked Ancient World Data Initiative, the digital Classics community is creating new, robust digital tools that are opening new possibilities for research and pedagogy.4

The creator of the semantic web, Tim Berners-Lee, described LOD as information on the web that is related to other data, which can be explored by a person or machine through links. Key to the operation of the LOD ecosystem is Berners-Lee’s five star model, which describes the ideal linked data resource (Berners-Lee 2007). Data have to be:

  • 1) available in the web
  • 2) in a machine-readable format
  • 3) which is non-proprietary
  • 4) using open standards to identify data, and
  • 5) linked to other people’s/project’s data to provide context.

For data to be truly LOD, the above points must be true and the data itself must be released under an open licensing agreement.3 The central idea is that data must be freely accessible, unencumbered by restrictive licenses, and linked to other content, which allows it to be used, remixed, expanded, and annotated in any number of different contexts.

To understand how LOD is used in the digital humanities and digital Classics communities, it is essential to examine one of the important technologies behind LOD, namely the RDF standard. RDF, or the Resource Description Framework, is a way of representing information about resources on the web (this is data about data, otherwise known as metadata), in a machine readable and actionable way. RDF depends on Uniform Resource Identifiers (URIs), which are a means to uniquely identify an entity/resource. One set of URIs use the hierarchical naming scheme of the world wide web (http://) to disambiguate entities, and it is this set that is relevant to the LOD model.6

Pleiades, one of the central projects in the LOD ancient studies ecosystem, makes extensive use of URIs. Growing out of The Barrington Atlas of the Greek and Roman World, the editors of Pleiades describe the project as follows:

... a community-built gazetteer and graph of ancient places. It publishes authoritative information about ancient places and spaces, providing unique services for finding, displaying, and reusing that information under open license. It publishes not just for individual human users, but also for search engines and for the widening array of computational research and visualization tools that support humanities teaching and research.7

Pleiades is a peer-reviewed digital resource that offers geospatial, linguistic, and reference information for over 36,000 places in the ancient world. Each place is identified by its own unique URI which disambiguates it from other resources. For example, there are 128 places with the name “Alexandria” in the database; the famous Alexandria in Egypt founded by Alexander III (“the Great”) of Macedon is identified by https://pleiades.stoa.org/places/727070, and the URI https://pleiades.stoa.org/places/658371 identifies Alexandria on the Issus, or modern iskenderun. Each URI is machine-actionable, meaning that a properly configured application can access the URI and receive some data that can be understood and acted upon without human intervention. By simply appending / rdf to the URI (https://pleiades.stoa.org/places/727070/rdf), an RDF representation of the Pleiades data is returned instead of the standard landing page.

The use of RDF technology by Pleaides is essential to its role in the LOD world. RDF uses URIs to describe data resources with simple properties and values (Latif et al. 2009, pp. 76-78). For instance, there could be an abstract identifier https://pleiades.stoa.org/places/423025 which has a title (the concept of title being defined at http://purl.org/dc/terms/title) of Rome. This declaration is called a “triple” which takes the form of . In our case the “subject” is the data at https://pleiades.stoa.org/places/423025, the predicate is the statement at http://purl.org/dc/terms/title, and the object is the literal value “Rome”. This is the basic framework on which LOD rests. Each component of a triple can be drawn from any number of controlled vocabularies, otherwise known as data ontologies. There are expansive ontologies offered by data providers like the Getty, USGS, DBpedia, and specialized ontologies, including ones focused on cultural heritage (See Roberto Rodriguez in this volume).8

Start of the Alexandria RDF file

FIGURE 5.2 Start of the Alexandria RDF file.

What this allows for is comparisons between projects with different ontologies and types of data. For instance, a project may be interested in the urban layout of Rome, while another may be interested in Rome as a political capital, and yet another with Rome as an element of some religious journey. All of these data sets could be explored for information on “Rome”, provided that they share links to an agreed upon URI; this could be the Pleiades URI (https://pleiades. stoa.org/places/423025), the GeoNames URI, Wikidata (www.wikidata.org/ wiki/Q220), OpenStreetMap (www.openstreetmap.org/relation/41485), or some other authority.

Linkages do not have to be exact. Using the Simple Knowledge Organization System (SKOS) ontology to describe data relationships, a project could state that its ancient version of Rome as a city is a close match to the Wikipedia definition of Ancient Rome (which also discusses the Roman Empire), but is an exact match of the Pleiades entry, which is based on the city itself.9 In this manner, any number of projects can have different definitions, labels, and data, yet they all describe or are in some way related to the same general concept.

The power of LOD

One of the key benefits of LOD is access to diverse types of data which can be discovered through an automated process (Pattuelli et al. 2016, pp. 918-922).

For instance, LOD providers of geospatial information almost always have coordinate data for an entity. In some cases, they may have even more complex geometries, like city walls, urban areas, and land use. At the same time, another project may have demographic data that can be linked to specific cities but does not itself offer geospatial information. Another initiative may concern itself with the economic history of a city, while any number of museums may link objects in their collections to the same place. If these different projects are using LOD to link their information to a common identifier, like the Pleiades ID for Rome, then all of these data are available for anyone to find and use through basic web technologies.

In practical terms, this allows a project to gain information and data that are curated, updated, and useful without reinventing existing efforts or focusing on areas of data collection and creation which are peripheral to the investigation. Many projects focusing on the ancient world use geospatial information from Pleiades, which allows for them to focus on their own data and arguments without expending undue effort in locating and creating geospatial information.

There are many other providers of LOD that offer URIs for a wide array of data: the Virtual International Authority File (VIAF) collates name records from participating libraries into singular URIs, and therefore serves as one of the primary sources for URIs related to individuals; PeriodO mints URIs for named time periods; and Nomisma creates URIs for numismatic concepts and mints, all of which can be used as a foundational element of a project, or enrich a digital presentation.10 The world of LOD is an ever-growing network of connections and projects, many of which can be found in the LOD Cloud or are discoverable through web searches or social media.11 Indeed, the BAM team has found that asking questions with the appropriate hashtags on twitter (#LOD, #linkedopendata, etc.) can often lead to the discovery of new LOD resources and communities.

Alignment with LOD

In order to gain these benefits from LOD, it is necessary to align a project’s data with one or more LOD providers. One strength of LOD is that individual projects do not have to radically alter their own data structures to participate with other data providers. Projects can use whatever identifiers or relationship structures are required by the research, sources, or materials—all that is required is for some table to associate those structures or entities with an external LOD contributor. A project that has data entities representing places, like the Rome example above, could create a new table that links each place entity in the database to a corresponding record in Pleiades, while a project that is concerned with coins could link each coinage type to a record in Nomisma, and a project that has information on known individuals could link their identifiers with VIAF. Often this process is done through the use of spreadsheets, where a project’s IDs and a human readable title are in separate columns, with any number of other columns

LOD Cloud

FIGURE 5.3 LOD Cloud.

reserved for corresponding LOD URIs. While this process used to be completed by hand (often through the Pleiades search functions), new tools like Recogito are using entity recognition software and innovative interfaces to make the reconciliation process easier and more accessible to a non-technical audience.12

Beyond the entities themselves, descriptive fields in a project database can also be linked to existing digital resources. To return to our Rome example, perhaps a project has assigned a feature type, essentially a descriptive phrase or numbering scheme, to compare Rome to other inhabited places. Much like associating entities with other data sets, these data structures can be linked to other data ontologies. In our example, if a project labels Rome as a “city”, a new table could be created linking its concept of city with the Getty Art & Architecture Thesaurus URI (http://vocab.getty.edu/page/aat/300008389) for “cities”. Much like finding information on Rome itself, this would allow a project to discover other data providers that deal with the concept of cities and reference the corresponding Getty URI, and optionally use the Getty’s conceptual hierarchy and ontology for geographic data types.

Visualizing and modelling LOD

One of the most common tasks for LOD data in the field of ancient studies is to map places that are mentioned in primary source documents or in research. Once data from a project are matched with an LOD gazetteer, the process of getting coordinates and mapping the results is trivial. For many projects, tools like Recogito can greatly aid this process, and the resulting coordinate information can be imported into a desktop GIS (such as QGIS or А к Map), online platforms like Antiquity Л-la-carte, or used with mapping libraries like Leaflet or OpenLayers (with backgrounds available from the Ancient World Mapping Center (AWMC) and the Digital Atlas of the Roman Empire) to create static maps or interactive mapping applications.13 Due to the use of unique IDs, these outputs can be built to integrate fully with the LOD ecosystem. Indeed, the integration of LOD with the continued development and refinement of digital historical gazetteers which provide spatial and onomastic information is a foundational component of the emerging LOD community (Isaksen et al. 2014, pp. 197-199; Grossner et al. 2016, pp. 80-84).

Another interesting option is not only to link data to LOD resources, but to model and display those linkages and relationships between data entities. For many projects in ancient studies, this entails linking people, and is accomplished through the use of SNA software, often through the popular Geplii platform.14 In this case, VIAF IDs are often used for well-known individuals, Trismegistos IDs for individuals in Graeco-Roman Egypt, or other IDs created by a project for its own use.15 These IDs are then linked together, generally on a spreadsheet, with terminology for the relationships between people drawn from an external data ontology, and the relationships themselves given a unique identifier. This spreadsheet is then brought into Geplii, where SNA statistics and visualizations are preformed, then the data are exported out into some web-accessible format which has URIs for both people and their relationships.

Creating and contributing LOD

What follows is a high-level overview of the technical and procedural requirements for actually creating a LOD application, which often limit its use (Rath 2016, pp. 268-271). As all LOD is built on stable URIs, the first task is to secure a hosting solution that will create and maintain an unchanging URL for the project. Many academic initiatives use university servers and thus have a URL scheme such as my-project.some-university.edu, some-university.edu/my-project, or something similar. While these types of URLS can be used, it is highly recommended that digital projects actually purchase a unique domain that is external to the university (like my-project.org), which is redirected to whatever hosting solution is used. This protects projects from changing server structures, software platforms, and does not tie the data to a specific institutional address.

Once the domain name and URI scheme has been selected for the project, the next step is to create some kind of “landing page” for each data item ID that is exposed to the public. Existing URIs and identifiers can be used for these pages, as that helps to disambiguate and simplify the LOD model. For instance, if a project has a data entity that represents Rome and is linked to the Pleiades data set, then a URI like www.my-project/423025 should resolve to a page that, at the very minimum, provides some information on the entity Rome in the project, perhaps with the internal project ID listed as well. This eliminates a proliferation of URIs that refer to the same subject, and allows for easy browsing and data access. The actual internal structure and visualization of the pages are up to the project; some best practices include offering alternate data formats, like .json and .rdf, as both selectable from the page and machine accessible as part of the URI. Continuing our example, if alternate data formats are offered, then www.my-project/423025/json should offer a .json formatted version of the data, www.my-project/423025/rdf should point to the data in .rdf form, and so on.

This can be accomplished through a variety of means, including a database- driven site that dynamically serves pages on demand, or a site that has static landing pages for each item in the database. The choice of approach is largely dictated by the hosting environment, and therefore is somewhat unique to every project. For initiatives that enjoy extensive technical support and fast-hosting computers, a dynamic site (with a database backend combined with PHP) may be attractive. For other projects which do not have access to fast servers or online databases, a collection of pre-generated static pages may be preferable.

After establishing a stable URI and website infrastructure, all that remains is the publication of linkages between project data and other LOD resources. In most cases, this is simply a matter of taking a table that already expresses linkages in a project database and formatting the output in whatever way is required by what is being linked to.16 For Pelagias, this takes the form of an .rdf file in a specific format, the key component of which is linking a target, or the object in a project database, as an annotation to an existing gazetteer resource (like a Pleiades ID).17 Once this is done, the project is then discoverable and accessible to the wider LOD community.

BAM: background and development

The functional and technical considerations outlined above often hinder the production and use of LOD in scholarship. Although there has been much exciting and pioneering work in the LOD ancient studies ecosystem, less attention has been paid to increasing access to creating and curating LOD projects. Tools like Recogito provide an excellent interface for connecting data sources, but they do not focus on the development of larger digital projects and complex visualizations that tie together geospatial and network data. In addition, there remains a demand for a somewhat high technical knowledge for full use and construction of LOD, both for research and pedagogy. BAM was designed from the beginning to operate within the LOD and ancient studies worlds, both to lower the technical barrier for users and to create a unified interface for exploring different digital approaches to Classical studies.

The unifying principle of BAM is the development of a suite of accessible and connected digital tools and methodologies that enable the exploration of textual, network, and geographical data in novel ways. BAM is built upon open source and open-access principles, with the idea that all code and data produced by the BAM project should be freely accessible to scholars, students, and the general public. Sarah Bond and Paul Dilley founded BAM in 2014, and lead developer and ancient historian Ryan Horne soon joined the team. After an initial planning phase, they undertook a two-week organizational session at the University of Iowa’s Obermann Center for Advanced Studies in 2015. A workshop, Linking the Big Ancient Mediterranean Conference, was held at the University of Iowa in June 2016, at which various project representatives shared data and offered feedback on the interface. Development work on BAM is ongoing, with a third major version envisioned for release in 2021.

The initial code for BAM is based on the Antiquity d-la-carte application, a web-based lightweight GIS that allows users to create custom maps from Pleiades resources and their own data on a geographically accurate base map of the ancient world.18 This original codebase was built with OpcnLayers sitting on a PostGIS database and MapServer backend, which allowed the custom digital elevation model created by the AWMC to be used as the underlying base map.19 At the time of its creation, Antiquity d-la-carte was the only resource available that allowed for the creation of custom maps of the ancient world that reflected modern knowledge of ancient geography.

The main screen of Antiquity d-la-carte

FIGURE 5.4 The main screen of Antiquity d-la-carte.

The first step in the development of BAM was to create a data set that featured both network and geographic data. Our development started with data entry through spreadsheets, which is hardly a novel technology for the majority of historians. Working from a data set of co-locations in the Gospel of Luke compiled by Cory Taylor at the University of Iowa, these data were slightly modified to create two lists of nodes (in our case people and places), and a separate list of the connections between them (i.e. Jesus and John appearing at the same place). These were imported directly into Gephi, an open-source tool for network analysis, where community detection was performed using the Louvain community detection algorithm. The result is a visualization of the social network in Luke that displays both the connections between each node and a sub-group in which they belong.

The next step of the project involved finding geo-information for each locat- able place mentioned in Luke. The original .csv was imported into a PostGIS database, and then the Latinized name of each location was matched with names and location data from the Pleiades Project. As Pleiades contains geospatial information, mapping the results in a web environment was a simple exercise. What was more difficult was linking the network and geospatial visualizations. We first needed the network data to be in a form that was consumable by our javascript application. To accomplish this, we extended code from the SigmaJS exporter produced by the Oxford Internet Institute to communicate with the DataTables plugin for jQuery, which allows all of the data to be presented in a searchable, tabular form.20 This interface allows a user to click on any node in the social network graph, and the map responds by highlighting the locations (if any) associated with the node. Clicking on a map location brings up a tabular popup displaying the various nodes associated with a place, and clicking on the name of a node changes the network graph to highlight only that particular node and its neighbours. Detailed instructions for how we accomplished this process, and sample code, are available online.21

Despite the success of the different components communicating with each other, this interface still displays the network graph and map as two discrete entities. In order to show how the social network is influenced by geography, we found it necessary to combine these components into a single interactive screen that both displays a map and places a social network on top of it. This separation into different panes, the somewhat unintuitive interface, and the necessity to extensively customize the codebase for each project presented challenges to its usefulness for the number of different projects and modules envisioned by the team.

BAM phase 2

Between the creation of BAM phase 1 and the desire to update the codebase, there were significant developments both in web mapping technology and the larger ancient world LOD ecosystem. To begin with, the Leaflet javascript library

The BAM interface

FIGURE 5.5 The BAM interface.

became widely adopted by the web mapping community, which, coupled with the library’s lightweight, more modern design, made it an attractive choice for the new version of BAM.22 In addition, the D3.js library was increasingly preferred by web developers over SigmaJS, and the ability to integrate Leaflet and D3 into the same project provided new opportunities for data visualization, especially with data sets that proved too large to display using pure web-mapping libraries.23

Projects associated with linked data and the ancient world also began to offer new tools and resources. Pelagios Commons began offering new tools like Peri- pleo to visualize linkages between different ancient world data sets and Recogito, which associates arbitrary text with online gazetteers.24 Other projects, like the Perseus Digital Library, PeriodO, Trismegistos, and Online Coins of the Roman Empire increasingly adopted and published LOD resources which could easily be integrated into other LOD projects.25

Against this backdrop, the decision was made to further integrate BAM’s tools and code to increase its accessibility to non-technical specialists. The BAM code was rewritten as a modular javascript framework that reads .json configuration files to customize BAM for each module.26 Now, most modules in development can simply change the underlying data and one configuration file without the need to extensively customize the codebase. The interface was changed to display a full screen “main” area with different configurable panels; the main area itself can be configured to feature a map, a network, or a network overlaid on a map. By using the combination of D3.js and Leaflet, BAM can now potentially show thousands of places, connections, and animations, further increasing its applicability to big data humanities projects.

The pipeline for bringing data into BAM has also been streamlined. In its most basic functionality, BAM allows a user to simply place a .csv file into the

BAM version 2 interface

FIGURE 5.6 BAM version 2 interface.

data directory and change the appropriate lines in the BAM configuration file; BAM will then display each row of the .csv file as a point location on an interactive mapping application. The entries in this file do not have to be associated with any other linked data projects or systems; all that is needed is coordinate information. Another avenue for creating a BAM module is to have a file that already associates data with Pleiades IDs. By using a simple python script the number of places in a data set can be quantified and mapped, with the resulting file displayed directly in BAM.27

For users who want to associate their data with some form of network analysis, all that is necessary is to bring their data into Geplii, perform the desired analysis, then export the result in a .json format. The user then changes the BAM configuration file as needed, and BAM will place any geospatial information on the map, with non-geospatial data points placed between their connections. BAM preserves all of the node/edge colour, size, and connectivity information, and the connections between the various points are drawn as schematic lines.

The application recognizes longitude and latitude information in the inputted data and assigns nodes that have these values to fixed location on the map. After using this information to set the centre and zoom of the map, the remaining nodes of the network graph are then displayed, using the forced layout capabilities of D3.js to place the remaining nodes.28 This approach re-configures the display of the network depending on the zoom level decided by the viewer, and highlights the importance of fixed locations for nodes which do not have their own specific geographic data. The visual touch of such nodes being animated is an additional clue to the end user that they are distinct from locatable information (such as a place), and should be viewed and analysed with a different approach.

All of this work was accomplished through extending and modifying existing codebases, and the code underpinning our application is released under GPLv3 by the BAM team through our GitHub repository.29 Of interest to other projects (both inside and outside the temporal bounds of the ancient world), the modular nature of our effort allows for any correctly formatted data from Geplii to be displayed in the interface with minimal, if any changes to the code itself.

A currently experimental method for BAM is to function as an end point for other digital resources in the ancient world. For instance, we are currently developing a way for BAM to ingest files that conform to the Linked Places format, which is currently used by Pelagias and will be a fundamental component of the new World Historical Gazetteer under development at the University of Pittsburgh.30 By allowing files (and data connections) from sources that use this format, BAM will be able to function as a discovery and visualization interface for an even larger variety of LOD projects.

Whatever the source of the data, BAM is designed to run in multiple server environments. As many digital humanities projects and initiatives do not have access to extensive server resources, especially in their design and development phase, BAM is designed to run in any environment that is capable of serving javascript. As a result, new modules can be run in many free websites, including GitHub pages, with full searching, linking, and display functionality without the need to install or maintain a database. BAM can also be extended to work with dynamically served content; currently the Iowa Cannon of Classical Literature uses the BAM interface with custom PHP scripts to display a variety of different faceted searches and data files. This flexibility allows BAM to be used in any number of projects from a wide array of contexts. From modules that present all of the places mentioned in Strabo, to an audio archive of modern artists in the Black Lunch Table project, BAM is designed to be a flexible tool to integrate projects into the wider scholarly linked data ecosystem.31

Future development

The new interface, however, is still incomplete. The ability to travel through the text, and to make meaningful connections between the text, the social graph, and the map is still in the early stages of development. Although the social network graph and the map are easily extensible and reusable by different projects, the textual display still requires extensive customization, including interaction with relevant APIs. While any text obtained by an API could be displayed by BAM, the input of TEI encoded data is required for advanced functionality, which is not feasible for every project for any number of reasons including cost, availability, and copyright.

Our interface and methodology only offer preliminary steps into the problem of representing incomplete and fuzzy social networks in a geographic context. Further work needs to be done to make some locations “weigh” more than others, attracting nodes that have stronger connections to one location than another, and shortening the distance between them. Another issue is that while the social network is shown in space, and there are clusters around specific places that are important to individuals, the result is still largely schematic. The actual features of the underlying terrain (elevation, rivers, roads) are not accounted for. The ORBIS API offers an intriguing possibility for measuring the actual travel time between some of the nodes on the network, but ORBIS does not contain travel times for all ancient places which are of interest to BAM.32 As a result, BAM is looking forward to further refinement and development, in an effort to effectively capture some of the complexities of social networks in communities where near instantaneous communications were virtually unknown, and obstacles, whether they be geographic, human-made, or both, profoundly influenced communication.

While BAM modules can stand on their own, perhaps the most potentially impactful use of BAM is as a gateway into LOD. BAM is capable of serving as an endpoint for URIs; for example, a URL structured like http://www. someBAMmodule.org/someURL can select a data point that has some URI as its ID, allowing for direct access to the data. We are currently developing code to increase the customization of such requests, including the construction of configurable landing pages and a directory structure to mimic dynamically hosted content for projects that operate in javascript-only environments. Another area of development is the continued integration of BAM into the linked data ecosystem. We envision a new set of visual tools within BAM to facilitate linkages between the data in a module and other projects, like Pleiades IDs, reconciliation offered by Recogito, PeriodO time periods, and text from Perseus. This would significantly lower the difficulty of reconciling data with existing LOD resources, which would benefit the module developers and contribute more linked data, making the process even easier for future users.

We are also working on further interface improvements, including a visual interface for creating configuration files and configurable content, with an eye towards developing a BAM app that can take a simple spreadsheet and generate a BAM module, complete with a file structure that supports stable URIs, in a browser-based environment. This would create a new, point-and-click system that could bring data and projects into the LOD cloud without any modification of underlying code or configuration files. This approach would further broaden access to LOD systems and resources, enabling nearly any project to contribute its data to the larger LOD digital ecosystem.

Conclusion

Advances in digital scholarship, combined with an ethos of open-access and an embrace of LOD principles, has revolutionized digital classical studies. An increasing number of projects, tied together through the use of common URIs, have created a robust digital ecosystem that supports a variety of scholarly approaches to the ancient world. The BAM seeks to leverage this rich landscape of linked ancient world data, while providing accessible geospatial, network, and textual exploratory tools. The development of a streamlined interface enables new readings of ancient sources by providing students, teachers, researchers, and the public with an open-access toolset wherein they can interact with texts, maps, and visualizations from an ever-increasing number of LOD projects.

Notes

  • 1 See the papers in Elliott et al. (2014); also https://ancientitineraries.org/.
  • 2 For some examples see Doling (1999, 2000), Smith (2005, pp. 833-845), Cline (2012, pp. 62-70), and Bordoni (2015, p. 126).
  • 3 https://github.com/Big-Ancient-Mediterranean/BAM
  • 4 See the hashtag #LAWDI on twitter.
  • 5 The Journal of Open Humanities Data has a useful reference for different open licenses: https://openhumanitiesdata.metajnl.eom/about/#q5
  • 6 For more information on URIs, see Keith et al. (2015, pp. 117-118) and Blaney (2017).
  • 7 https://pleiades.stoa.org/
  • 8 Getty, www.getty.edu/research/tools/vocabularies/lod/; USGS, www.usgs.gov/ core-science-systems/ngp/cegis/linked-geospatial-data?qt-science_support_page_ related_con=l#qt-science_support_page_related_con’; DBpedia, https://wiki.dbpedia. org/services-resources/ontology; https://github.com/lawdi/LAWD
  • 9 SKOS, www.w3.org/TR/2008/WD-skos-reference-20080829/skos.html; Wikipedia entry for Rome, https://en.wikipedia.org/wiki/Ancient_Rome
  • 10 VIAF, https://viaf.org/; PeriodO, http://perio.do/en/; Nomisma, http://nomisma.org/
  • 11 https://lod-cloud.net/
  • 12 https://recogito.pelagios.org/
  • 13 Antiquity A-la-carte, http://awmc.unc.edu/wordpress/alacarte/
  • 14 https://gephi.org/
  • 15 www.trismegistos.org/
  • 16 See Becker et al. (2013) for an example.
  • 17 https://github.com/pelagios/pelagios-cookbook/wiki/Joining-Pelagios
  • 18 http://awmc.unc.edu/wordpress/alacarte/
  • 19 OpenLayers, https://openlayers.org/;PartC/S, https://postgis.net/;MapServer, https:// mapserver.org/
  • 20 Oxford Internet Institute, https://marketplace.gephi.org/plugin/sigmajs-exporter/; Data Tables, www.datatables.net/; jQucry, https://jquery.com/
  • 21 https://rmhorne.org/2015/09/28/code-for-bam-part-l-of-n-gephi-and-maps/
  • 22 https://leafletjs.com/
  • 23 D3.js, https://d3js.org/;https://rmhorne.org/2015/11/11 /2-of-n-gephi-d3-js-and-maps- success/
  • 24 Pelagios Commons, http://commons.pelagios.org/; Peripleo, https://peripleo.pelagios. org/; Recogito, https://recogito.pelagios.org/, and Simon et al. (2017).
  • 25 Perseus, www.perseus.tufts.edu/hopper/;PenodO, http://perio.do/еп/;Trismegistos, www. trismegistos.org/; Online Coins of the Roman Empire, http://numismatics.org/ocre/
  • 26 https://github.com/Big-Ancient-Mediterranean
  • 27 https://github.com/rmhorne/pleiades_utilities/tree/master/pleaides_parser
  • 28 https://github.com/mbostock/d3/wiki/Force-Layout
  • 29 https://github.com/Big-Ancient-Mediterranean/BAM
  • 30 https://github.com/LinkedPasts/linked-places; http://whgazetteer.org/
  • 31 http://awmc.unc.edu/awmc/applications/strabo/: http://archive.blacklunchtable.com/ network/
  • 32 http://orbis.stanford.edu/api/

References

Becker,). A., Florne, R. and Talbert, R. J. A., (2013). The ancient world mapping center. Pelagios [online]. [Viewed 18 May 2020]. Available from: http://pelagios-project. blogspot.com/2013/01 /the-ancient-world-mapping-center.html

Berners-Lee, T., (2007). Linked data. W3 Design Issues [online]. [Viewed 18 May 2020]. Available from: www.w3.org/DesignIssues/LinkedData.html

Blaney, J., (2017). Introduction to the principles of linked open data. Programming Historian [online]. [Viewed 18 May 2020]. Available from: https://programminghistorian.org/ en/lessons/intro-to-linked-data

Bordoni, L., (2015). Social network analysis for sharing and understanding archaeology. In: J. A. Barcelo and I. Bogdanovic, eds. Mathematics and archaeology. Boca Raton, FL: CRC Press, pp. 123-134.

Cline, D. H., (2012). Six degrees of Alexander: Social network analysis as a tool for ancient history. Ancient History Bulletin. 26, 59-70.

Duling, D. C., (1999). The Jesus movement and social network analysis (part I: The spatial network). Biblical Theology Bulletin: A Journal of Bible and Theology. 29(4), 156-175.

Duling, D. C., (2000). The Jesus movement and social network analysis (part II: The social network). Biblical Theology Bulletin: A Journal of Bible and Theology. 30(1), 3-14.

Elliott, T., Heath, S. and Muccigrosso, )., eds., (2014). Current practice in linked open data for the ancient world. ISA W Papers 7 [online]. New York: Institute for the Study of the Ancient World, New York University, [Viewed 18 May 2020]. https://doi. org/2333.1/gxd256w7

Grossner, K., Janowicz, K, and Kelilcr, C., (2016). Place, period, and setting for linked data gazetteers. In: M. L. Berman, R. Mostern and H. Southall, eds. Placing names: Enriching and integrating gazetteers. Bloomington: Indiana University Press, pp. 80-96.

Horden, P. and Purcell, N., (2000). The corrupting sea: A study of Mediterranean history. Malden, MA: Blackwell.

Isaksen, L., Simon, R., Barker, E. T. E. and de Soto Canamares, P., (2014). Pelagios and the emerging graph of ancient world data. Proceedings of the 2014 ACM Conference on Web Science (WebSci ’14). New York, NY: Association for Computing Machinery, pp. 197-201. https://doi.org/10.1145/2615569.2615693

Keith, M., Binding, C. and Tudhope, D., (2015). Barriers and opportunities for linked open data use in archaeology and cultural heritage. Archdologische Informational. 38, 173-184.

Latif, A. et al., (2009). Turning keywords into URIs: Simplified user interfaces for exploring linked data. In: S. Sohn, L. Chen, S. Hwang et ah, eds. Proceedings of the 2nd International Conference on Interaction Sciences: Information Technology, Culture and Human 2009, 24-26 November 2009, Seoul, Korea, pp. 76-81.

Mills, B., (2017). Social network analysis in archaeology. Annual Review of Anthropology. 46, 379-397.

Mostern, R. and Arksey, M.. (2016). Don’t just build it, they probably won’t come: Data sharing and the social life of data in the historical quantitative social sciences. International Journal of Humanities and Arts Computing. 10(2), 205-224.

Pattuelli, M. C., Hwang, K. and Miller, M., (2016). Accidental discovery, intentional inquiry: Leveraging linked data to uncover the women of jazz. Digital Scholarship in the Humanities. 32(4), 918-924.

Rath, L., (2016). Low-barrier-to-entry data tools: Creating and sharing humanities data. Library Hi Tech. 34(2), 268-285.

Simon, R. et ah, (2017). Linked data annotation without the pointy brackets: Introducing Recogito 2. Journal of Map & Geography Libraries. 13(1), 111-132.

Smith, M. L., (2005). Networks, territories, and the cartography of ancient states. Annals of the Association of American Geographers. 95(4), 832-849.

 
Source
< Prev   CONTENTS   Source   Next >