About

Why Inscriptions?

The Inscriptions of Israel/Palestine project seeks to collect and make freely accessible all of the previously published inscriptions (and their English translations) of Israel/Palestine from the Persian period through the Islamic conquest (ca. 500 BCE – 640 CE). Epigraphy is the study of such inscriptions, defined as texts written on durable materials (except for coins, which falls under the academic category of numismatics). There are about 10,000 of these inscriptions, written primarily in Hebrew, Aramaic, Greek and Latin, by Jews, Christians, Greeks, and Romans. They range from imperial declarations on monumental architecture to notices of donations in synagogues to humble names scratched on ossuaries, and include everything in between.

These inscriptions are an invaluable resource for historical investigation, for they provide information that is frequently not available in the extant literary texts. Recently, for example, scholars have used these inscriptions to:

  • Reconstruct the ancient Roman road system throughout Israel/Palestine, thus revising our understanding of trade routes and the economy;
  • Investigate the involvement of the Roman government in municipal building projects;
  • Revise our understanding of the Bar-Kokhba Revolt, suggesting that the revolt was far more serious than we previously thought;
  • Recover the role (and perhaps even voices) of women in Jewish and Christian communities – voices that otherwise are silent in the literary record;
  • Provide insight into linguistic use and change in the area.

Some examples of the kind of information that inscriptions provide about the ancient world can be found on our Stories page. Please take a look and tell us what you think!

Project Description and History

The primary goals of the project are:

  • To make these inscriptions, which have been published in a variety of venues, publicly accessible in a way that would be useful for both scholars and the general public;
  • To stimulate interest in the inscriptions and, more generally, study of the ancient world;
  • To create a platform to experiment with open-source commentaries;
  • To create a platform that will allow for deeper machine-automated analysis of our data;
  • To contribute toward creating a wider web ecosystem (Linked Open Data) that will allow for the linking and bundling of data dealing with the ancient world.

Inscriptions of Israel/Palestine is an ongoing project at Brown University. IIP has been online at its present location since 2002 and was among the first freely-accessible online databases of inscriptions. It has been generously supported by the Center of Digital Scholarship and the Goldhirsh-Yellin Foundation.

An “inscription” is writing on durable material (excepting coins). At present, we know of some 10,000 relevant inscriptions corresponding to the rough parameters of this database. These inscriptions are mainly in Hebrew, Aramaic, Greek, and Latin, although inscriptions may feature other languages as well. The inscriptions have been written by Jews, Christians, and traditional Greeks and Romans (i.e., “pagans”). Published hither and yon in small collections or even individually in journal articles, these inscriptions have never been fully collected. To compound the problem, many of the actual stones and mosaics upon which the older publications were made are no longer extant, and scholars have shown that some of the extant inscriptions were previously misread or misinterpreted.

Despite hosting some of the same data, the Inscriptions of Israel/Palestine is a fundamentally different project. Following a long epigraphic practice that differentiates between new editions (e.g., CIIP) and collections of previously published inscriptions, we seek to gather inscription data into a single digital repository which will increase access to these important materials and make them more useful to scholars and the general public by virtue of their digital existence.

Over the past two decades, a project to re-edit these inscriptions and present them in print form, the Corpus Inscriptionum Iudaeae/Palaestinae (CIIP), has been underway. There is currently no plan to allow free access to the data of the CIIP. We have been rebuffed repeatedly in our attempts to find areas in which we might collaborate.

The CIIP editors have asked us not to use their work or provide their corpus numbers in our own database. While we do not believe that they have the legal right to prevent this, we are presently honoring their requests out of a sense of scholarly collegiality.

The project began in 1996 at the Institute for Advanced Digital Technology in the Humanities at the University of Virginia as a prototype under the name “Inscriptions of the Land of Israel.” This prototype has since been decommissioned. We originally designed a structure for our data in Standard General Markup Language (SGML). Much of this structure underlies the present Epidoc standard (in XML) which we and many other digital inscription projects now share.

