Linguistic Text Database¶

The WIVU group in Amsterdam, led by Eep Talstra has crafted a linguistic database of the Hebrew Old Testament. It is the fruit of decades of work, still continuing.

The acronym WIVU is not officially known on the website of the Free University Amsterdam. But there is a current NWO project Data and Tradition. The Hebrew Bible as a linguistic corpus and as a literary composition, initiated by Eep Talstra, that continues the WIVU work. Oliver Glanz is associated with it.

The text with all its features is stored in a special database (EMDROS). This database supports a pragmatic subset of the query language QL, defined in [Doedens]. The subset is called MQL. EMDROS is a front-end on more conventional database technologies such as MySQL or SQLite.

Scholars use MQL queries to shed light on exegetical questions. It is possible to define quite sophisticated queries into text corpora, of which the Hebrew Bible is an example. These queries do not only mine the surface forms of the texts, but also the annotated features that have been added over time. Depending on the amount and detail of these features, the queries will yield a treasure of information, some of which will be fed into the text database in subsequent stages.

The WIVU database is included and integrated in Logos/SESB Bible study software.

SESB 3.0 also contains the Biblia Hebraica Stuttgartensia with text critical apparatus and linguistic WIVU database, plus the Biblia Hebraica Stuttgartensia: Workgroep Informatica Constituency Tree Analysis. The new WIVU database allow for a precise overview on how the single textual elements of a specific text passage are analyzed and hierarchically organized.

The WIVU database is not the only linguistically marked up database of the Hebrew Bible. To get a feel for how these databases are used, have a look at the Logos users’ forum.

While this approach is beneficial for analysis and interpretation, it poses challenges for sharing and tradition.

All these people that have bought their individual copies of the WIVU database, running their queries locally, what means for sharing their research do they have? Of course they can publish their results in scholarly articles, but how is one to get an overview of all the research that is going on?

Here we propose an approach where queries and their results are being visualised together with the canonical sources around which they have been constructed.

A first attempt by DANS for sharing the research done with the WIVU database using the EMDROS tool has resulted in a website hosted by DANS where interested people can experiment with MQL queries on a 2008 version of the WIVU database.

After that the WIVU database has been listed in an inventory of language resources by the European CLARIN project.

Open Annotation¶

Annotation is a pervasive research activity. It is the vehicle to enrich the data of science by the insights of experts. Annotations are often locked into the sytems that hold the data or the tools by which scientists perform their analysis. They might be using programs on their own personal computers, or work in an institutional environment around a database for which no public access has been set up. Where it is not possible to address the things that annotations are about, the annotations themselves cannot be shared in ways that do justice to their potential.

It is very fitting in our network age that there is an initiative to liberate annotations from their specialised contexts and share them freely on the web: the Open Annotation Collaboration (OAC).

The first task is to identify a general, abstract model to which all annotations conform. The OAC model talks about annotations as entities having one body and one or more targets. The body is what you say about the targets.

The second task is to employ web-technology to underpins that model. OpenAnnotation has chosen the emerging Linked Data framework (see also Linked Data Book) for giving web-reality to its abstract concepts of bodies, targets and what connects them together.

Additional information about an annotation can be supplied as well. This is metadata about an annotation. This is the place to tell who made the annotation, when, and why, in what context, referring to which publications, etc.

Metadata is not modeled by the OpenAnnotation Collaboration. It is attached to the annotation by usual Linked Data means.

Taking all this togehter means that: here we have a framework that is working on the most pervasive technology of the information age, with a nearly unlimited capacity of making connections where there used to be no connections. It is suited to express the results of much hard research work. Last but not least it has the promise of new discovery by new ways of visualising patterns.

Queries as Annotations¶

So much for annotations. What about queries into databases? Where annotations are rather passive, static comments, queries are active, dynamic forays into landscapes of data. What do the benefits of OpenAnnotation have to do with queries? If we want to preserve research output, we should preserve queries!

Yes, and here is how. First we must realise how difficult it is to preserve queries in their dynamic form. Several problems stand in our way:

• real-life databases are changing all the time. Running a query now will give different results from running a query tomorrow.
• software itself is difficult to preserve. The whole stack of <operating system - database management system - query language - publishing manager> is changing at such a rate, that if you do nothing special, the query that runs fine now, will not run at all in two years time.

Yet, when a scholar is grounding the conclusions of a journal article on the results of a query, it is important that there is some permanent record of the exact results. It matters less that the query cannot repeated exactly. It matters more that when the query is repeated, the differences with previous runs can be spotted.

Preserving the record of a query (and its results) is a whole lot different from preserving the capability of running that query with exactly the same results for the indefinite future. This record is not dynamic but static, not active but passive. So it makes sense to turn to OpenAnnotaion again and see what they can do for query records.

The central idea is:

a query on a text database can be preserved as an annotation to all its result occurrences in that database.

In the list below the exact correspondence between the annotation concept and the query(record) concept is shown, together with the WIVU database as an example.

Benefits of Queries-As-Annotations¶

Is it worthwhile to preserve queries as annotations? What can you do with it? Well, the best way to find out is to start building it and see what happens.

We (Eko and Dirk) have built a demo web application that shows the surface text of the WIVU database in the left column, and the relevant queries in the right column. A query is relevant if it has results occurring in the text of the left column. You can click on a query to highlight the actual results on the left.

When DANS built the DANS-WIVU website back in 2008, we used 22 real-life example queries. Now in 2012 we use a new version of the database, called BHS3, and we have adapted those 22 queries to the new datamodel. Yes, the data model has changed, most of the queries did not run out of the box.

Users of bible study software are familiar with searching (=querying). But it is just one direction of information that is usually supported: given the query, you get the results. What is more difficult to obtain, is: given text passages, what are the queries of which they are results?

This latter direction makes only sense if there is a set of queries that have a significant research value. Not every search command or query is equally valuable. It depends on the underlying research question, if there is one, the identity of the person/project that crafted the query, and associated publications. Queries-As-Annotations have the potential to make this network visible. And the source texts themselves are part of this network and provide access to it.

The present demo application lets scholars stumble upon each other’s research questions by showing the published queries, including metadata, next to their results.

If there is a significant amount of published queries, an interesting network of researchers, research questions, query instructions and text passages will be revealed.

Anchored Sources¶

The query-as-annotation idea is most easily implemented and most effective if the sources against which the queries are executed, are stable.

If they are not stable, the idea still works if the atomic elements in the sources are addressable by stable addresses.

If the addresses are not stable, the idea can still be put to work if we can translate addresses from one version to another.

This requirement can be summarised by saying that the sources should be anchored:

all atomic elements of the sources should have well-defined addresses.

In the WIVU case, the words are called monads and they have a sequence number in the whole corpus. We have used these sequence numbers as our anchors in for our demo application.

There are more versions of the Hebrew texts that collectively comprise the Old Testament. If we do not want to tie our queries to a specific version, several approaches could be followed. We could make databases for the individual versions, assign local monad numbers to the words, and then compute a mapping between the monad numbers in such a way that the numbers of corresponding words are mapped.

A radically other approach is to integrate all versions in a super-version. Each word will carry an extra feature, called version-membership, which specifies the versions to which the word belongs. If the addresses of the words are assigned in such a way that it is possible to add new words between existing words, than we can keep anchors stable even if new versions are discovered and added.

The query-as-annotation approach is suited also to this super version. Even if the assignment of words to versions is not stable, and follows the successive waves of scholarship, the words themselves have fixed addresses, and can be targeted by query records.

Independence of Analytical Tools¶

In order to show the query record, it is not necessary to preserve the analytical machinery in working order.

A positive consequence is that there is no brake on the continuous evolution of analysis tools. There is no legacy to be carried around. When showing query results, it is not needed to show all the analytical features carried by the words in the database. That makes it easier to build web interfaces that are optimised for sharing research and discovering larger patterns.

Of course, it remains important to preserve the data of the analytical machinery, i.e. all the features and their organisation by the database. But we do not have to preserve them in a way that we can run the analytical tools on them. It is sufficient that the data is transparent en well-documented.

Transparent means: open to inspection, not hidden behind opaque binary formats. The tools that see through these binary formats may not exist anymore somewhere in the future.

