Tara Lee AndrewspersName (2023date). “Graph schema validation at last? Revisiting the Stemmarest data model with Neo4J and SHACL.” Digital Humanities 2023 (DH2023), Graztitle·a, GrazplaceName.
Object of study — The variant graphterm·dom data model used to represent text collations, and whether its constraints can be expressed formally.
Research question — Can a graph-based scholarly data model be validated with the same rigour as a TEI XMLterm·mth or relational schema?
Contribution — Shows where OWLterm·dom fails as a validation language for graph data, and what a constraint language has to do instead.
phenomenon · claim-type · cross-domain-transfer · mechanism · claim-relation · replication-status · limitation — grounded in the full text| phenomenon | graph schema validation — “In this sense, the critics of graph-based models do have a point; how do we validate our graphs?” | |
| claim-type | method — “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.” | |
| method — evidence | — “Recently, however, there have been two intriguing developments in the Semantic Web world that are especially relevant to digital humanities projects, not least Stemmarest.” | |
| object of study — evidence | — “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.” | |
| mechanism | An ontology describes what kinds of thing exist and how they relate, but cannot forbid a combination that is well-typed and still wrong — “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.” | mechanisms[0] |
| mechanism | The hard constraints are cross-object: an entity appearing in one structure must be consistent with its membership elsewhere — “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.” | mechanisms[1] |
| mechanism | Some constraints are global properties of the whole graph and cannot be checked object by object at all — “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.” | mechanisms[2] |
| mechanism | 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 — “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.” | mechanisms[3] |
| mechanism | Constraints only bite if the store can undo a rejected write, so validation needs transactions and rollback underneath it — “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.” | mechanisms[4] |
| mechanism | Allowing arbitrary code inside constraints erases the code/data boundary that sustainability practice depends on, which the author treats as a feature — “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.” | mechanisms[5] |
| builds-on | Andrews (2020), the 2020 attempt to build an ontology for the variant graph / Stemmarest — “What the 2020 project showed, in the end, was the inadequacy of ontologies and especially OWL as a validation model for graph-based data.” | claim_relations[0] |
| extends | Vogeler (2021) on graph-based models for critical edition and the unexploited affordance of OWL — “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.” | claim_relations[1] |
| builds-on | SHACL (Shapes Constraint Language), 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.” | claim_relations[2] |
| builds-on | RDF* (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.” | claim_relations[3] |
| critiques | the author's own 2020 attempt to build a variant-graph ontology — “What the 2020 project showed, in the end, was the inadequacy of ontologies and especially OWL as a validation model for graph-based data.” | claim_relations[4] |
| critiques | the argument that graph databases lack the sustainability foundations of XML or relational schemas — “In this sense, the critics of graph-based models do have a point; how do we validate our graphs?” | claim_relations[5] |
| extends | Vogeler on graph-based models for critical edition — “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”.” | claim_relations[6] |
| supports | the codework literature arguing that code embodies scholarship — “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.” | claim_relations[7] |
| sense | schema - as DESCRIPTION: says what classes exist and how they may relate, which an ontology does well — “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.” | senses[0] |
| sense | schema - as CONSTRAINT: forbids configurations that are well-typed and still wrong, which is what validation actually needs — “However, one of the important aspects of validation is to prevent inattentive mistakes in the data model.” | senses[1] |
| sense | the graph problem - LOCAL: a property on a single node or relationship, which Neo4J can already enforce — “Constraint enforcement in Neo4J, perhaps the most popular graph database, is indeed limited strictly to data properties of nodes and relationships (Neo4J, Inc., 2022).” | senses[2] |
| sense | 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 — “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.” | senses[3] |
| sense | OWL's purpose - as intended: open-world inference, deriving new facts from stated ones — “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”.” | senses[4] |
| sense | OWL's purpose - as wanted by editors: formalisation, description and consistency, which is a different job it was not built for — “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.” | senses[5] |
| edge | SHACL —contrasted-with→ ontology — “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.” | concept_edges[0] |
| audit | RDF* —operationalised-as→ property attributes — 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. — “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.” | concept_edges[2] |
| audit | property attributes —distinct-from→ OWL — Audit 2026-09-28: DOUBTFUL - read against its span and kept, but OWL does not handle property attributes; distinct-from paraphrases an inability. — “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.” | concept_edges[3] |
| edge | witness —part-of→ tradition — “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.” | concept_edges[4] |
| retracted | EVIDENCE CORRECTED (RE-GROUNDED) · stemma —part-of→ tradition — 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. — “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.” — “For example, in the Stemmarest ontology we can say that” | concept_edges[5] |
| audit | Stemmarest —operationalised-as→ variant graph — Audit 2026-09-28: DOUBTFUL - read against its span and kept, but Stemmarest USES the variant graph model; operationalised-as is the wrong type. — “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.” | concept_edges[8] |
| audit | critical apparatus —part-of→ digital scholarly edition — 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. — “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.” | concept_edges[11] |
| for which use | limitation — 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 — “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.” | limitations[0] |
| for which use | limitation — the interoperability half of the proposal: RDF* IS STILL IN AN EARLY PHASE OF DEVELOPMENT — “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.” | limitations[1] |
| for which use | limitation — the sustainability claim for SHACL: constraint components CHALLENGE THE IDEA OF THE SEPARATION OF PROGRAM CODE AND DATA THAT IS THE USUAL GOLD STANDARD — “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.” | limitations[2] |
| for which use | limitation — 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 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.” | limitations[3] |
| for which use | limitation — the graph-database alternative: CONSTRAINT ENFORCEMENT IN NEO4J ... IS INDEED LIMITED STRICTLY TO DATA PROPERTIES OF NODES AND RELATIONSHIPS, not structure — “Constraint enforcement in Neo4J, perhaps the most popular graph database, is indeed limited strictly to data properties of nodes and relationships (Neo4J, Inc., 2022).” | limitations[4] |
| for which use | limitation — the same scope as limitations[1] - the fix for the property problem is immature — “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.” | limitations[5] |
| for which use | limitation — the linked-data alternative: LOD STORES ... HAVE SO FAR DEPENDED MORE OR LESS ENTIRELY ON ONTOLOGY SPECIFICATIONS, WITH LIMITATIONS AS DESCRIBED ABOVE — “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.” | limitations[6] |
| replication | untested | |
| limitation | 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. — “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.” | limitations[0] |
| limitation | RDF*, the extension the interoperability half of the proposal depends on, is acknowledged to be immature. — “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.” | limitations[1] |
| limitation | SHACL's SPARQL/Javascript constraint components undermine the separation of code from data that sustainability practice normally treats as the gold standard. — “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.” | limitations[2] |
| limitation | The 2020 ontology attempt failed because RDF and OWL handle property attributes badly, and the model depends on them — “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.” | limitations[3] |
| limitation | The graph database's own constraint mechanism reaches only data properties, not structure — “Constraint enforcement in Neo4J, perhaps the most popular graph database, is indeed limited strictly to data properties of nodes and relationships (Neo4J, Inc., 2022).” | limitations[4] |
| limitation | The extension that would fix the property problem is not yet mature — “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.” | limitations[5] |
| limitation | Linked-data stores are in no better position, having relied on ontologies alone — “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.” | limitations[6] |
finding · quantity · variable · definition · key-term — grounded in the full text| finding | An ontology could not express the variant graph model, because the model relies on property attributes that RDF and OWL handle badly. — “rely on property attributes, which RDF and OWL do not handle well and which can therefore not be suitably represented in an ontology definition” | content_tags.findings[0] |
| finding | The 2020 project showed that ontologies, and OWL in particular, are inadequate as a validation model for graph-based 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.” | content_tags.findings[1] |
| finding | The concern being answered is that graph databases lack the schema enforcement that gives XML and relational data their sustainability and interoperability. — “they lack the foundations for sustainability and interoperability that TEI XML schemas or, indeed, relational database schemas provide” | content_tags.findings[2] |
| evidence status note | finding — 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. | content_tags.findings[2] |
| finding | an ontology can describe the model adequately and still be unable to constrain it, leaving the constraints in code — “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.” | content_tags.findings[3] |
| finding | the failure traces to RDF and OWL handling properties on relationships badly — “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.” | content_tags.findings[4] |
| finding | RDF* supplies the missing ability to put properties on relationships, though it is early — “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.” | content_tags.findings[5] |
| finding | SHACL constraints plus a transactional store can enforce the cross-object consistency an ontology cannot — “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.” | content_tags.findings[6] |
| definition | variant graph — “the variant graph, which is a data model used in tools such as CollateX” | content_tags.definitions[0] |
| definition | SHACL — “SHACL (Shapes Constraint Language), a language whose purpose is to define a set of constraints against which RDF graphs can be validated” | content_tags.definitions[1] |
| definition | RDF* — “RDF*, an extension to RDF that allows an entire triple to be the subject or object in further triple statements” | content_tags.definitions[2] |
| definition | variant graph — “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” | content_tags.definitions[3] |
| key-terms | variant graph, ontology, OWL, SHACL, schema validation, interoperability, property attributes, RDF*, Neo4J, Stemmarest, witness, stemma, tradition, sustainability, codework, SPARQL, TEI XML |
| claim type | method — a second reading reaching the same value; recorded: method — “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).” | alternatives.claim_type |
Full text — tagged
The reference list is not part of the text we hold for this paper. Our copy was extracted from the publisher's page and the bibliography did not survive that extraction, so the article below ends before its references. Nothing has been removed by us.
In 2020 there was an attempt to create an ontologyterm·dom (AndrewspersName, 2020) for the variant graphterm·dom, which is a data model used in tools such as CollateX (Haentjens Dekker et al., 2015), Stemmarestterm·mth (AndrewspersName, 2019), and TraVIZ (Jänicke et al., 2015) to represent and visualize text collations and certain sorts of annotation. The conclusion was that the ontologyterm·dom was not suitable for expressing the full data model employed in variant graphsterm·dom, not least because all of them (Stemmarestterm·mth most heavily) rely on property attributesterm·mth, which RDF and OWLterm·dom do not handle well and which can therefore not be suitably represented in an ontologyterm·dom definition.
Indeed, although ontologies have in the meantime been proposed for various aspects of digital scholarly editionterm·dom (NIE-INE, 2019) and specifically for critical apparatusterm·dom (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 sustainabilityterm·dom and interoperabilityterm·dom that TEI XMLterm·mth 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 OWLterm·dom as a validation model for graph-based data. While many of the classes used by Stemmarestterm·mth and their relationships to each other can be described adequately in OWLterm·dom, the model relies upon many additional constraints that, while seemingly simple, go beyond OWLterm·dom’s capabilities. For example, in the Stemmarestterm·mth ontologyterm·dom we can say that a Witnessterm·dom can belong to a Traditionterm·dom and also to one or more Stemmata, and that a Traditionterm·dom 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 witnessterm·dom W appears in a stemmaterm·dom belonging to traditionterm·dom A, the model software should ensure that W also belongs to traditionterm·dom A as a witnessterm·dom and not, for example, an unrelated traditionterm·dom B; moreover, W should not appear in any stemmata of traditionterm·dom B. Even more intractable problems arise with more complex specifications: for example, the need to ensure that the variant graphterm·dom 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 Stemmarestterm·mth ontologyterm·dom 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 OWLterm·dom is not really exploited in Digital Scholarly Editionsterm·dom”. We would argue here that most editors are less interested in the sort of open-world inference for which OWLterm·dom 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 Neo4Jterm·mth, perhaps the most popular graph database, is indeed limited strictly to data properties of nodes and relationships (Neo4Jterm·mth, Inc., 2022). The situation is hardly better for LOD stores, which have so far depended more or less entirely on ontologyterm·dom 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 Stemmarestterm·mth. The first of these is RDF*term·mth, 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*term·mth 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 Neo4Jterm·mth have always provided; this in turn has opened the way for Stemmarestterm·mth, and many other projects besides, to take advantage of Neo4Jterm·mth’s powerful graph traversal and analysis algorithms while preserving full interoperabilityterm·dom with LOD formats.
The second major development is SHACLterm·mth (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 Neo4Jterm·mth, a set of SHACLterm·mth constraints can ensure the consistency of data added to the graph, so that (to take the example above) a witnessterm·dom from one text traditionterm·dom cannot be included in a stemmaterm·dom belonging to an entirely different traditionterm·dom.
Perhaps the most intriguing feature of SHACLterm·mth is the ability to include “constraint components” expressed in SPARQLterm·mth 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 sustainabilityterm·dom 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 SHACLterm·mth model thus provides a fascinating way to bring the intellectual contributions inherent in codeworkterm·dom (Zundert, 2016; Antonijevic Ubois, van Zundert, and AndrewspersName, 2018) across the “sustainabilityterm·dom 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.