Applying Linked Open Data Standards

Introduction: LOD - Terror and Promise

Linked open data (LOD) can be a frightening concept. Far from the conventional model of research, where a monograph or article is a well-formed, clean, and polished culmination of inquiry conducted in private, LOD is public, often messy, and rarely seen as “finished.” Somewhat equivalent to electronically providing notes or a card-index, LOD is a collaborative enterprise which stresses open-access, connectivity, and new ways of thinking about publication and research which are often at odds with traditional models of recognition and reward. LOD also pushes many practitioners out of their traditional areas of expertise, with unfamiliar and often intimidating terms, technical jargon, and challenging infrastructure requirements.¹⬈#p1

Despite these supposed obstacles, there is a remarkably robust community of practitioners and projects that embrace LOD methodology in the humanities, and in particular in the field of ancient studies. In the last decade there has been a fundamental shift in the way that digital projects of the ancient world are presented and created.² Unlike some monolithic digital projects of the past, this new digital ecosystem is built upon shared data, connectivity between different initiatives, and a thriving community that is redefining interdisciplinary approaches and collaborative work.³ Although the number of ancient world studies projects that use LOD as a core component of their development is rapidly expanding, the intricacies of creating, curating, and using LOD can still seem complex and overwhelming. What follows is an overview of structuring and preparing data to get the best use of LOD resources.⬈#p2

LOD: A (Quick!) Overview