Well-documented means that it will be clear to future users of the data what the features mean, what the quality of the value assignments are, and for what purposes the data have been collected and used.

Solution of Digital Preservation¶

Considering the field of biblical scholarship, the nature of the analysis that takes place, the kind of research results that are communicated, it can be concluded that we can do a good job in digital preservation of research data if:

• we use and preserve anchored sources
• we preserve static analytical data in trusted digital repositories
• build and maintain an Linked Data web of Queries-As -Annotations

It is not perfect, in that we will not be able to completely reproduce every detail of past research. But it is still good value to be able to see a well-documented, well connected track record of research questions and answers.

Components¶

Rendering Application¶

The web-application that renders the sources shows individual chapters of individual books of the Hebrew Bible.

The browser-screen is divided into a left, middle and a right column.

The middle column contains selection controls for books and chapters, and below that displays the selected chapter. The text is rendered in Hebrew characters, from right to left. This is the primary data, the source, and it is pulled out of a mysql database, called wivu.

The left and right columns contain annotations, which are pulled out of a different database, called oannot. This database has tables for bodies, targets and metadatarecords for annotations. It has a table for annotations as well. An annotation record consists of an identifier only; the body and its targets are connected to it by means of link tables.

The left column contains highlight controls for features. Features are annotations that have bodies of the form key = value, and they can be distinguished by other annotations through a field called type in the metadata record. The targets of a feature annotation are all the words that carry that feature-value.

The right column contains the queries that have results in the selected chapter. The results can be highlighted per query, and more information about the query can be shown on demand.

Data Statistics¶

Here is an overview of how many source data and annotations this application deals with.

Functionality¶

2013-05-02 Workshop Electronic Tools in Biblical Hebrew Research and Teaching¶

A workshop where the methods of Biblical research are demonstrated, a preview on new ways of sharing the results of those results is given. Eep Talstra, the retiring professor gives a concrete illustration of sorting, searching and simulation on the basis of the Hebrew Text database he and his group have developed. After the workshop his successor, Wido van Peursen takes over with his inaugural lecture “Grip op Grillige Gegevens” (getting to grip with capricious/raw data).

2013-05-01 SHEBANQ project starts¶

Today we had a kick-off of the CLARIN-NL project that aims to implement the idea of queries-as-annotations into a production system, running at DANS which acts as a CLARIN centre here.

2012-12-18 SHEBANQ project granted by CLARIN-NL¶

System for HEBrew text: ANnotations for Queries and markup is a 100 k€ project proposal for call 4 of the Dutch section of the European project CLARIN. With this project the Old Testament group at the VU University Amsterdam, lead by Wido van Peursen, and DANS will represent the renowned WIVU database in the Linguistic Annotation Format. It will then be possible to save meaningful queries on that database as (open) annotations. We will build a query saver as a web application. A project like this is important to get digital biblical scholarship out of the local computer systems into the clouds.

2012-10-29 Paper presented at the ASIST conference¶

Here are the slides. And here is the article in the proceedings (warning: this is a slow link, the result is a 6MB image). Much more convenient is our final submission, which is a searchable pdf.

2012-07-25 Paper accepted for the ASIST conference¶

With Charles van den Heuvel I submitted a paper ” Annotation as a New Paradigm in Research Archiving ” where we advertise new practices for archives in order to really support modern research. The showcases are the CKCC project and the Hebrew database. The paper has been accepted and will be presented on 29 October 2012 in Baltimore.

2012-03-26 Towards portable annotations¶

Version 3.0: Preparation for portable annotations. The targets in the texts can be addressed by the word sequence number in the WIVU text. Now the address consists of book-chapter-verse + local word sequence number, i.e. the sequence number in the verse. We prepared the Westminster version of the Hebrew Bible with the aim of displaying it together with the WIVU version, in such a way that words common to both versions have common addresses.

2012-03-19/20 Interedition Symposium at Huygens ING¶

Direct link to the program

(abstract accepted) (to present and enhanced demo compared to the one presented at Lorentz Workshop)

2012-03-14 Features as Annotations¶

Version 2.1: After a recent, internal bootcamp we have brought new features to the demo: features as annotations. The user can select a number features-value pairs and highlight them in a color of his choice.

2012-03-07 Ported to web2py¶

The demo has been ported to the convenient, python-based web2py framework. Ready to receive more functionality.

2012-02-06/10 Lorentz workshop¶

(encouragement to work further on ways of sharing research, see Lorentz Workshop, queries-as-annotations still stand, but the idea must be worked out more compellingly).

2012-01-30/02-03 DANS mini bootcamp: Eko and Dirk¶

Building a demo for the sole purpose of realising the query-as-annotation idea in a real research context. It is not optimised for performance, it has no security measures whatsoever, and the user interface is bleak. We await feedback and suggestions from the participants of the Lorentz workshop. Depending on that, we hope to improve and add and present an improved version on a following workshop. The demo and its documentation are hosted on a cloud server , hired by DANS.

2012-01-11/14 Interedition Bootcamp¶

Inspiration as to the content and the implementation of the query-as-annotation idea. Dirk participated in a Linked Data subgroup. We built services to automatically annotate place names in Arabic, Greek and English texts. This we did by looking up each and every word in the Geonames database. The hits were translated into Open Annotations.

Topic detection and modelling¶

Extracting topics from texts is as useful as it is challenging. Topics are semantic entities that may not have easily identifiable surface forms, so it is impossible to detect them by straightforward search. Topics live at an abstraction level that does not care about language differences, let alone spelling variations. On the other hand, if you have a corpus with thousands of letters in several historical languages, and you want to know what they are about without actually reading them all, a good topic assignment is a very valuable resource indeed.

There are several ways to tackle the problem of topic detection, and they vary in the dimensions of the quality of what is detected, the cost of detection, and the ratio between manual work an automatic work. Several of these methods have been (and are being) tried out in the Circulation of Knowledge Project a.k.a. CKCC* (References). See also a paper by Dirk Roorda (References), Charles van den Heuvel (References) en Erik-Jan Bos (References), delivered at the Digital Humanities Conference in 2010 (References) and a paper by Peter Wittek and Walter Ravenek (References) about the topic modeling methods that have been tried out (References).

Preserving (intermediate) results¶

manual keyword assignments

The purpose of the present article and demo is not to delve in topic detection methods. Our perspective is: how can we gather the results of work done and make it reusable for new attempts at topic modelling and detection? Or for other ways to uncover the semantic contents of the corpora involved?

At this moment, CKCC (References) has not obtained fully satisfactory results in topic modelling. But there are:

• results in automatic keyword assignments,
• manual assignments of topics in a subset of the corpus
• automatic topic detection on the basis of the LDA algorithm

The outcomes of this work are typically stored in databases, or bunches of files of type text or csv. They involve internal identifiers for the letters. They cannot be readily visualised.

I propose to save this work as annotations, targeting the corpus.

The interface¶

TKA (References) is a simple demonstration of what can be done if you store keyword and topic assignments as annotations. Here is an overview of the limited features of this interface. Bear in mind that very different interfaces can be built along the lines of this sources-with-annotations paradigm.

This interface is designed to show the basic information contained in the letters and the keyword/topic aasignments.

Keywords as Annotations¶

In the present case, keywords and topics are targeted to letters as a whole. So the granularity of the target space is really coarse.

For keywords, the modeling as annotation turned out to be a straightforward matter. A keyword assignment by an expert or algorithm corresponds to one annotation with the keyword itself as body, and the letters to which that keyword is assigned as the (multiple) targets. The author of the assignment is added as metadata.

Topics as Annotations¶

The mapping from topics to annotations is not so straightforward. Several alternative ways of modelling are perfectly possible. The complication here is the confidence factor with which a topic is assigned to a letter. This really asks for a three way relationship between topics, letters and numbers, but the OAC (References) model does not cater for that. We could work around them by adding relationships to our annotation model, but that would defeat the purpose of the whole enterprise: packaging scholarship into annotations to make them more portable. So we want to stick to the OAC (References) model.

Here is a list of remaining options.

Annotations in Relational Databases¶

Here I discuss how the annotations have been modelled as relational databases.

Indeed, these annotations have not been coded into RDF, they have no URIs, so they do not conform to OAC (References). Instead, they have been modeled into relational database tables.

