search

jjmccollum / open-cbgm

Fast, compact, open-source, TEI-compliant C++ implementation of the Coherence-Based Genealogical Method
MIT License
29 stars 1 forks source link

Graphical user interface to prepare collation files for open-cbgm #3

Closed jjmccollum closed 2 years ago

jjmccollum commented 4 years ago

Per @LarsKemmann's suggestion, I've added dedicated issues for the desired features external to the open-cbgm library. Because they are external to the core library, these features would best be maintained in their own repositories, but until someone decides to start implementing these features, these issues will serve as a convenient forum for discussion. This issue concerns the "pre-CBGM workflow" desideratum listed at the end of the readme.

Tools like the ITSEE Collation Editor offer users a graphical interface for segmenting and classifying collations of multiple witnesses to a text. Their output is a TEI XML file representing the collation. In order to use these files to populate a database for the open-cbgm library, a couple extra components (primarily, connectivity limits and local stemmata) need to be added to their XML trees. I've put together a rudimentary Python script in https://github.com/jjmccollum/itsee-to-open-cbgm that does the initial steps in this process (it adds CBGM-specific TEI XML elements under the <app> elements representing variant passages, including a <graph> element for the local stemma, initialized with disconnected readings), but it still leaves a good deal of work to the user, and it is a command-line utility. A graphical user interface (GUI) would be ideal.

The graphical interface I have in mind would start with the initial formatting step described above. A drop-down menu or similar widget would allow the user to navigate between variant passages (i.e., the <app> elements in the XML file being processed) by their indices (which will be assigned to them automatically by the interface, as itsee_to_open_cbgm.py already does). For each passage, the user should be able to input a connectivity limit (a positive integer) and a human-readable label for the local stemma. The interface would display a Graphviz (or D3, if this is implemented as a web app and D3 is easier to use) rendering of the local stemma in its current state. Initially, a local stemma might look like this:

image

The interface would include buttons for adding, removing, or editing directed edges between the readings. (For our purposes, editing would consist of the assignment of a weight to an edge, which would modify the <label> element of the <arc> element corresponding to the edge.) This could be done with a drag-and-drop system, or, if that's too complicated, with a dialog that uses dropdown menus for source and destination readings. The rendering of the local stemma would respond to changes in real time:

image

A "load" button would read in a TEI XML file of a collation and perform any necessary reformatting (as described above). A "save" button would write the XML tree in memory to an output file specified by the user.

jjmccollum commented 2 years ago

I am now closing this issue, as I consider @d-flood's criticus library (https://github.com/d-flood/Criticus/) to fulfill these desiderata.