First, it is important to understand the concepts underlying linked data and LOD. Linked data has essentially four components: it is data that is on the web; it has a stable address (a URI) that provides information about a resource; that information is in a standard format; and there are links to other URIs about the same or related subjects.⁴ For example, a project that centers on the Roman empire could have a page on the city of Rome with a URI of exampleproject.org/Rome, which fulfills the first two conditions. This same project could have representations of Rome in standard data formats (explained below) at exampleproject.org/Rome/json or exampleproject.org/Rome/rdf, and within this data there could be links to other resources about Rome (such as https://pleiades.stoa.org/places/423025) which are themselves URIs. For a project to practice LOD, all of the above has to be true and the data needs to be released under an open license.⁵ ⬈#p3

The use of an open license is essential for the success of LOD. Although individual licenses and terms vary, without the ability for any project or user to access data without restrictions beyond requiring citations could create pockets of inaccessible, yet still referenced, data. This is not only opposed to the spirit of the LOD movement, but such a situation would prevent the automatic retrieval and use of data, rendering the LOD approach moot. The essential benefit of LOD is that data about the same concept (Rome for instance) can be accessed and shared across different projects. Perhaps one project, such as Pleiades, focuses on the location of ancient places, while another project, SNAGG: Social Networks and Ancient Greek Garrisons, catalogs and studies different garrisons in the Greek world. If Pleiades offers its geospatial information about ancient locations in a LOD format, then the SNAGG project can link its records about garrisons to corresponding Pleiades records about places and gain all of the geospatial data and information in Pleiades. At the same time, SNAGG can link to other projects that also use Pleiades IDs; if SNAGG became interested in the minting activity associated with garrisons, it can automatically access all of the numismatic data (mints, coin hoards, production, and even individual coins) that are offered by the Nomisma project, which associates Pleiades IDs with ancient mints.⁶⬈#p4

This series of linked projects, all using recognized identifiers, LOD principles, and common data formats collectively forms a LOD ecosystem or LOD cloud. There is no central controlling organization or committee that determines who or what can participate; the LOD ancient studies community is constantly evolving as more project link their data to one another. From discovering geospatial data, and quantifying coin production to the distant reading of texts, creating prosopographies, and studying Syriac, the LOD ancient studies ecosystem offers ever-expanding ways for a project to discover and contribute insights into the ancient world.⬈#p5

The Basics: Getting Your Data Ready for LOD

The first step for any potential LOD project is understanding the nature of your data. Is the project focused on textual analysis? Is there a geospatial component? Does the research study individuals, collectively or individually, real or mythical? Are there any objects, whether they be coins, vases, or ships, artworks or tools, that feature in the study? What is the relationship between these people, places, objects, and concepts? ⬈#p6

All of these questions are related to the entities under consideration. Even if they are not traditionally enumerated outside of a print index, each individual, place, object, or concept in a study can be treated as a discrete data record. What this means in practical terms is that each entity could be given its own row in a spreadsheet or database, with relevant information entered into each column or field. For instance, a person record should address certain common metadata categories: a common name, birthplace, date of birth, date of death, political affiliation, or any other number of characteristics. A place record could include geographic location, population size, references in primary sources, etc. Whatever the content of a record, each should have a unique ID (this can be any arbitrary but unique sequences of numbers, characters, or both) that differentiates it from other records. This is somewhat analogous to a social security number for each data element; although people and places can (and often do!) change and/or share names and affiliations, an individual ID will have a one-to-one, unchanging relationship with its record.⁷⬈#p7

Such work is an essential element for modeling and understanding the complex data of humanities research. As mentioned above, people and places could be known by any number of names in any number of languages at any number of different times. For example, The Eternal City, Roma, and Caput Mundi are different names which nevertheless refer to the same conceptual entity of Rome. At the same time the exact meaning of that entity to different audiences can change; for some, Rome is home, for others it is a workplace, and for another group it is a vacation destination. At the same time a place, concept or person may have different emotions attached to it; Rome could be a place of celebration, indifference, trauma, or hatred. By creating a system where each entity has a unique ID, any number of different meanings, names, and values can be related to the same conceptual subject, allowing any number of computational and semantic queries to be performed on the data. Much like a human knows that various names refer to the same conceptual entity of Rome, modeling data in this way allows a computer to understand the same connections between different definitions, names, and any number of subjects. ⬈#p8

The essential methodology for creating such a system is already embedded in many research practices. For instance, a study of Cicero’s letters may wish to know how many letters there are, who was the intended recipient for each letter, what people and places were mentioned in the letters, and where the letters were written. Similarly, a project of Greek garrisons may wish to identify garrisons, their locations, commanders, and establishing authority. Simply listing and assigning a unique ID to the various answers to these research questions creates the basic elements of a record. Using our examples above, each one of Cicero’s letters should be a new row in a spreadsheet, as should each establishing authority of a Greek garrison. Additional information, such as references to ancient sources, categories for the place/person, or extended notes for each record, should be entered into new columns.⬈#p9

After establishing an entity and its various data fields in a database, the next task is to describe its relationship to other records. For projects that wish to use a form of social network analysis (SNA), this often takes the form of another spreadsheet/table which focuses on the edges, or connections between different entities (nodes in SNA terminology). In its most basic form such a table has a source column (the node about which the connection is about) and a target (what the source is connected to). For example, a project may wish to model the Seleukid kingdom as a sum of its component communities, with each edge taking the form of “community x is part of political entity y”. Such a relationship can be modeled as Abydos → subordinate → The Seleukid Kingdom (see Illustration 2). This spreadsheet/table can have additional columns further specifying the type of connection, source references, and human-readable titles in addition to the source and target IDs. In addition, each connection should have its own unique ID (which can simply be a sequence of numbers or some other arbitrary scheme) so they can be disambiguated and offered as LOD in their own right.⬈#p10

Beyond organizing and presenting the objects of a study, following this process also results in the creation of a digital gazetteer. Gazetteers are an essential component of most LOD projects and are a major academic and research pursuit in their own right.⁸ Traditionally, gazetteers have largely been conceived of as structured lists of place names compiled from or otherwise related to maps. These lists may contain data, such as feature classification, reference information, and places which are otherwise difficult or impossible to render on traditional print pages, including mythical and imaginary locations, conceptual groupings, and places which have left no secure archaeological traces.⁹ Gazetteers are not limited to simply describing places on maps; they can contain information on how different places relate to each other, research notes, bibliography, or any other data on a place.⬈#p11

This limited and almost strictly geospatial definition of gazetteers is currently under significant challenge. One project, NEH funded Period0, bills itself as “..a public domain gazetteer of scholarly definitions of historical, art-historical, and archaeological periods.”¹⁰ Instead of focusing on geospatial information, Period0 provides unique identifiers that disambiguate different scholarly definitions of time periods. For instance, the Classical Period as defined by the Pleiades project is found at http://n2t.net/ark:/99152/p03wskd.⬈#p12

Similar to Period0, the Getty/Mellon funded Ancient Itineraries Institute is also using a gazetteer-centered approach to not only disambiguate place names, but also to describe people, artworks, art styles, and their relationships to one another. With a growing number of initiatives and projects viewing gazetteers in a more expansive manner, digital gazetteers are increasingly not only presenting traditional place name information, but are also further developing tools and methodologies to model and explore the relationships between entities. ⬈#p13

The Pleiades project offers an example of this approach. Originally started as an outgrowth of the project that resulted in the creation of the Barrington Atlas project,¹¹ Pleiades is a peer-reviewed, community driven gazetteer and graph of the ancient Mediterranean world, which now features geospatial information on over 36,000 ancient places.¹² Each place entry in the Pleiades data set has its own unique ID in addition to information about variant names, time periods, external references, and connected places. ⬈#p14

Place connections in Pleiades started as a means to simulate complex geographic features whose precise geometries are unknown today. Instead of storing the modern geometry of a river, Pleiades instead connected features that were known to border the river (settlements, forts, mountain ranges, etc.), and then created an impression of the river’s geographic context. This concept is now under expansion in the Pleiades database, and other uses of connections, from denoting political and cultural groupings, to geographical proximity, to cultural zones are all being added to the gazetteer.⬈#p15

As more projects expand the conception of digital gazetteers from named lists to entities and their relationships to one another, LOD promises exciting new possibilities for research. Much like establishing connections within a project enriches the data set and can lead to new discoveries, so can linking the data to an external source. For example, due to the breadth of its coverage and its embrace of LOD methodologies, Pleiades has become the premier place gazetteer for much digital scholarship in the ancient world, and many projects use its identifiers to not only gain geospatial information about their study area, but also to gather information about artifacts, coins, and texts that are related to their research. Unlike other gazetteers or geospatial providers which are primarily concerned with making their data available on the web as standalone applications that do not provide stable links to each place record or an efficient means to extract data, Pleiades was designed from the beginning to be part of a LOD ecosystem. It provides stable identifiers under an open license that other projects can link to and enrich, as well as an API that allows for the automated retrieval of place information. As a result, it is a simple matter to get the geospatial information for each place in the data set to another project through the process of reconciliation, which is explained below.⬈#p16

Aligning Your Data With LOD Projects

One of the most important tasks in a LOD project is to reconcile data with other projects. This does not necessitate any significant changes in a project’s underlying data collection, database, or research practices; all that is required is to point internal data IDs to IDs from any number of external sources.¹³ For many projects this takes the form of a “linking” table that simply lists project IDs and one or more corresponding external URIs. The initial reconciliation task is most often performed by matching place/person names from a project’s database to another data resource; for instance, a project that has the place “Rome” may wish to match to Rome in the Pleiades database¹⁴ to get geospatial coordinates and access any additional information related to Rome (like coins, artifacts, and texts) related to Rome from other ancient LOD projects.⬈#p17

There are many different methods to perform this matching. One is to go line by line in your database/spreadsheet and match entries to an external provider by hand through a visual search interface. This is a laborious process and is not recommended for projects that have more than a few dozen entries. Another option is to programmatically match the names with a data source through a form of “fuzzy matching” where names, or partial names, are matched to an external LOD database. This can take the form of a simple script, or a more complex database query. If the external data has a geospatial component this process can be aided by setting spatial parameters: for example, if you know all of the data in your project is in the Eastern Hemisphere, you could automatically reject any matches that occur in North and South America. Depending on the data contained within a project and an external LOD source such matches could be refined even further, by restricting the data type (only matching people records, only matching places that are settlements, etc.), date range, or any other data attribute. The results of any reconciliation then need to be checked by hand for accuracy; even with refined data controls, there will still be false-positive and false-negative matches in any data set.⬈#p18

An exciting new tool that greatly aids this process is Recogito, created by the Pelagios Project.¹⁵ Using an expanding selection of geospatial gazetteers, Recogito allows a user to upload a text file or spreadsheet (in .csv format), then performs automatic reconciliation to discover place names in the text and match them with its collection of gazetteers, which are then presented in the program’s interface. The matches suggested by Recogito can be accepted or rejected by the user, and the interface allows for refining the results, conducting your own searches, or discovering/tagging entities by hand. It must be stressed that this process is not perfect; Recogito may suggest places which are incorrect matches, be unable to find a place name in its system, or fail to recognize a name at all. Such entries may need additional linkages outside of Recogito to other LOD projects, which may be a laborious process. To facilitate this, Recogito presents its results both as a selection of downloadable files (in .csv and .json form), and as an interactive geospatial map within its interface. ⬈#p19

Using and Publishing LOD

Once a project has data that has been aligned with a LOD resource, then a project is free to use and publish its newly enriched data, preferably under an open license to facilitate the use and reuse of its findings. For many projects in ancient studies, the goal of aligning data with LOD providers is to discover geospatial information in their data for use in maps. For users of the Recogito interface, this can be as simple as taking a screenshot of the mapping display of the application.⬈#p20

Most users want further customization of their maps or wish to get different information from the LOD provider. In this case, a project needs to consult the API specified by an individual project to access the desired data in the relevant format. As mentioned above, the Pleiades project has an API that returns place information in a well-documented data format, such as .json or .csv), that is supported by most modern GIS and web mapping applications, including ArcGIS, QGIS, and Antiquity À-la-carte.¹⁶ The resulting data could also be downloaded, transformed into other visualizations, or entered into a database, where any number of unique and interesting queries could be performed. The possibilities for using LOD are almost unlimited, as are the options for contributing back to the LOD ecosystem. ⬈#p21