There are several reasons for this:

# the annotations should not be tied to specific incarnations of the sources # the annotations are to drive interfaces in different ways, depending on what it is that is being annotated

The main reason for 1. is that those sources are not yet publicly online, or if they are, they have not yet stable uris by means of which they can be addressed.

Because of 2. we need random access to the annotations with high performance. The easiest way to achieve that is to have them ready in a relational database.

Nevertheless, there is a sense in which we conform to OAC (References): the annotations reside in a different database than the sources do, and the link between annotations and targets is a symbolic one, not checked by the database as foreign keys. So the addressing of targets is very flexible.

This establishes modularity between sources and annotations, and the intended workflow to deal with real OpenAnnotations (References) is:

# if you encounter a set of interesting rdf annotations on a source that you have in your repository: import the rdf annotations into a relational database, and translate target identifiers into database identifiers; # if you want to export your own set of annotations to the Linked Data web: export the database annotations to a webserver, translating target identifiers to URIs pointing to your sources.

Data model for annotations¶

The datamodel for annotations containing topics and keywords is as straightforward as possible. Some observations:

#There are separate databases for topics, which act as bodies of the annotations, and for the annotations themselves. #Topics are symbolically linked to the annotation database, not by database-enforced foreign keys. #Topics do not have external ids, so the annotations link to them by means of their database id. This is a challenge if you need to export topics as web resources. #Bodies have structure: there are three fields: ##**bodytext** for bodies that are ordinary text strings, like keywords; ##**bodyref** for bodies that are database objects themselves; this field is meant to contain the id of the body object; the application is meant to ‘know’ in which table these objects are stored; ##**bodyinfo** additional information inside the body; here we use it for storing the confidence factor, which is a floating point number stored as a sequence of characters; ##there is no sharing of targets between annotations, the database model admits only one annotation per target. If we allowed target sharing, we would need an extra cross table between annot and target, which would burden all queries with a lot more inner joins. Whether efficiency suffers from or improves by this choice I have not investigated. In QFA (References) I have used target sharing, and it worked quite well in a corpus with nearly 500 000 targets. Especially the targets of the features there would have caused the target table to explode of sharing were not used. #The letters, which are the sources that are targeted by the annotations, are in a separate database as well. They carry ids given with the corpus. These are the ids that are used as the symbolic targets in the target table of the annotations. #There is no split between the annotations and their metadata. The reason for the latter integration is that the annotation machinery should have a decent performance. Most queries sift through annotations by metadata, so for this demo I chose a simple solution.

The main intention between these choices is to keep the interface between the annotation model and the real world objects that constitute the bodies and the targets, as free as possible from database-specific constraints. We want to use the model for more than one kind of annotation!

Data Statistics¶

Since performance is an important consideration, here are some statistics of the sources and annotations of TKA (References).

Not all annotations are equal¶

The annotation model is very generic, and many types of annotation fit into it. Here we saw several kinds of keywords and topics, each with different glitches. In the QFA (References) demo there are linguistic features as annotations and queries as annotations, which require completely different renderings.

So the question arises: what is the benefit of the single annotation model if real world applications treat the annotations so differently?

And: how can you design applications in such a way that they benefit optimally from the generic annotation model? Now that we have interfaces for at least three real world type annotations we are in a position to have a closer look, and to gather the lessons learned.

The benefits of a unified model¶

Metadata and Annotations¶

The OAC (References) model defines an annotation as something that is a resource in itself. That means that annotations can be the targets of other annotations (and probably of itself as well, but I do not see a use case for that right now), and that annotations can be linked to metadata. So metadata is not part of the OAC (References) model, but the fact that metadata on annotations is around, is well accomodated.

With metadata the divergence sets in. Concrete applications need metadata to filter annotations, but there is no predetermined model for that metadata. So here is a point where applications become sensitive to the specifics of the information around annotations. Or, alternatively, applications might discover the metadata of annotations, and make educated guesses as to the filtering of the annotations they want to display. Very likely this will so computation intensive, that a preprocessing stage is needed, in which the metadata that is around will be in fact indexed according to an application specific metadata model.

metadata fields in Queries/Features As Annotations

metadata fields in Topics As Annotations

Let me conclude with an account of the metadata that the TKA (References) and QFA (References) demos needed to function. See the screenshots on the right.

Type and Subtype

One of the most important characteristics is the type of the annotation.

In QFA (References) it tells whether the annotation expresses a (linguistic) feature, or a query and its results. As features and queries are displayed differently, it is important to be able to select on type and subtype, and to do it fast (that’s why there is an index on these columns).

In TKA (References) there is a field metatype which is used to distinguish between keywords and topics, and a field metasubtype which distinguishes between manual annotations and automatic annotations, i.e. the results of algorithms.

Provenance

In a world where annotations are universal carriers for scholarship, provenance metadata is of paramount importance. Without it, it would be very difficult to assess the relevance and quality of the annotations that one discovers around a resource. For QFA (References) there are, even in demo setting, a handful of fields: researcher, research question, date_created, date_run, publications.

A typical use case for QFA (References) is this: a researcher in the future comes across some targets of a query annotation by way of serendipity. He navigates to the body of the annotation, which is a query instruction. Very likely he has no means at hand to run that query, but he can look up the other query results. Apart from that he is able to see why this query has been designed, which question it answers, and who has done it and when, and to which publications this has lead. Using this information he can find related research questions, queries and results. In this way a quite comprehensive picture op past and ongoing scholarship around these sources can be obtained, without maintaining the engines that once run all those queries.

Among the possible use cases for TKA (References) is this one: in order to get algorithmic access to the semantics of all those tens of thousands of 17th century letters various methods are tried to get keywords and topics. Some methods yield keywords in purely automatic ways. Other methods require training by manual topic assignments by experts. The methods must be tested against test data. Parameters will be tweaked, outcomes must be compared. Precision and recall statistics indicate the success of those methods. Yet something is missing: a view on all those keyword/topic assignments in context, where you can switch on and off different runs of the algorithms, and where you can assess the usefulness of the assigned labels and hit on the obvious mistakes.

If all topic/keyword assignments are expressed as annotations, than it is the provenance metadata that enables the application to selectively display interesting sets of annotations.

Even more importantly, there is real gold among those annotations, especially the manual ones by experts. They can be used by other projects in subsequent attempts to wrestle semantic information from the data. Good provenance information combined with real portability of annotations will increase the usefulness of those expert hours of manual tagging.

Real applications driven by annotations¶

How do real applications utilize the common aspects of the annotation model, and how do they accomodate the very different roles that different kinds of annotations play in the user interface? Let me share the experience of designing demo applications driven by annotations.

Differences¶

The differences are there where the abstract annotation model hits the reality of the use cases: the contents of the bodies, the addressing of the targets, the modeling of the metadata. Also the visualisation of the annotations differs.

Bodies

Bodies tend to have structure. A choice must be made whether to express that stucture in plain text, or to use database modeling for it. Before discussing this choice, let me list what the bodies look like in each case.

Kind of annotation	form of body	interpretation of annotation
Query	plain text: statement in a query language	targets are results of query
Feature	plain text of the form: key*=*value	targets are source fragments for which the feature key carries the value
Keyword	plain text of the form: keywordstring	targets are letters in which keywordstring occurs
Topic	database identifier in dedicated database of topics	targets are letters to which the identified topic applies with a confidence factor
Topic	confidence factor which is a real number coded as plain text	targets are letters to which the identified topic applies with a confidence factor

Remember that topics are collections of words, where each word has a certain relative weight in that topic. This asks for plain old database modeling.

There are conflicting interests here. In our annotation model we want to accomodate annotations in their full generality. Yet the application will specialize itself around a few annotation types that are known beforehand. If the application does not specialize, its performance will not be up to the task. Yet we have tried to keep the structure of a body as generic as possible. The features case, for example, is a plain text body, but there is in fact the additional structure of keys and values.

But the topics case really would be awkward if we had to spell out the complete topic information for each annotation with that topic in the body. So we decided to give each body three content fields:

• bodytext for plain text content
• bodyref to contain an identifier pointing to an object in a(nother) database, without foreign key checking
• bodyinfo a bit of extra info of the body on which the application may search