The project moved to Brown University in 2002, and soon went into production under the auspices of the Scholarly Technology Group, now reorganized as the Center for Digital Scholarship, a unit of the Brown University Library.

Data

Our texts are, at present, all drawn from publications (and all are cited). We occasionally make minor corrections, but ultimately the readings are presented “as is.” For research and teaching purposes, we highly recommend consulting the original publication or its republication in CIIP. In time, we hope to develop IIP into a platform that accepts original contributions of inscriptions and their images.

We want our data to be used and reused. We have tagged our data (see below) in a way that maximizes its visibility for automated processes. Our data is freely available for download through our API (see below) and through Github. Our data are also accessible via the EAGLE Network and we are partnering with other online sites such as PelagiosTrismegistos, and the Portal of Epigraphy, Archaeology, Conservation, and Education on Jewish Funerary Culture.

Archiving and Preservation

Our data is tagged with an eye toward linking. Thus, the native XML files do not stand alone – they contain links, for example, to our bibliographic database. Our archival XML files, on the other hand, are meant to stand alone. These files are located in the Brown Digital Repository (accessed here), which is updated with new inscriptions periodically. We documented our archiving strategy in a published paper.

Encoding and Process

Each inscription receives its own XML file which has the same name as the inscription ID. Our encoding follows the Epidoc Guidelines.

Following these guidelines, each inscription file has four major parts:

  • Header: This section contains all the metadata, or information about the inscription. This includes, when available, a description of the inscription; the object type and material on which it is written and how it is written; the inscription’s date; its place of discovery and present location; its genre and “religion”; its dimensions; and encoding information and links to images.
  • Diplomatic transcription: This section contains the literal transcription of the writing. Greek and Latin inscriptions were written entirely in uppercase letters and frequently do not have breaks between words. This is a simple copy of what is on the stone, with all of its gaps, damage, etc., indicated.
  • Edited transcription: This is where the editor reconstructs and restores the inscription, as necessary, in its original language. Breaks between words are provided and corrections (to, for example, misspelled words) are made.
  • English translation: We try to provide a translation into English for all inscriptions.

Given the complexity of the data and the different languages (with Hebrew being read right-to-left), we have created a guide for data entry (to be used with our oXygenXML framework – see below) located here.

The transcriptions of the inscriptions in their original languages follow the Leiden conventions. These conventions standardize the symbols and punctuation used to represent the text. For example, text inside brackets encloses text which an editor assumes was on the stone. Text inside parentheses are editorial additions, such as the expansion of an abbreviation. The list of Leiden conventions, with their equivalent encoding (which is derived from the TEI, or Textual Encoding Initiative), can be found here.

Vocabularies and Linked Data

In order to facilitate searching, we have standardized some of the vocabularies. In particular, the entries for language; type of inscription; physical type; and religion have controlled vocabularies. We are working on standardizing the “figures” as well.

A note on the use of the category “religion.” Inscriptions, of course, do not have “religions,” although those who commission them, those who are mentioned in them, and those who carved them might. Moreover, we have a problem categorizing those who are sometimes referred to as “pagan”; this is a pejorative term used by Jews and Christians which lumps together a large set of diverse beliefs and devotional practices. We use the category of “religion” with ambivalence because it is familiar and can be useful to scholars: we attribute a “religion” to inscriptions which have familiar religious symbols or other indications of belonging to such a community. Instead of attempting to create a taxonomy of different Greek and Roman religious groups we lump those together as “Other.” This is an imperfect solution and we would welcome other ideas for categorization.

Our data contain information that facilitates linking. Primarily:

  • Geographical linking through the Pleiades project. All inscriptions have Pleiades IDs for their location and can be linked to all other data with the same geographic ID.
  • Object linking through the Getty Art and Architecture Thesaurus. All objects, such as an altar or a mosaic, contain a unique identifier. This too allows for links across the web to similarly tagged objects.
  • Period linking through PeriodO. PeriodO URIs are included in our data files. This will allow consolidation of all data from across the web based on chronological period.