Contributing a project’s data to the larger LOD world is a more complex process, which is somewhat simplified by the gazetteer approach advocated here. However, before any further work is done, a project first needs to secure a digital host that will allow for the creation of stable URIs. Due to the variability of IT infrastructure at the institutional level and the very real possibility that participants could change institutional affiliations, this should almost certainly not be tied to a personal website or an institutional address that is somehow based on a participant's name or other institutional identifiers. As a result, it is best practice for a digital project to secure an external domain name (my-projectname.org, etc.) through a registrar service, which generally offer highly reasonable rates. This domain can then be configured to point to wherever the data is hosted, making my-projectname.org stand on its own, so that should the project be transferred to another institution or project lead, the URIs will remain the same.⬈#p22

After securing a hosting solution, a project needs to ensure that each data record that is linked to another LOD resource have its own landing page on the web. For example, if you have a record with an ID of cicero0000002 that links to the Pleiades page for Rome, then a URI like my-projectname.org/cicero0000002 should resolve as a page that presents some information on the record and its linkage to Rome. This can be as simple as a textual description or as complex as a mini-application with maps, texts, and other features. To be a completely integrated into the LOD world, there should be an option to return a machine-actionable response for each data record; ideally something like my-projectname.org/cicero0000002/json would return a .json representation of your data, while my-projectname.org/cicero0000002/rdf would return the data formatted as RDF. The Pleiades project provides a perfect illustration of this concept; https://pleiades.stoa.org/places/423025 leads to the landing page for Rome, generated from the Pleiades database, while https://pleiades.stoa.org/places/423025/json and https://pleiades.stoa.org/places/423025/rdf point to .json and .rdf representations of the data. These pages do not need to be created by hand, and for most sites they can be generated as requested with a simple php script that reads elements of the database, then formats and displays the results in the desired manner.¹⁷ The most important aspects of this process are creating pages for each record that not only present a human-readable page, but an option to access .rdf or .json representations. ⬈#p23