By abstaining from database constraints for bodyref we keep the model still very versatile. If the application knows the database to look in, the body object can be found. Hence annotations with bodies that refer to arbitrary databases and tables can be accomodated without changes to the database model.

By having an extra bodyinfo field of type string, we can separate body information in two fields on which the application can efficiently perform filter operations. In the case of topics, the bodyinfo stores the confidence number. If topic bodies had been stored as plain text including this number, it would have been very inefficient to select topics regardless of this confidence number.

Probably the best option, but one that we have not implemented, is: express the confidence as body of a new annotation that targets the absolute topic assignment annotation.

The OAC (References) model is really concise, and there are many ways to link to additional data, which results in quite of few options to pursue when one maps topics onto annotations.

Targets

target model for queries/features

target model for keywords/topics

Targets are resources or fragments of resources. As there is no standard way to refer to fragments of resources, we decided to always use a string to denote a target. This is the field anchor, of type string. We do not fill this field with database identifiers, but with identifiers that come from the sources themselves.

As an illustration: before version 3.0 of QFA (References) we used the absolute word number of a word occurrence. The first word of the Old Testament got number 1, and the last word number 430156. Now the first word gets anchor gen_001:001^001 and the last word gets anchor ch2_036:023^038. These anchors refer to books, chapters and verses and specify a word in a verse by their order number in that verse. The last word of the bible is the 38th word of the 23th chapter of the second book of Chronicles.

In TKA (References) only letters as a whole are anchored. For example, the letter of the example screenshot above has identifier 1139a, which is clearly not a database identifier.

An obvious difference between the target model for queries/features on the one hand and keywords/topics on the other hand is that the former allow target sharing between annotations. This is only a pragmatic issue with no semantic consequences and not too much performance impact. The model without target sharing is definitely simpler, and fewer inner joins are needed to get from target to body, for instance. The model with target sharing does not enforce it. Even if targets are shared, there is the need for a record in the cross table annot_target per target per annotation. So this will only gain something if the anchor field requires a significant amount of text per anchor.

Metadata

In fact, we have very little metadata, most of it unstructured. So we can afford to store it in a separate table (in the queries/features case) or even in extra fields in the annotation record itself. As soon as the relevant metadata becomes more complex, it is better to separate it thoroughly from the annotations, and make the connection purely symbolic, like we did with the connection between target anchors and the targets themselves.

Visualisation

Each type of annotation asked for different visualisations on the interface. The common aspect is that targets are highlighted, and bodies are displayed in separate columns, one for each (sub)type of annotation. The differences between queries and features and topics and keywords are: #for queries only those bodies are shown that have targets in the rendered part of the source; whereas for features all features/value pairs are selectable, regardless of their occurrence in the displayed passage of the source; #query targets are highlighted whereas features targets are highlighted according to display characteristics under user control; #queries and features have targets at the word level whereas keywords and topics are targeted at the letter level, but the individual occurrences are highlighted by means of a generic javascript search in element content, which is less precise!

Exercise¶

A first exercise is to get all nomina sacra of the main text. The following sql query will do the trick:

use jude;
select
     layerdata.address,
     layerdata.glyph,
     source.name,
     passage.name
from
     layerdata inner join source
on layerdata.source_id = source.id
     inner join passage
on layerdata.passage_id = passage.id
     inner join layeron layerdata.layer_id = layer.id
where
     layer.name = 'SRC-NS'
order by
     passage.id,
     source.name,
     layerdata.address

and the initial part of the result is:

Collation with CollateX¶

At the moment I am at the stage that I have seen a reasonably good collation by CollateX (References), even without using the detected transpositions.

Here is a sample of the collation (in a pretty-printed form):

0142           |ιουδας|       |ιυ     |χυ    |                    |       |     |       |δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θω            |πρι        |           |       |      |       |ηγιασμενοις        |και         |ιυ          |χω     |     |       |τετηρημενοις|κλητοις  |
0251           |█     |       |       |      |                    |       |     |       |      |       |  |       |        |       |      |              |           |           |       |      |       |                   |            |            |       |     |       |            |         |
0316           |█     |       |       |      |                    |       |     |       |      |       |  |       |        |       |      |              |           |           |       |      |       |                   |            |            |       |     |       |            |         |
049            |ιουδας|χυ     |ιυ     |      |                    |       |     |       |δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θω            |πρι        |           |       |      |       |ηγιασμενοις        |και         |ιυ          |χω     |     |       |τετηρημενοις|         |
056            |ιουδας|       |ιυ     |χυ    |                    |       |     |       |δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θω            |πρι        |           |       |      |       |ηγιασμενοις        |και         |ιυ          |χω     |     |       |τετηρημενοις|κλητοις  |
1              |ιουδας|       |       |      |                    |       |ιησου|χριστου|δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |
1003           |ιουδας|       |       |      |                    |χριστου|ιησου|       |δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |
101            |ιουδας|       |       |      |                    |χριστου|ιησου|       |δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |
102            |ιουδας|       |       |      |                    |       |ιησου|χριστου|δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |
1022           |ιουδας|       |       |      |                    |χριστου|ιησου|       |δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |
103            |ιουδας|       |       |      |                    |       |ιησου|χριστου|δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |
104            |ιουδας|       |       |      |                    |χριστου|ιησου|       |δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |και   |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστου|τετηρημενοις|κλητοις  |
1040           |ιουδας|       |       |      |                    |       |ιησου|χριστου|δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |
105            |ιουδας|       |       |      |                    |       |ιησου|χριστου|δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |
1058           |ιουδας|       |       |      |                    |       |ιησου|χριστου|δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |
1066           |ιουδας|       |       |      |                    |       |ιησου|χριστου|δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγιασμενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |
1067           |      |       |       |      |ιουδας              |       |     |χριστου|δουλος|αδελφος|δε|ιακωβου|τοις    |       |εν    |θεω           |           |           |       |      |πατρι  |ηγαπημενοις        |και         |            |       |ιησου|χριστω |τετηρημενοις|κλητοις  |

Collation with a new algorithm¶

Now we will research whether a bag-of-words master source is a workable idea. I just found a new way to link corresponding positions across variants. Still a lot of checking and cross-checking has to be done. Pending the verdict whether the new method yields good results, it is certainly an interesting experience to look at this data in completely new ways.

Here is an illustration first, it is the passage Jude verse 1, just one line of text, but in 560 variants.

Here is the source in just a few variants:

0142 = ιουδας ιυ χυ δουλος αδελφος δε ιακωβου τοις εν θω πρι ηγιασμενοις και ιυ χω τετηρημενοις κλητοις
049  = ιουδας χυ ιυ δουλος αδελφος δε ιακωβου τοις εν θω πρι ηγιασμενοις και ιυ χω τετηρημενοις
056  = ιουδας ιυ χυ δουλος αδελφος δε ιακωβου τοις εν θω πρι ηγιασμενοις και ιυ χω τετηρημενοις κλητοις
1    = ιουδας ιησου χριστου δουλος αδελφος δε ιακωβου τοις εν θεω πατρι ηγιασμενοις και ιησου χριστω τετηρημενοις κλητοις
1003 = ιουδας χριστου ιησου δουλος αδελφος δε ιακωβου τοις εν θεω πατρι ηγιασμενοις και ιησου χριστω τετηρημενοις κλητοις
101  = ιουδας χριστου ιησου δουλος αδελφος δε ιακωβου τοις εν θεω πατρι ηγιασμενοις και ιησου χριστω τετηρημενοις κλητοις

The first step in collating is: cluster similar words according to a similarity measure. I choose a measure that takes insertions and deletions into account, so it is not quite the Levenshtein distance. I compute it based on the longest common subsequence (LCS) in the following way:

sim(w1,w2) = 2*length(LCS(w1,w2)) / (length(w1) + length(w2))

I cluster words by growing clusters from words that have a similarity of at least 0.8 to at least one member of them. The 0.8 is a thing to play with.

The next step is to create a bag-of-cluster-occurrences for all words in all sources. This is the master bag. Any word in a source is member of a cluster and this cluster is in the masterbag. If a source has repeated occurrences in the same cluster, the master bag will contain several occurrences of that cluster.