Entering Data

Our encoders use the latest version of the program oXygen XML for data entry (although after some updates we have found the need to use older versions due to difficulty handling right-to-left languages). After installing the program on their own machines, our encoders configure it to work with our own custom designed framework. Instructions for installation can be found here.

Our guide for entering inscriptions is here.

Bibliography

Following practices described in the Epidoc Guidelines, IIP has been maintaining bibliographic entries in a master bibliography and referring to these from individually encoded inscriptions. We feel that bibliographic data entry and editing must be collaborative, web based, and unambiguous. In an earlier stage of the project, we managed the bibliography with a customized SQL database which provided useful features such as controlled lists of journal abbreviations. When the project upgraded in 2013, we decided to replace the custom bibliographic database with Zotero. Zotero does not require maintenance on our part and has a versatile API which allows us to access citations directly when displaying an inscription in our interface. IIP assigns ID numbers to bibliographic entries, following the form [IIP-000], and uses the ID to reference a citation. Zotero also assigns ID numbers to bibliographic entries. These are automatic and function as database keys but are not part of the citation data. Thus, we store the IIP ID in the Zotero “Loc in Archive” or “Extra” field, on the premise that it is our project catalog number. To enable the Zotero API to retrieve a particular citation, we also save the IIP ID as a Zotero tag for each entry: the Zotero API can only access tags and a restricted number of bibliographic fields. We do not convert our bibliography to TEI in order to integrate it into our inscription files. The formatted citations the Zotero API generates using the Citation Style Language (CSL) an open language used by a variety of citation managers, are sufficient. A more complete explanation of how we use Zotero is available here.

We feel that our choice of an external database, (particularly Zotero, which is widely used; allows for collaboration; and can host a re-useable, standalone bibliography of sources for inscriptions) is an efficient means of working with different types of material and applying the tools most appropriate for each.

Workflow and Organization

Encoders create their files in a shared Drive folder. Each encoder has his or her personal subfolder, and within each of those is another sub-folder labeled “Finished”. Encoders add files to their “Finished” sub-folder when they complete their work.

Periodically, the Project Manager checks the files in the “Finished” folders. When deemed satisfactory, files migrate to a sub-folder labeled “Finished Inscriptions,” after which the Technical Director uploads these approved files to the Github repository. These are then synced to the repository on the production machine.

All inscriptions are marked with a status: “Approved,” “To Approve,” or “To Correct.” Inscriptions marked “To Approve” are uploaded to the production machine. The Project Director checks each of these files and either approves the file (at which point a file becomes visible to the public) or marks it “To Correct” if it needs modifications.

Technical Information

This website combines three different platforms. The actual inscriptions are processed with Apache Solr, and our front end uses Django. All our code is available for free download on Github. The bibliography is managed by Zotero. All other pages (such as this one) are managed through a WordPress site.

API

An API (Application Programming Interface) is a piece of software that makes it possible for two programs to communicate. IIP provides a web API, which means that it is possible to issue a series of special URLs that will return IIP information as data – in XML or in Json format – instead of an attractive and human-readable web display. These formats make our corpus data reusable by other projects and programs. For example, in the case of IIP you might use our API instead of manually searching for inscriptions if you wanted to gather statistics or display the inscriptions geographically on a map (like we do!). In certain cases, you may also have access to more information through an API than you would otherwise. For example, in building a map you would use our API to gather geographic coordinates, information that each inscription has but that isn’t generally displayed when you look at an inscription on our website. APIs are amazingly useful — for more information and a general introduction, see the documentation provided by the Digital Public Library of America.

The IIP API connects you to our collection of inscription data by sending queries to the Solr index powering our search interface. Simply put, the API asks Solr for information and Solr returns it in a structured format that is easy to re-use. For more detail, or if you’re interested in using Solr for your own project, see the Solr documentation.

