Loading... Loading ...
Notice: This documentation was generated by the free version of MireDot. As such, not all features are supported.
Unknown licensing error, please contact support@miredot.com.
expand / collapse all

REST API documentation

Stemmarest is a Neo4j-based repository for variant text traditions (i.e. texts that have been transmitted in multiple manuscripts). For an introduction to its conceptual structure, read on; to dive into specific API calls, see the menu to the right. Within the documentation, click on any title to get an expanded description of the call.

Definition of terms

What follows is a definition of the concepts that occur within Stemmarest; understanding these terms will be helpful for understanding the API documentation. Note that most of these entities are defined with respect to (therefore, under) the /tradition/{tradId} heading in the API; readings, although defined as root objects, always belong to one and only one tradition section.

Tradition

This is the central object in the database. A tradition represents the structure of our information about the text, from its witnesses to its sections to its readings and relations.

Witness

A witness represents a document that carries some version of the text. Witnesses generally have sigla to identify them, and they can be assembled into one or more stemma hypotheses. The witness sigla are used to identify individual textual versions within the sections; there, witnesses may also have layers to represent changes made to the text in the document.

Stemma

A stemma (in this context more properly a stemma hypothesis) is a graph that asserts a particular set of copying relationships between witnesses. The witnesses in a stemma can be extant (meaning that their text appears in the tradition) or hypothetical (meaning that their text does not appear, and their existence is only conjectured based on the evidence of the copying history.) The stemma objects in the database can have a root (or archetype), or not. The identity of the archetype can be changed by the user.

Section

The text of a tradition is divided into one or more sections, largely for manageability of the textual data. A section includes the set of readings from each witness, usually knitted together into a collation graph. Every section has a start node and an end node, and every witness (or, more precisely, every layer of every witness) takes a single path from the start to the end through a subset of the section's readings.

Reading

A reading is the base unit of the text. Most often this is equivalent to a word, but depending on context and on the needs of the editor, it may be a partial word, or it may be several words joined together. Readings are the nodes that are joined together by witness paths (a.k.a. sequences), and can be correlated by named relations. Two or more readings that are colocated in the collation (that is, they occupy the same place in the text, in different witnesses) are also known as variants.

Relation

It is often useful for an editor to be able to classify the types (or even the existence) of variation that occurs across witness texts. This is done via the relation, which (depending on its type; see below) usually also signals that the readings are colocated. They can also indicate correspondences such as transposition (when the same reading occurs in different places across different witnesses).

Relation type

The user can define a set of relation types per tradition; these can be given unique names and arranged in a loose hierarchy. See the documentation for RelationType for more details.

Annotation

Arbitrary structured information can be added to any node in the tradition via the annotation framework. An annotation is a node that has user-defined properties, and user-defined outbound links (i.e. relationships) to specific sorts of nodes. An annotation framework is defined by means of annotation labels on the tradition.

Annotation label

The annotation label defines a sort of annotation that may appear on the tradition, the properties it may contain, and the types of entities (i.e. nodes) that it may link to.

  • Deprecated.

    Deprecated:

    {{baseUrl.value || ' '}}
       {{role}}{{$last ? '' : ', '}}

    Body

    Accept:
    no type

    Returns
    Content-Type:
    no type

    Response Headers

    Status codes

  • Interfaces not documented

    MireDot believes that the Java methods below correspond to REST interfaces, but somehow had problems parsing/processing these interfaces and therefore excluded them from the generated documentation. We would very much appreciate it if you would send us the interfaces (not the implementations) and the types used (returntype, parameters). This will allow us to further improve MireDot and better document your interfaces in the future.

Below is a list of potential problems detected by MireDot. They can be severe or not. Some of them wil result in low quality documentation, some are real implementation issues. With each warning, the Java method causing the problem is documented.

    • method:

    not shown here because this documentation was generated by the free version of MireDot. As such, not all features are supported.