The words in the sources are linked (bi-directionally) to the cluster occurrences in the master bag.

Here is the result of assigning clusters to the words in the example sources above. Every cluster has a number, and every cluster occurrence has that number with a # appended and then the occurrence number:

0142           |336#1 ιουδας 542x|338#1 ιυ 11x|636#1 χυ 9x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|325#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|324#1 θω 10x|486#1 πρι 8x|296#1 ηγιασμενοις 484x|343#1 και 524x|338#2 ιυ 10x|637#1 χω 9x|573#1 τετηρημενοις 510x|356#1 κλητοις 537x|
049            |336#1 ιουδας 542x|636#1 χυ 9x|338#1 ιυ 11x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|325#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|324#1 θω 10x|486#1 πρι 8x|296#1 ηγιασμενοις 484x|343#1 και 524x|338#2 ιυ 10x|637#1 χω 9x|573#1 τετηρημενοις 510x|
056            |336#1 ιουδας 542x|338#1 ιυ 11x|636#1 χυ 9x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|325#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|324#1 θω 10x|486#1 πρι 8x|296#1 ηγιασμενοις 484x|343#1 και 524x|338#2 ιυ 10x|637#1 χω 9x|573#1 τετηρημενοις 510x|356#1 κλητοις 537x|
1              |336#1 ιουδας 542x|331#1 ιησου 530x|626#1 χριστου 531x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|325#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|320#1 θεω 525x|481#1 πατρι 529x|296#1 ηγιασμενοις 484x|343#1 και 524x|331#2 ιησου 510x|627#1 χριστω 378x|573#1 τετηρημενοις 510x|356#1 κλητοις 537x|
1003           |336#1 ιουδας 542x|626#1 χριστου 531x|331#1 ιησου 530x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|325#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|320#1 θεω 525x|481#1 πατρι 529x|296#1 ηγιασμενοις 484x|343#1 και 524x|331#2 ιησου 510x|627#1 χριστω 378x|573#1 τετηρημενοις 510x|356#1 κλητοις 537x|
101            |336#1 ιουδας 542x|626#1 χριστου 531x|331#1 ιησου 530x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|325#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|320#1 θεω 525x|481#1 πατρι 529x|296#1 ηγιασμενοις 484x|343#1 και 524x|331#2 ιησου 510x|627#1 χριστω 378x|573#1 τετηρημενοις 510x|356#1 κλητοις 537x|

And here is the master bag of all 560 variants! Every item in the masterbag is a list of words from the variants that are linked to that item. The number of variants supporting each word is indicated, and the words are (vertically) ordered by the quantity of their support. The horizontal ordering is just alphabetical:

|12#1 x1|13#1 x3  |23#1 x541   |85#1 x2    |122#1 x2|144#1 x537|169#1 x541 |169#2 x1 |181#1 x23  |200#1 x1    |221#1 x539|221#2 x7|296#1 x538       |297#1 x2     |310#1 x1|320#1 x525|323#1 x1|324#1 x10|325#1 x541  |326#1 x1|331#1 x530|331#2 x510|331#3 x1|332#1 x1|332#2 x1|336#1 x542 |336#2 x1 |338#1 x11|338#2 x10|343#1 x524|343#2 x4|356#1 x538  |364#1 x2 |440#1 x538|440#2 x1|481#1 x529|482#1 x1   |486#1 x8|509#1 x1|573#1 x526       |581#1 x1|597#1 x1|626#1 x531  |626#2 x134  |627#1 x378 |627#2 x2 |634#1 x1|635#1 x1|636#1 x9|636#2 x2|637#1 x9|650#1 x14|651#1 x4|
|1x αγι |3x αγιοις|541x αδελφος|1x ●●●●●○○ |2x ●●●● |537x δε   |541x δουλος|1x δουλος|23x εθνεσιν|1x εκλεκτοις|539x εν   |7x εν   |484x ηγιασμενοις |2x ηγιασμενης|1x ημων |525x θεω  |1x θυ   |10x θω   |540x ιακωβου|1x ιακω |530x ιησου|510x ιησου|1x ιησου|1x ιηυ  |1x ιηυ  |542x ιουδας|1x ιουδας|11x ιυ   |10x ιυ   |524x και  |4x και  |537x κλητοις|2x κυριου|538x τοις |1x τοις |529x πατρι|1x πατρασιν|8x πρι  |1x προ  |510x τετηρημενοις|1x της  |1x τω   |531x χριστου|134x χριστου|378x χριστω|2x χριστω|1x χρυ  |1x χρω  |9x χυ   |2x χυ   |9x χω   |14x █    |4x ░    |
|       |         |            |1x ●●●●●●●●|        |          |           |         |           |            |          |        |47x ηγαπημενοις  |             |        |          |        |         |1x ιακοβου  |        |          |          |        |        |        |           |         |         |         |          |        |1x κλιτοις  |         |          |        |          |           |        |        |9x τετηριμενοις  |
|       |         |            |           |        |          |           |         |           |            |          |        |2x υγιασμενοις   |             |        |          |        |         |            |        |          |          |        |        |        |           |         |         |         |          |        |            |         |          |        |          |           |        |        |2x τετυρημενοις  |
|       |         |            |           |        |          |           |         |           |            |          |        |1x ηγισαμενοις   |             |        |          |        |         |            |        |          |          |        |        |        |           |         |         |         |          |        |            |         |          |        |          |           |        |        |1x τηρημενοις    |
|       |         |            |           |        |          |           |         |           |            |          |        |1x ηγαποιμενοις  |             |        |          |        |         |            |        |          |          |        |        |        |           |         |         |         |          |        |            |         |          |        |          |           |        |        |1x τιτεμημενοις  |
|       |         |            |           |        |          |           |         |           |            |          |        |1x ηγνησμενοις   |             |        |          |        |         |            |        |          |          |        |        |        |           |         |         |         |          |        |            |         |          |        |          |           |        |        |1x τετιρημενοις  |
|       |         |            |           |        |          |           |         |           |            |          |        |1x ηγιασμενος    |             |        |          |        |         |            |        |          |          |        |        |        |           |         |         |         |          |        |            |         |          |        |          |           |        |        |1x τετηρημενος   |
|       |         |            |           |        |          |           |         |           |            |          |        |1x προηγιασμενοις|             |        |          |        |         |            |        |          |          |        |        |        |           |         |         |         |          |        |            |         |          |        |          |           |        |        |1x τετημενοις    |

Note that transpositions are no problem whatsoever. But there are problems, though, because very different words on corresponding positions will not get linked in any way.

Here is a remedy: take context into account. Merge cluster occurrences that have similar contexts. Here is how. First I make a skeleton passage by replacing the words with little support from the variants by a star. Words with sufficient support are replaced by the cluster occurrence in the master bag that they are linked to. The threshold is 0.6 . Again a value to play with. The context of an cluster occurrence is this skeleton occurrence with a place holder for the cluster occurrence in question. I will merge two cluster occurrences if they share a significant context. Significant means that at least one of the cluster occurrences occurs in this context often enough; often enough is expressed as a fraction of how often it occurs in all variants. The threshold here is chosen to be 0.0. Again, this is something to play with, or may be not since the limit value 0.0 already gives good results.

This is what we get. First the new collation:

0142           |336#1 ιουδας 542x|331#2 ιυ 11x|634#1 χυ 9x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|326#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|320#1 θω 10x|481#1 πρι 8x|296#1 ηγιασμενοις 484x|343#1 και 524x|320#1 ιυ 10x|320#1 χω 9x|573#1 τετηρημενοις 510x|200#1 κλητοις 537x|0251           |651#1 █ 14x|0316           |651#1 █ 14x|
049            |336#1 ιουδας 542x|634#1 χυ 9x|331#2 ιυ 11x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|326#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|320#1 θω 10x|481#1 πρι 8x|296#1 ηγιασμενοις 484x|343#1 και 524x|320#1 ιυ 10x|320#1 χω 9x|573#1 τετηρημενοις 510x|
056            |336#1 ιουδας 542x|331#2 ιυ 11x|634#1 χυ 9x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|326#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|320#1 θω 10x|481#1 πρι 8x|296#1 ηγιασμενοις 484x|343#1 και 524x|320#1 ιυ 10x|320#1 χω 9x|573#1 τετηρημενοις 510x|200#1 κλητοις 537x|
1              |336#1 ιουδας 542x|331#1 ιησου 530x|331#2 χριστου 531x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|326#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|320#1 θεω 525x|481#1 πατρι 529x|296#1 ηγιασμενοις 484x|343#1 και 524x|331#2 ιησου 510x|320#1 χριστω 378x|573#1 τετηρημενοις 510x|200#1 κλητοις 537x|
1003           |336#1 ιουδας 542x|331#2 χριστου 531x|331#1 ιησου 530x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|326#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|320#1 θεω 525x|481#1 πατρι 529x|296#1 ηγιασμενοις 484x|343#1 και 524x|331#2 ιησου 510x|320#1 χριστω 378x|573#1 τετηρημενοις 510x|200#1 κλητοις 537x|
101            |336#1 ιουδας 542x|331#2 χριστου 531x|331#1 ιησου 530x|169#1 δουλος 541x|23#1 αδελφος 541x|144#1 δε 537x|326#1 ιακωβου 540x|440#1 τοις 538x|221#1 εν 539x|320#1 θεω 525x|481#1 πατρι 529x|296#1 ηγιασμενοις 484x|343#1 και 524x|331#2 ιησου 510x|320#1 χριστω 378x|573#1 τετηρημενοις 510x|200#1 κλητοις 537x|

And here is the new master bag:

|12#1 x1|13#1 x3  |23#1 x541   |144#1 x537|169#1 x541 |169#2 x1 |200#1 x541  |221#1 x539|221#2 x7|296#1 x540       |310#1 x1|320#1 x1072 |326#1 x542  |331#1 x530|331#2 x1053 |331#3 x1|336#1 x542 |336#2 x1 |343#1 x524|343#2 x4|364#1 x2 |440#1 x540|440#2 x24  |481#1 x539 |573#1 x526       |581#1 x1|627#2 x2 |634#1 x10|651#1 x18|
|1x αγι |3x αγιοις|541x αδελφος|537x δε   |541x δουλος|1x δουλος|537x κλητοις|539x εν   |7x εν   |484x ηγιασμενοις |1x ημων |525x θεω    |540x ιακωβου|530x ιησου|531x χριστου|1x ιησου|542x ιουδας|1x ιουδας|524x και  |4x και  |2x κυριου|538x τοις |23x εθνεσιν|529x πατρι |510x τετηρημενοις|1x της  |2x χριστω|9x χυ    |14x █    |
|       |         |            |          |           |         |1x ●●●●●●●● |          |        |47x ηγαπημενοις  |        |378x χριστω |1x ιακοβου  |          |510x ιησου  |        |           |         |          |        |         |2x ●●●●   |1x τοις    |8x πρι     |9x τετηριμενοις  |        |         |1x χρυ   |4x ░     |
|       |         |            |          |           |         |1x ●●●●●○○  |          |        |2x υγιασμενοις   |        |134x χριστου|1x ιακω     |          |11x ιυ      |        |           |         |          |        |         |          |           |1x πατρασιν|2x τετυρημενοις  |
|       |         |            |          |           |         |1x κλιτοις  |          |        |2x ηγιασμενης    |        |10x θω      |            |          |1x ιηυ      |        |           |         |          |        |         |          |           |1x προ     |1x τηρημενοις    |
|       |         |            |          |           |         |1x εκλεκτοις|          |        |1x ηγισαμενοις   |        |10x ιυ      |            |          |            |        |           |         |          |        |         |          |           |           |1x τιτεμημενοις  |
|       |         |            |          |           |         |            |          |        |1x ηγαποιμενοις  |        |9x χω       |            |          |            |        |           |         |          |        |         |          |           |           |1x τετιρημενοις  |
|       |         |            |          |           |         |            |          |        |1x ηγνησμενοις   |        |2x χυ       |            |          |            |        |           |         |          |        |         |          |           |           |1x τετηρημενος   |
|       |         |            |          |           |         |            |          |        |1x προηγιασμενοις|        |1x ιηυ      |            |          |            |        |           |         |          |        |         |          |           |           |1x τετημενοις    |
|       |         |            |          |           |         |            |          |        |1x ηγιασμενος    |        |1x χρω      |
|       |         |            |          |           |         |            |          |        |                 |        |1x τω       |
|       |         |            |          |           |         |            |          |        |                 |        |1x θυ       |

Much better, it seems. Look how many nomina sacra (holy names) are now lumped together. Too many?

Next steps¶

Important questions remain:

• how can we check whether this kind of collation is good?
• what is needed to adjust the thresholds to get optimal results?
• how can we understand the contribution of each of the three threshold settings?

Greek Group Bert Jan¶

Disccusion with Jan Krans, Alexey Somov, Ulrik Sandborg-Pedersen, Nico de Groot, Matthew Munson, Markus Hartmann, Jon Riding, Bert Jan Lietaert Peerbolte

1. The main point we are discussing is how to analyze the text of the Greek NT by computers. Paratext works with algorithms, establishes word pairs (e.g. Greek - English; Greek - Dutch): on the basis of these word pairs, English equivalents are displayed. Occasionally, this leads to mistakes because words function in various semantic domains and their exact meaning is related to the semantic domain in which the word functions in the particular text in which it is found.
2. The critical apparatus poses a problem to bible software. How should the apparatus be taken up in your program? The presence of variant readings is important to translators who do not have a paper edition at hand. Adding the committee’s classification from Metzger’s textual commentary informs translators on the value of the readings adopted in the main text. NB: Paratext uses the GNT apparatus, not NA27. The way in which Paratext presents textual evidence now shows that it is digital information that has been published in a printed form, and has then been transformed to a digital environment. In the apparatus a scholarly edition would need full information on manuscript readings. Clicking the abbreviation should result in checking the exact reading referred to.
3. A syntactical analysis of the Greek text is lacking so far. Semantics and morphology are covered in Paratext, but syntax is not. Jon Riding is actually questioning the sheer existence of syntax as a discreet system. Eep Talstra (who just entered the room) argues that syntactical patterns are there in the text, and that they can be discerned by a computer. In response to this point, Ulrik Sandborg-Pedersen presents the new syntactical parsing project by Logos. There, the parsing is done by the computer, not by human activity. This parser can generate entire trees of NT texts in Logos. The group are hoping for Rick Brannan to show us the possibilities of this new asset in his presentation later this week. One of the difficulties here appears to be the fact that every computer analysis of syntax is also connected to grammatical categories. To mention but one example: why should δέ be categorized as a “conjunction”?
4. An interesting methodological issue pops op: what to do with the phenomenon of krasis? Should the word κἀκεῖνον in Luke 20:11 be read as καὶ ἐκεῖνον or not? If you work on the basis of a database, the word should probably be split up for reasons of classification. The methodological problem is of course whether you can apply grammatical classification as the defining element for building a database. Jan Krans mentions the (non) use of the article in John 1 as an important point of discussion, but the exact point escapes the author of this report...

Notes BJLP

Hebrew Group Wido¶

• How do you organize data of the text
• How do you order the analysis of the text

The WIVU database itself is designed to allow data to be extracted. Allowing arbitrary “data mining”, to supplement the data, to write scripts to manipulate or search the data in ways or to answer questions not originally envisioned by the database designers.

Once you decide upon a data model, that makes the database well-defined, but you can no longer accommodate those things that do not fit the model.

Multiple information hierarchies in the text. These hierarchies are not necessarily compatible with one another. How does one preserve the hierarchical relationships and not lose information? E.g., multiple Bible translation alignments: LXX and MT, for example. Emdros is one possible solution.

Can we design a database that is optimal for incorporating new data as we go along? There is a symbiotic relationship between the database as a research tool and the database as a repository of information. Is a database designed to answer very specific research questions, or do we design it to allow uses which we today cannot predict?

Can databases be “re-purposed”? How can we combine the information of “alien” databases (or parts of them) into a “new” database or dataset for the researcher’s use?

There was some discussion about the practical problem of proprietary databases versus “open” databases.

Different manuscripts and reading traditions. Basic information unit should be an “abstract position” of the text where variants can be linked and associated.

We need some sort of standard for first level data, second level data, etc.

