Graph schema validation at last? Revisiting the Stemmarest data model with Neo4J and SHACL

object_of_studyconcept_edgesIn 2020 there was an attempt to create an ontology (Andrews, 2020) for content_tags↗content_tags↗the variant graph, which is a data model used in tools such as CollateX (Haentjens Dekker et al., 2015), Stemmarest (Andrews, 2019), and TraVIZ (Jänicke et al., 2015) to represent and visualize text collations and certain sorts of annotation. limitationsconcept_edgescontent_tagsThe conclusion was that the ontology was not suitable for expressing the full data model employed in variant graphs, not least because all of them (Stemmarest most heavily) content_tagsrely on property attributes, which RDF and OWL do not handle well and which can therefore not be suitably represented in an ontology definition.

concept_edgesIndeed, although ontologies have in the meantime been proposed for various aspects of digital scholarly edition (NIE-INE, 2019) and specifically for critical apparatus (Giovannetti, 2021) and an opportunity to discuss these together would be very welcome, one major motivation for undertaking the 2020 project at all was to address the concerns, frequently heard by the author in a very heavily XML-based community, that since graph databases do not tend to have schemas and certainly have no way to enforce these schemas, content_tagsthey lack the foundations for sustainability and interoperability that TEI XML schemas or, indeed, relational database schemas provide. Many of those who expressed concerns went on to point to ontologies as examples of schemas that can be used to validate RDF data.

claim_relationsclaim_relationscontent_tagsWhat the 2020 project showed, in the end, was the inadequacy of ontologies and especially OWL as a validation model for graph-based data. sensesWhile many of the classes used by Stemmarest and their relationships to each other can be described adequately in OWL, the model relies upon many additional constraints that, while seemingly simple, go beyond OWL’s capabilities. concept_edgesconcept_edgesFor example, in the Stemmarest ontology we can say that a Witness can belong to a Tradition and also to one or more Stemmata, and that a Tradition can contain multiple Stemmata. sensesHowever, one of the important aspects of validation is to prevent inattentive mistakes in the data model. mechanismsFor example, if a witness W appears in a stemma belonging to tradition A, the model software should ensure that W also belongs to tradition A as a witness and not, for example, an unrelated tradition B; moreover, W should not appear in any stemmata of tradition B. mechanismssensesEven more intractable problems arise with more complex specifications: for example, the need to ensure that the variant graph is self-consistent, so that a user cannot create a situation in the model where a portion of the edited text loops back onto itself or is omitted altogether. mechanismslimitationscontent_tagsThus, while the Stemmarest ontology can describe the data reasonably well, it is not an adequate tool for setting constraints; these must still be described in code.

sensesclaim_relationsVogeler (2021, p. 80) notes in his discussion of graph-based models for critical edition that “the formal affordance of OWL is not really exploited in Digital Scholarly Editions”. mechanismssensesclaim_relationsWe would argue here that most editors are less interested in the sort of open-world inference for which OWL was intended (though Vogeler makes a case for why it might be interesting), as opposed to the formalisation, description, and consistency of their data. phenomenonclaim_relationsIn this sense, the critics of graph-based models do have a point; how do we validate our graphs? limitationssensesConstraint enforcement in Neo4J, perhaps the most popular graph database, is indeed limited strictly to data properties of nodes and relationships (Neo4J, Inc., 2022). limitationsThe situation is hardly better for LOD stores, which have so far depended more or less entirely on ontology specifications, with limitations as described above, to describe their data.

method↗Recently, however, there have been two intriguing developments in the Semantic Web world that are especially relevant to digital humanities projects, not least Stemmarest. The first of these is content_tags↗RDF*, an extension to RDF that allows an entire triple to be the subject or object in further triple statements (Arndt et al., 2021). limitationslimitationsclaim_relationsconcept_edgescontent_tagsWhile it is still in an early phase of development, RDF* provides the long-awaited ability to set context for LOD statements, and promises to triple stores the same ability to set properties on relationships that graph databases such as Neo4J have always provided; this in turn has opened the way for Stemmarest, and many other projects besides, to take advantage of Neo4J’s powerful graph traversal and analysis algorithms while preserving full interoperability with LOD formats.

alternativesThe second major development is content_tags↗SHACL (Shapes Constraint Language), a language whose purpose is to define a set of constraints against which RDF graphs can be validated (Knublauch and Kontokostas, 2017). claim_typemechanismsclaim_relationsconcept_edgescontent_tagsThis language solves exactly the problem that ontologies do not; specifically, in conjunction with a database that supports transactions and their rollbacks such as Neo4J, a set of SHACL constraints can ensure the consistency of data added to the graph, so that (to take the example above) a witness from one text tradition cannot be included in a stemma belonging to an entirely different tradition.

Perhaps the most intriguing feature of SHACL is the ability to include “constraint components” expressed in SPARQL or Javascript, providing more or less limitless possibilities for formalising complex models. mechanismslimitationsIn a sense, this affordance challenges the idea of the separation of program code and data that is the usual gold standard for sustainability efforts, insofar as constraints can be expressed as arbitrarily complex programming logic, embedded in RDF or Turtle files and saved as a schema alongside the data itself.

claim_relationsThe SHACL model thus provides a fascinating way to bring the intellectual contributions inherent in codework (Zundert, 2016; Antonijevic Ubois, van Zundert, and Andrews, 2018) across the “sustainability divide” that allows them to be properly valued and conserved as scholarship; at the same time, it points to a promising future model of digital work in the humanities, in which domain-specific code can live alongside the data, to be processed by more generic (and thus, hopefully, more long-lived) software platforms.