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

Tag layer of the DHSS Meta-Tagging Project. The article text is reproduced from the staged copy named in sourceDesc and is not altered; the tags are held separately in standOff so that overlapping and nested spans are preserved.

 Graph schema validation at last? Revisiting the Stemmarest data model with Neo4J and SHACL 2023 Digital Humanities 2023 (DH2023), Graz 10.5281/zenodo.8107471 stemmarest2023-shacl stemmarest2023-shacl.txt, the project's staged copy 16a0fc45ba86c37046cb00ea2d4f0df0df375611 cc-by digital-humanities

the paper's own words

the tag layer; a sentence written by the tagger about the paper, always anchored to a quotation but not itself a quotation

 50 spans located by searching the stored text for the quote's exact words, allowing any whitespace between them The variant graph data model used to represent text collations, and whether its constraints can be expressed formally. method graph schema validation reviewreview An ontology describes what kinds of thing exist and how they relate, but cannot forbid a combination that is well-typed and still wrong The hard constraints are cross-object: an entity appearing in one structure must be consistent with its membership elsewhere Some constraints are global properties of the whole graph and cannot be checked object by object at all The original failure was not a modelling mistake but a mismatch of purpose - OWL was built for open-world inference and editors want description and consistency Constraints only bite if the store can undo a rejected write, so validation needs transactions and rollback underneath it Allowing arbitrary code inside constraints erases the code/data boundary that sustainability practice depends on, which the author treats as a feature The author's own earlier Stemmarest ontology describes the data adequately but cannot express the model's constraints, which still have to be written in program code.what this limits: any use of the ontology to enforce the model: 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 RDF*, the extension the interoperability half of the proposal depends on, is acknowledged to be immature.what this limits: the interoperability half of the proposal: RDF* IS STILL IN AN EARLY PHASE OF DEVELOPMENT SHACL's SPARQL/Javascript constraint components undermine the separation of code from data that sustainability practice normally treats as the gold standard.what this limits: the sustainability claim for SHACL: constraint components CHALLENGE THE IDEA OF THE SEPARATION OF PROGRAM CODE AND DATA THAT IS THE USUAL GOLD STANDARD The 2020 ontology attempt failed because RDF and OWL handle property attributes badly, and the model depends on themwhat this limits: any RDF/OWL serialisation of a property-bearing graph: THE ONTOLOGY WAS NOT SUITABLE FOR EXPRESSING THE FULL DATA MODEL ... NOT LEAST BECAUSE ALL OF THEM ... RELY ON PROP[erty attributes] The graph database's own constraint mechanism reaches only data properties, not structurewhat this limits: the graph-database alternative: CONSTRAINT ENFORCEMENT IN NEO4J ... IS INDEED LIMITED STRICTLY TO DATA PROPERTIES OF NODES AND RELATIONSHIPS, not structure The extension that would fix the property problem is not yet maturewhat this limits: the same scope as limitations[1] - the fix for the property problem is immature Linked-data stores are in no better position, having relied on ontologies alonewhat this limits: the linked-data alternative: LOD STORES ... HAVE SO FAR DEPENDED MORE OR LESS ENTIRELY ON ONTOLOGY SPECIFICATIONS, WITH LIMITATIONS AS DESCRIBED ABOVE schema - as DESCRIPTION: says what classes exist and how they may relate, which an ontology does well schema - as CONSTRAINT: forbids configurations that are well-typed and still wrong, which is what validation actually needs the graph problem - LOCAL: a property on a single node or relationship, which Neo4J can already enforce the graph problem - GLOBAL: a property of the whole graph, such as the edited text not looping back on itself, which nothing local can check OWL's purpose - as intended: open-world inference, deriving new facts from stated ones OWL's purpose - as wanted by editors: formalisation, description and consistency, which is a different job it was not built for claim_type: methoda second reading reaching the same value. Recorded: method — note: a second reading reaching the same value from a different sentence. Not applied - a person decides. builds-on → Andrews (2020), the 2020 attempt to build an ontology for the variant graph / Stemmarest extends → Vogeler (2021) on graph-based models for critical edition and the unexploited affordance of OWL builds-on → SHACL (Shapes Constraint Language), Knublauch and Kontokostas (2017) builds-on → RDF* (Arndt et al., 2021) critiques → the author's own 2020 attempt to build a variant-graph ontology critiques → the argument that graph databases lack the sustainability foundations of XML or relational schemas extends → Vogeler on graph-based models for critical edition supports → the codework literature arguing that code embodies scholarship SHACL —contrasted-with→ ontologystrength of the relation: 1SHACLontology RDF* —operationalised-as→ property attributesstrength of the relation: 1 Audit 2026-09-28: DOUBTFUL - read against its span and kept, but RDF* allows properties on relationships; operationalised-as 'property attributes' is the wrong type.RDF*property attributes property attributes —distinct-from→ OWLstrength of the relation: 1 Audit 2026-09-28: DOUBTFUL - read against its span and kept, but OWL does not handle property attributes; distinct-from paraphrases an inability.property attributesOWL witness —part-of→ traditionstrength of the relation: 1witnesstradition EVIDENCE CORRECTED (RE-GROUNDED) · stemma —part-of→ traditionEVIDENCE CORRECTED: RE-GROUNDED. The old span attested 'stemma' only inside 'Stemmarest', the TOOL'S OWN NAME - a run of letters, not the word. This clause writes both terms and states the containment in the paper's own verb: a stemma BELONGS TO a tradition. — strength of the relation: 1stemmatradition Stemmarest —operationalised-as→ variant graphstrength of the relation: 1 Audit 2026-09-28: DOUBTFUL - read against its span and kept, but Stemmarest USES the variant graph model; operationalised-as is the wrong type.Stemmarestvariant graph critical apparatus —part-of→ digital scholarly editionstrength of the relation: 1 Audit 2026-09-28: DOUBTFUL - read against its full span and kept, but the span says ontologies were proposed for aspects of digital scholarly edition and specifically for critical apparatus; part-of is loose.critical apparatusdigital scholarly edition An ontology could not express the variant graph model, because the model relies on property attributes that RDF and OWL handle badly. The 2020 project showed that ontologies, and OWL in particular, are inadequate as a validation model for graph-based data. The concern being answered is that graph databases lack the schema enforcement that gives XML and relational data their sustainability and interoperability.about this quote: THE QUOTE IS A CONCERN THE PAPER SETS OUT TO ADDRESS, NOT ITS FINDING - it completes a sentence that says the project was undertaken 'to address the concerns, frequently heard' that. an ontology can describe the model adequately and still be unable to constrain it, leaving the constraints in code the failure traces to RDF and OWL handling properties on relationships badly RDF* supplies the missing ability to put properties on relationships, though it is early SHACL constraints plus a transactional store can enforce the cross-object consistency an ontology cannot variant graphvariant graph SHACLSHACL RDF*RDF* variant graphvariant graph

In 2020 there was an attempt to create an ontology (Andrews, 2020) for 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. The 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) rely on property attributes, which RDF and OWL do not handle well and which can therefore not be suitably represented in an ontology definition.

Indeed, 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, they 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.

What the 2020 project showed, in the end, was the inadequacy of ontologies and especially OWL as a validation model for graph-based data. While 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. For 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. However, one of the important aspects of validation is to prevent inattentive mistakes in the data model. For 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. Even 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. Thus, 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.

Vogeler (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”. We 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. In this sense, the critics of graph-based models do have a point; how do we validate our graphs? Constraint enforcement in Neo4J, perhaps the most popular graph database, is indeed limited strictly to data properties of nodes and relationships (Neo4J, Inc., 2022). The 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.

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 RDF*, an extension to RDF that allows an entire triple to be the subject or object in further triple statements (Arndt et al., 2021). While 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.

The second major development is 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). This 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. In 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.

The 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.