The RDF format is one of the foundational technologies of the LOD movement which allows for data interchange. RDF, or Resource Description Framework, is a model for describing metadata, or data about data. RDF is used to represent information about web resources in a subject→ predicate→ object format, otherwise known as triples. The subject is the resource being described, the predicate is a term (often itself defined in a URI)¹⁸ that describes the relationship, and the object is what the subject is referencing.¹⁹ To use our example above, the statement “Abydos → subordinate → The Seleukid Kingdom” is a triple, where Abydos is the subject, “subordinate” is the predicate, and the Seleukid Kingdom is the object. With a slight vocabulary change (subordinate to “part of”), this could be expressed as URIs like <https://myproject.org.abydos>, <https://pleiades.stoa.org/vocabularies/relationship-types/part_of_admin>, <https://pleiades.stoa.org/places/45635759>. Data prepared using the gazetteer approach advocated above already takes the form of entity → relationship type→ other entity, so the creation of RDF linkages can be a largely automated process. ⬈#p24

Once all the linkages are modeled as RDF, they are placed in a “dump file” which can be read by a parser or sent to a project like Pelagios Commons, which aggregates different projects and their linkages to each other.²⁰ There are a plethora of different vocabularies and ontologies for the various predicates and formats that are acceptable to different research and study domains. For projects dealing with the ancient world, the Linked Ancient World Data Institute/Initiative (#lawdi on Twitter) resulted in a data ontology that assists with the creation of RDF triples, and is available under open licensing²¹ In addition, Pelagios Commons produced an excellent guide on how to format RDF data so a project can join the larger LOD community.²² Finally, new development work in the Big Ancient Mediterranean project (BAM) is focused on creating an “out of the box” solution that will automatically generate both a directory structure and RDF files for connecting most projects to the larger LOD ecosystem.⬈#p25

The ever-increasing number of LOD projects, coupled with the increasing accessibility of tools and methodologies to create and contribute LOD marks an exciting new shift in scholarship. By emphasizing the relationships of data and shared resources, projects that embrace LOD enter into a collaborative space where the goals of openness and connectivity are leading to exciting new discoveries.⬈#p26

References

Berman, Merrick Lex, Ruth Mostern, and Humphrey Southall. “Introduction.” In Placing Names. Enriching and Integrating Gazetteers, edited by Merrick Lex Berman, Ruth Mostern, and Humphrey Southall, 1–11. Bloomington: Indiana University Press, 2016.⬈#reference-1

Blaney, Jonathan. “Introduction to the Principles of Linked Open Data.” Programming Historian, May 7, 2017. https://programminghistorian.org/en/lessons/intro-to-linked-data.⬈#reference-2

Bodard, Gabriel, Hugh Cayless, Mark Depauw, Leif Isaksen, Faith Lawrence, and Sebastian Rahtz. “Standards for Networking Ancient Person Data: Digital Approaches to Problems in Prosopographical Space.” Digital Classics Online, 2017, 28–43.⬈#reference-3

Cayless, Hugh A. “Sustaining Linked Ancient World Data.” Digital Classical Philology: Ancient Greek and Latin in the Digital Revolution, 2019, 572–004.⬈#reference-4

Elliott, Thomas, Sebastian Heath, and John Muccigrosso, eds. Current Practice in Linked Open Data for the Ancient World. ISAW Papers 7. New York: Institute for the Study of the Ancient World, New York University, 2014. http://dlib.nyu.edu/awdl/isaw/isaw-papers/7/.⬈#reference-5

Horne, Ryan. “Beyond Lists: Digital Gazetteers and Digital History.” The Historian, March 10, 2020, 1–14. https://doi.org/10.1080/00182370.2020.1725992.⬈#reference-6

———. “Mapping Power: Using HGIS and Linked Open Data to Study Ancient Greek Garrison Communities.” In Historical Geography, GIScience and Textual Analysis: Landscapes of Time and Place, edited by Charles Travis, Francis Ludlow, and Ferenc Gyuris, 213–27. Cham: Springer International Publishing, 2020. https://doi.org/10.1007/978-3-030-37569-0_13.⬈#reference-7

Isaksen, Leif, Rainer Simon, Elton TE Barker, and Pau de Soto Cañamares. “Pelagios and the Emerging Graph of Ancient World Data,” 197–201.⬈#reference-8

Latif, Atif, Muhammad Tanvir Afzal, Patrick Hoefler, Anwar Us Saeed, and Klaus Tochtermann. “Turning Keywords into URIs: Simplified User Interfaces for Exploring Linked Data.” In Proceedings of the 2nd International Conference on Interaction Sciences: Information Technology, Culture and Human, 76–81, 2009.⬈#reference-9

May, Keith, Ceri Binding, and Doug Tudhope. “Barriers and Opportunities for Linked Open Data Use in Archaeology and Cultural Heritage.” Archäologische Informationen 38 (2015): 173–84.⬈#reference-10

Mostern, Ruth, and Humphrey Richard Southall. “Gazetteers Past: Placing Names from Antiquity to the Internet.” In Placing Names: Enriching and Integrating Gazetteers. Bloomington: Indiana University Press, 2016.⬈#reference-11

Rath, Linda L. “Low-Barrier-to-Entry Data Tools: Creating and Sharing Humanities Data.” Library Hi Tech, 2016, 268–85.⬈#reference-12

Talbert, Richard J. A., and Roger S. Bagnall. Barrington Atlas of the Greek and Roman World. Princeton: Princeton University Press, 2000.⬈#reference-13

Notes

¹ Linda L. Rath, “Low-Barrier-to-Entry Data Tools: Creating and Sharing Humanities Data,” Library Hi Tech, 2016, 268–71.⬈#footnote-1

² See the papers in Thomas Elliott, Sebastian Heath, and John Muccigrosso, eds., Current Practice in Linked Open Data for the Ancient World, ISAW Papers 7 (New York: Institute for the Study of the Ancient World, New York University, 2014), http://dlib.nyu.edu/awdl/isaw/isaw-papers/7/; Gabriel Bodard et al., “Standards for Networking Ancient Person Data: Digital Approaches to Problems in Prosopographical Space,” Digital Classics Online, 2017, 30–31; Hugh A Cayless, “Sustaining Linked Ancient World Data,” Digital Classical Philology: Ancient Greek and Latin in the Digital Revolution, 2019, 37–42.⬈#footnote-2

³ Leif Isaksen et al., “Pelagios and the Emerging Graph of Ancient World Data” (Proceedings of the 2014 ACM conference on Web science, ACM, 2014), 197–201.⬈#footnote-3

⁴ Tim Berners-Lee, “Linked Data,” W3 Design Issues, 2007, http://www.w3.org/DesignIssues/LinkedData.html.⬈#footnote-4

⁵ See https://creativecommons.org/choose/ and https://rightsstatements.org/page/1.0/?language=en for examples of open and restricted data licenses.⬈#footnote-5

⁶ Ryan Horne, “Mapping Power: Using HGIS and Linked Open Data to Study Ancient Greek Garrison Communities,” in Historical Geography, GIScience and Textual Analysis: Landscapes of Time and Place, ed. Charles Travis, Francis Ludlow, and Ferenc Gyuris (Cham: Springer International Publishing, 2020), 215–17, https://doi.org/10.1007/978-3-030-37569-0_13.⬈#footnote-6

⁷ See http://viaf.org/viaf/102895066/#Marcus_Aurelius,_Emperor_of_Rome,_121-180 for the VIAF record for Marcus Aurelius;  https://pleiades.stoa.org/places/423025 for the Pleiades record of Rome.⬈#footnote-7

⁸ Merrick Lex Berman, Ruth Mostern, and Humphrey Southall, “Introduction,” in Placing Names. Enriching and Integrating Gazetteers, ed. Merrick Lex Berman, Ruth Mostern, and Humphrey Southall (Bloomington: Indiana University Press, 2016), 1–9; Karl Grossner, Krzysztof Janowicz, and Carsten Keßler, “Place, Period, and Setting for Linked Data Gazetteers,” Placing Names: Enriching and Integrating Gazetteers, 2016, 80–84; Horne, “Mapping Power: Using HGIS and Linked Open Data to Study Ancient Greek Garrison Communities,” 218.⬈#footnote-8

⁹ Mostern and Southall, “Gazetteers Past: Placing Names from Antiquity to the Internet,” 15–16.⬈#footnote-9

¹⁰ https://perio.do/en/⬈#footnote-10

¹¹ Talbert and Bagnall, Barrington Atlas of the Greek and Roman World.⬈#footnote-11

¹² https://pleiades.stoa.org/⬈#footnote-12

¹³ Ryan Horne, “Beyond Lists: Digital Gazetteers and Digital History,” The Historian, March 10, 2020, 45–47, https://doi.org/10.1080/00182370.2020.1725992.⬈#footnote-13

¹⁴ https://pleiades.stoa.org/places/423025 ⬈#footnote-14

¹⁵ https://recogito.pelagios.org/⬈#footnote-15

¹⁶ http://awmc.unc.edu/wordpress/alacarte/ ⬈#footnote-16

¹⁷ See Becker, Horne, and Talbert, “The Ancient World Mapping Center” for an example.⬈#footnote-17

¹⁸ Atif Latif et al., “Turning Keywords into URIs: Simplified User Interfaces for Exploring Linked Data,” in Proceedings of the 2nd International Conference on Interaction Sciences: Information Technology, Culture and Human, 2009, 76–78.⬈#footnote-18

¹⁹ Keith May, Ceri Binding, and Doug Tudhope, “Barriers and Opportunities for Linked Open Data Use in Archaeology and Cultural Heritage,” Archäologische Informationen 38 (2015): 117–18; Jonathan Blaney, “Introduction to the Principles of Linked Open Data,” Programming Historian, May 7, 2017, https://programminghistorian.org/en/lessons/intro-to-linked-data; https://www.w3.org/TR/rdf-primer/; https://www.w3.org/RDF/; https://en.wikipedia.org/wiki/Resource_Description_Framework.⬈#footnote-19

²⁰ http://pelagios.org/⬈#footnote-20

²¹ https://github.com/lawdi/LAWD⬈#footnote-21

²² https://github.com/pelagios/pelagios-cookbook/wiki/Pelagios-Gazetteer-Interconnection-Format⬈#footnote-22