Standards for publication and peer review specifically relating to the digital humanities. Research publishing needs to allow the reader to – as in the natural sciences – repeat the research (data, algorithms) to see if one can get the same results. In this way, research conclusions can be validated.

Notes: Kirk Lowery

Informatics Group Henk¶

Paul Huygen, Juan Garces (Göttingen), Nicolai, Marcel Ausloos, Dirk Roorda, Henk Harmsen, Janet Dyk, Andrea Scharnhorst

• levels of analysis (circularity, ambiguity)
• preserving research results
• anchored sources
• open source communities - non-exclusive licences

Ambiguity

Variance

Granularity - Modularity

Lowest level = texts as transmitted in manuscript traditions then transcriptions then markup levels

Uncertainty on lower levels are often resilved by patterns at higher levels.

Anchoring. Paul: Münster Group is doing that. There are unique identifiers in the WIVU database.

Canonical Text Services (FRBR) (http://wiki.digitalclassicist.org/Canonical_Text_Services)

Marcel: abbreviations?

Juan: physical and logical aspects in manuscript analysis.

Nicolai: we are moving towards collaboration, sharing, multiplicity.

Paul: how do we do this from the beginning, modelling. (looks like SharedCanvas).

Andrea: how you want to deal with ambiguity should be communicated to the informatics people.

Changing classification numbers in evolving systems.

Where is the responsibility for versioning: in the application or in the archive.

The role of mistakes: must we keep them, because they are facts, or must we correct them, because we want to do analysis.

Keep both.

Janet we do not only have the glyphs: we also have higher level patterns. We are doing analysis at different levels, so we cannot separate the realm of fact and the realm of interpretation rigourously.

Nicolai: it’s important to define the purpose of the database. Sometimes you need the mistakes to be present, e.g. if you are interested in the physical texts. But on top of that we need databases, systems for representing other layers of analysis.

Nicolai: bigger players go to open source initiatives. If we in our EU project cannot use the WIVU freely for research, we may have to drop it, which we would do with reluctance.

Relationship WIVU - SESB - Logos.

Juan: Bibleworks might be the must prone to proposals like this.

Notes: Dirk Roorda

Plenary¶

After the sub group summaries we discussed the following points:

• commercial versus/with open source. The panel states that it is good to have anchored sources publicly available, and that for the rest commercial interest can still flourish in the presence of an open source community that is also using those sources.
• syntax trees and colocations provide more information as to the interpreation of the words. Jan Krans: but is that information correct? Eep: could you anchor those analysis results to the sources?
• scope and details of anchored texts
• reference grammars stopped when linguistic database started (Michael Aubrey). The multiplicity of text databases per se is a worthwhile contribution to the field.
• the development of databases. They evolve, data is added, features are added.
• the role of the level of analysis for sharing and collaboration. On the lowest levels (say the facsimile of the Sinaiticus) we can achieve a lot of consensus. At higher levels there will be more controversy. So the lower levels are more amenable for sharing, and we should do that in order to further our research purposes at higher levels.
• scholars want to do their own analysis. They do voluntarily incorporate those of their colleaugues. The design of sharable data should reflect that. (Wido).
• Juan: also look at what’s happening in comparable disciplines: literary and discourse studies in old texts. Also mind the differences: there are other purposes at play as well.
• Sharing should be focus on the results of the analysis, not necessarily on the analysis process itself.
• collaboration also means: sharing assumptions. Playing with assumptions as well (counterfactuals).
• role of databases in teaching. Next generations have the equipment for new research. How much do we want to limit the use of our resources by new generations?
• Andrea’s question: why all these questions about text? Andrea: my question is: what can computational methods do for us, how far do they go?Do we use them to order our data, or are we using them to disturb our minds?
• Eep: we are changing from the question: how did the river from source to editions run in case of the Hebrew Bible? to how do rivers run in general?. From art-creation to sociological processes.

Notes: Dirk Roorda

Group Visualisation (Andrea)¶

Nicolai, Brenda, Wido, Eep, Marcel, Joris, Paul H.

Old Testament syntactic structures - Visualization of Kirk

New Testament Complexity in the manuscript evidence - 5000 different documents

A: Information about the sources: from which time on which media type of manuscript where it is now located a visualized bibliography

lists exist on parts of the sources Nicolai: a mapping of these sources is not interesting Wido: links between manuscripts and books Brenda: where things are found say how accurate they are

N.: closeness to the sources is the most interesting feature; so any measure which allows the comparison of the similarity of texts; clustered; and than check manually

Muenster institute applied multi-dimensional scaling to cluster manuscript on the textual basis - new testament people

Paul H.: genealogy of texts using techniques like in bioinformatics - minimal spanning tree (M. there are technically problems with this method in particular if data are noisy)

Brenda: most sense would make to do analysis of word levels for the NT: the New Greek Testament is an authorative sort of source

What would you like to see visualized? Why?

Wido: how to visualize the relationship between different texts (e.g., biblical books of Samuel and Chronicles) printed: two versions side by side and changes marked in red but we would like not only have changes marked but what kind of changes

Wido: We would also like to see how we could detect changes in the sources these authors might have used

Paul H.: could we use methods of fraud-detection?

B: What can computers do? Often people do guess work. We gave so little data. What computers can do help depends on the quality of the basic data. One approach to this is to test out very different measures at the same time (M)

N: can we develop criteria to detect authorship?

M.: an experiment was done on the time magazine editorial to find out who wrote it, or who wrote which pasaages; but influences are varied so that it is almost not possible

N: can we detect style? But people adapt their style to the context in which they use it, their audience

A: visuals could be use to communicate about your research to the outside communities: how complex are your data, in time/space/kind, along which dimension you have too much data and along which dimension you have to less and might want to have methods to “enrich” the data

J: CKCC project 20 000 letters of scholars in the enlightenment period; entity recognition - biggest question are topics, but names and places are also in the focus network visualization needs defined matrices!

Wido: different versions of a story can be found - not always with the same words - latent semantic analysis; motifs/themes/semantic links between things which come with a different wording

A: clustering depends on the seed node with which we start, from some nodes of the networks the group sees itself and equally amorphous all the rest, some other start nodes gives a more clear ring structure and neighboring village structure much clearer

M: network of quotations could be constructed and than similar techniques as in citation analysis could be applied

J: could one create information from the workflows done around the basic data, when storing and coding them? Construct a network of activity of biblical scholars (from the publications - tracking in books - reconstruction the perception history but than in modern time on the analyzer level (not the source level))

N: 8000 words are in the vocabulary: lemma’s (?)

B: timing of words has been used: what are changes: spelling - but no visualization

N: but what would it help us

B: wordle used in education to show what a certain passage is about; but beyond this we not even know the questions

W: visualizing the vocabulary of the bible; A.: could we also put this into the semantic web?

A: Can we apply the CRM system of Martin Doerr’s group to sources (http://www.cidoc-crm.org/)(artifacts) around the bible? Has that be done? CRM allows to trace the journey of an object across locations, musea

N/Eep: could we visualize stories using participant analysis; seeing the story happening; visualizing the path dependency of stories and this way show and maybe visualize “alternative histories”; poems are even more complex with this respects; track to visualize what is the consequence of some decisions made and switching between them; implement different scenarios - play with them difficult to read from raw data - for teaching to undergraduates visuals would be great

A: could we borrow visualizations from film scenarios or alternative writing with many stories ask Katy

Eep: for participant tracking metaphors became important - Iina Hellsten VU

N: as we discover new rules in analysis visualize on the flight; Principal component analyses applied to things like verbs, valencies, temporal and locational entities, persons,gender, number etc

DANS could do experiments with the database on the attribute level Andrea and Dirk could check this out

B: visualize different storylines in one text

Eep: synopsis of the gospel texts - might be similar to the ManyEyes visualization of changes in treaties of US legal systems

J: try to compose the old testament just from the perspective of David -> give this as task to the computer scientists and let them model the data

Eep: applying visualization in education; visualizing the workflow so that students could be more easier get used to the work practices** strong learning system

N: how to visualize a text? There are experiences in other fields you could rely on

E: how to translate database content to some kind of visualization**

N: bible is not only text, also images and other objects - project on augmented reality around the bible

E: deliberate changes versus changes/variations by accidents - purposefully variations of story with a certain effect on the audience; how to let students experience this?

A: Visuals fly with us because we live a a visual culture, but be carefully they can also be easily misleading and they can also become dull if not done professionally (design)

Software tools:

• Gephi - for network visualization http://gephi.org/
• Katy Boerner’s tool (where the workshop in Amsterdam is Feb 16, and registration via ehumanities.nl) http://sci.slis.indiana.edu/
• ManyeEyes, works as wordle, upload data and explore them http://www-958.ibm.com/software/data/cognos/manyeyes/
• Places and Places exhibition www.scimaps.org
• other visualization websites for inspirations http://www.visualcomplexity.com/vc/

Website of Clement Levallois, who organized the workshop on visualization together with Stephanie Steinmetz (Wido mentioned this, where Vosviewer was presented), he is in Leiden and Rotterdam, http://www.clementlevallois.net/index.php

Group Linguistic Analysis (Kirk)¶

Continued Discussion of the the Groves Center’s Westminster Hebrew Syntax

How did they compile the database? They began manually, starting with Genesis 1 and creating trees manually. Andi Wu (Asia Bible Society) began writing grammar rules. Then the parser generated trees for Genesis 1 and these were checked against the manually created trees. The grammar was modified again and run on Genesis 2 and compared again. By the time Genesis 20 was reached, the grammar was sophisticated enough for the rest of the Hebrew Bible (minus the Aramaic portions).

Most of our conversation dealt with what information was necessary in this database and what could be left out. In a tree, you need to decide which words are related to each other. What information do you need beyond that? S, V, O, IO, NP, PP. Ind Object vs. PP? Subject instead of np? How to deal with strange situation? Multiple objects for a verb? Object marker in front of what is actually a subject (cf. Neh 9:19)?

There was continued interest in how Masoretic cantillation was used. Rather than summarize the discussion, the reader is referred to the following paper by Wu and Lowery which goes into great detail about this method:

Wu, Andi and Kirk Lowery, “From Prosodic Trees to Syntactic Trees,” pp. 898-904 in Proceedings of the COLING/ACL 2006 Main Conference Poster Sessions. Association for Computational Linguistics: Sydney, July 2006. http://dl.acm.org/citation.cfm?id=1273188

Important insights: make the decisions made clear so that others can understand and disagree. Don’t make your database useless to those who don’t agree with your assumptions/decisions.

Group Dealing with Complex Textual Evidence (Jan)¶

Jan Krans, Juan Garces, Markus Hartmann, Constantijn Sikkel, Rick Brennan, Dirk Roorda, Karina van Dalen, Oliver Glanz, Alexey Somov, Reinoud Oosting, Eep Talstra (part-time), Bert Jan Lietaert Peerbolte.

• link between (linguistic) incoherence, then it is linked to its transmission; OT has a more a linguistic approach, NT has stronger emphasis on textual criticism -> it’s a matter of research interest
• text base is usually fixed to the standard editions (Textus Receptus, NA27, UBSGNT, SBLGNT) as “the text” - this influences the database structure - which is the right model? - NA27 should not be the de facto default
• is there one model that caters for both OT and NT? Do they have the attract the same research questions? Same tools can be used for both traditions, e.g. collation tools
• database = data + model + algorythm(s) - do we have to wait for a solutions to major questions before we create a database? - XML vs relational databases
• is RDF a possible solution? More of a metadata format than a solution
• versions: relations between source text(s) and translations is complex + quotations of the texts in Church Fathers etc. - how does this impact our research and modelling?
• science is also about abstraction and abstractions are important for scientific progress; are there discoveries & findings that have challenged major abstract models? Western non-interpolations (previously omitted, now included) - this would influence analysis and grammar
• new philology: texts are analysed in parallel -> no need to exclude variants in lieu of a standard text; the context of the manuscript is very important, variation is celebrated as part of the text tradition - each manuscript text has its own intrinsic value, different questions are asked; can we undertake such an approach with over 5000 MSS? (vast difference between MSS - from little fragments to large codices etc.)
• editions include disambiguations and interpretations that have been added in the process of transmission or by modern editors
• main challenge: trying to postpone the influence of (scholarly) tradition, departing from a sense of distance from that tradition
• case study: NT transcripts - Lk 2, 1Tim 3:16
• concept of text is more complex than the abstraction
• digital medium allows for explicitness of decisions and the reasons for these decisions - Q: what do you do with such micro-data? A: Find intricate patters, e.g. scribal habits, make decisions consistently, find patterns
• existing data is still restricted (e.g. Catholic Epistles) - is this data representative? more comprehensive data is necessary
• social revolution: data can only be established as a larger, collaborative effort (partly crowdsourcing) - needed: standards
• base data: sometimes you cannot agree, scholars aren’t sure - manuscript texts are more complex (change of hands, ink etc. - see file)

ADDENDUM¶

Discussion on newly found papyrus of Mark (1st century): http://hypotyposeis.org/

Plenary¶

The manuscripts of the Greek NT in digital form are low hanging fruit.

Gephi open source visualisation tool

Presentation Andi Wu¶

Showing the Synonym Finder

The programs gives a scored list of syonyms to a given Hebrew or Greek word. It also grabs translations in English and Chinese from the database. Can give Greek synonyms of Hebrew words and vice versa.

Janet: where did you harvest the synonyms from?

Question: we have the data to generate networks of meanings, so is this useful for scholars doing dictionary studies?

Showing the Similar Verse Finder

Shows verses with similar words in similar grammatical relationships. Similarity is sensitive to meaning, not in the first place to form, part-of-speech, morphology.

This tool crosses the OT/NT boundary.

Showing Multiple Senses for Words

Looking for the senses of strong 639. Computing the senses takes time ... Sense 7 does not have any instance yet. Uses info from the translations.

Shows all occurrences, indicating the sense it has in each occurrence.

Wido on Publication

Digital Humanities Quarterly is interested to have a special edition with contributions of this workshop. Some editorial work will be necessary.

Action Juan

Sends out a questionnaire in order to make a map. To make an inventory of our network.

Karina van Dalen

We have to show the humanists the tools in a bit more comprehensible ways.

What are the tools beyond linguistics? How do literary scholars discuss these things, how do we cooperate with programmers?

Agile development paradigm. Frequent reporting by programmers to scholars. Being involved during the complete development process. Discovering new possibilities in time, so that you can use them quickly. Benefit for programmers: they are building something that can be used.

Impressed by the tool developments that were shown here.

Ulrik confesses having done it in the wrong way at one time. The scholar did not want to use his database.

Dirk

Editions and the slide rule.

Ulrik

Socially: There is a spirit of common vision, focused: having databases of the biblical languages. Not too competitive.

Technically: people want to talk across the fields: ICT, Humanities. A lot of common understanding has been generated.

Yet: we are just starting. The real work await us: between us and among us.

Showing: The Discovery Bible, with question: is this useful?

Shows NASB text with annotations of verb tenses, more in general: to a large refeence grammar. Same for a lexicon. Plus concordance.

A scholarship-consumption tool?

Useful for teaching?

Jan: first have to feel it in action myself?

What is added value on top of SESB or Logos?

Ulrik: emphasis is marked in Greek, tense is marked in English.

Ulrik’s solution can be feature driven on the basis of whishes of the researchers.

Eep: so far it is an electronic version of a classical object: text, lexicon, grammar.

Oliver: we should have a map of feature lists: who is needing which features. That could function as an interface between scholars and programmers. We could develop larger chunks of functionality, targeted to researchers and teachers or both. What happens in workshops between scholars and programmers should somehow surface into the open.

John Cook: ambivalent. I’m not sure what I want to use in the class-room. We are always waiting for the ultimate (ICT) miracle.

Ulrik: this is a very small program: 2.500 lines of C++ on top of EMDROS.

Nicolai: agile development, participatory design that is what I like to see.

Andrea

Whenever you cross a disciplinary boundary you get an epistemic struggle. That is known. But the manifestions are always surprising, and unavoidable.

One’s solutions are another’s problems.

Explain the why-s? Find the language for that.

The topics are similar throughout digital scholarship. Do not go for a super discipline Digital Humanities, that eat up the original disciplines.