The queries that you send through our API will rely on IIP keywords and metadata and will return IIP metadata and IIP IDs (each inscription in the database has a unique ID). The way you piece together the query you want has a standard format defined by Solr.

Accessing Specific Inscription Files

The inscription files themselves are XML files encoded using Epidoc and can be accessed in their XML form by appending the IIP ID to the URL https://library.brown.edu/cds/projects/iip/view_xml/ .

The IIP ID takes the form aaaa1111 or aaaa1111a (where a stands for an alphabetic character and 1 stands for a number). Please note that although the URL path may change, the IIP ID will not.

For example, the following URL will link to the XML file of inscription jeru0237: https://library.brown.edu/cds/projects/iip/view_xml/jeru0237/

Using the API to Search

In order to request information using our API, you’ll need to construct the exact URL for the search parameters you want. The URL will always start the same way: http://library.brown.edu/search/solr_pub/iip/?

From there, you’ll append a series of Solr parameters separated by the ampersand &. Parameter values are added following an equals sign =. Most of these parameters are generally available to all Solr queries and not specific to IIP content. For example, API queries can return xml or json formats, depending on the value of the wt flag: wt=xml or wt=json. You can specify how many results you want returned using start=0&rows=100 – in this case, you are requesting the first 100 hits . The q parameter lets you construct content-specific IIP queries (see example #2 and the chart below). A nicely compact summary of constructing Solr queries can be found here.

Some example queries:

  1. Find the first 100 inscriptions:
    http://library.brown.edu/search/solr_pub/iip/?start=0&rows=100&indent=on&wt=json&q=*

    The resulting web page is in the Json data format (wt=json). If you look at the results carefully, you will see Name-Value pairs that provide information derived primarily from the inscription metadata that is stored in the Epidoc Header.
  2. Find the first 100 inscriptions that are from the region “Coastal Plain”:
    https://library.brown.edu/search/solr_pub/iip/?start=0&rows=100&indent=on&wt=json&q=region:%22Coastal+Plain%22

    In this example, region is one of IIP’s facets, which means you can define a value for it using a colon and then use region:"Coastal Plain" as your value for the Solr parameter q. However, note that double quotes “” in the URL must be encoded as %22.
  3. You might be wondering how you would know that “Coastal Plain” is a possible value for the field region in the previous example — or how you know that region is a facet. Sometimes it is helpful to get information that is aggregated across the whole corpus, in order to then be able to formulate other queries that are based on specific details. This query will give you a list of all the region attributes that are used in the IIP corpus:

    http://library.brown.edu/search/solr_pub/iip/?start=0&rows=0&indent=on&facet=on&facet.field=region&wt=json
  4. And this query will give you a CSV list of our facets, some of which are also in the table below:
    https://library.brown.edu/search/solr_pub/iip/?q=:&start=0&rows=0&indent=on&wt=csv&facet

Funding

Over the years we have received generous funding from Brown University, especially through the Office of the Vice President of Research and the Program in Judaic Studies. We also receive technical and other infrastructure support from the Center for Digital Scholarship, a division of the Brown University Library. In the summer of 2017 the Dean of the College at Brown University funded an Interdisciplinary Team Undergraduate Teaching and Research Award which supported four undergraduate students’ full-time work on the project. The team members are noted on our Team page.

We currently receive generous funding from the Goldhirsh-Yellin Foundation. We are tremendously grateful for their support.

There is much that we would still like to do, including: the incorporation of more images; advanced tagging of data content; programming to allow for more analysis and visualization; the development of a portal displaying material culture from the Israel/Palestine region in antiquity; and the mounting of an international conference on the digital use of these inscriptions. For these tasks, though, we require additional funding.

If you are interested in contributing to or partnering with IIP, please contact us!

People

The Project Director (PI) is Michael Satlow (Professor of Religions Studies and Judaic Studies, Brown University). The Technical Director is Elli Mylonas. We have been fortunate over the years to have had many excellent people working on the project. See our Team page for more information.