Shapes Constraint Language

Shapes Constraint Language for Checking Health Data

SHACL is the W3C language for checking a graph of RDF data against a set of written conditions, published as a W3C Recommendation on 20 July 2017. The conditions are grouped into shapes, which are recorded in RDF themselves, and a SHACL processor compares a data graph with a shapes graph and returns a validation report that names each node that failed and the condition it broke. For health economists the language matters once linked hospital records, trial extracts or model inputs sit in a graph and are about to be analysed, because a missing discharge date or a cost stored as text may load without complaint and still alter a length of stay or a mean cost.

Why RDF data needs its own checking language

The SHACL specification says that "the RDF data model offers a huge amount of flexibility", since any node can in principle have values for any property. Hogan and colleagues explain that semantic schemas such as RDF Schema and OWL are usually read under the open world assumption, in which a missing edge does not mean that the relationship is false, and they contrast them with validating schemas, used where some part of the data must be complete. Semantic schemas allow new graph data to be inferred, whereas validating schemas allow existing graph data to be checked. A cost study needs to know that every admission carries an admission time, a discharge time and a cost, and an OWL ontology read under the open world assumption does not report the records that lack them. SHACL fills that role, and the specification states that full RDFS inferencing is not required to use it.

Shapes, targets and focus nodes

SHACL Core has two kinds of shape. A node shape constrains the focus node itself, while a property shape constrains the values reached from the focus node along a path, such as the discharge times of an admission.

Targets say which nodes a shape applies to. Target declarations can pick out named nodes, every instance of a class, every subject of a given property or every object of a given property. Each node picked out becomes a focus node, and the values reached along a property shape's path are its value nodes.

Class targets follow subclass links present in the data graph. A node counts as a SHACL instance of a class when its type is that class or a subclass reached through a chain of subclass statements, and the specification expects the data graph to include all the subclass triples. A shape aimed at admissions therefore reaches records typed only as emergency admissions when the triple making emergency admission a subclass of admission sits in the graph being checked.

Core constraint components for health data checks

Each condition in a shape is set through a constraint component, and SHACL Core defines the components that every processor must support. When a shape uses several, all of them apply.

The datatype component rejects ill-typed literals as well as wrong datatypes, so a decimal-typed cost written as "2,450 GBP" fails. The allowed-values component matches literals exactly, and the specification notes that a byte written "04" does not match the integer 4, so codes must be stored in the same form as the list.

Validation reports, severity and messages

The validation report is itself an RDF graph. Its conforms value is true if and only if validation produced no results, and each result must record the focus node, the severity and the constraint component that caused it, with the path, the offending value and a message as optional extras.

SHACL defines three severities, info, warning and violation, and a shape without a stated severity produces violations. The specification states that severity values have no effect on validation itself, so a graph that produces only warnings still does not conform. Messages written on a shape are copied into each result it produces, which lets a data team explain a failed rule in plain language. Processors may limit the number of results returned for large datasets, so a short report from such a run does not prove that few records fail.

SHACL Core, SHACL-SPARQL and later work

The specification is split into SHACL Core, which all implementations must support, and SHACL-SPARQL, which adds constraints written as SPARQL SELECT queries and a way to declare new constraint components. None of the Core components adds up values, so a check that the costs of an episode's items sum to the episode total would need a SPARQL-based constraint. Validation with recursive shapes is left undefined, so processors may support it or report a failure, and recursive shapes may not behave the same way in every tool.

SHACL Advanced Features, a W3C Working Group Note of 8 June 2017, adds features such as functions and rules without Recommendation status. The Data Shapes Working Group is preparing SHACL 1.2 as a family of documents. The SHACL 1.2 Core Working Draft is dated 2 November 2026 and should be cited only as work in progress, so the 2017 document remains the latest Recommendation.

Documented uses in health data infrastructures

The Swiss Personalized Health Network, which Touré and colleagues describe as a government-funded initiative for the secondary use of health data, publishes an RDF schema that data providers follow when transforming health data. Its quality control rests mainly on SHACL rules, generated automatically from the schema by an in-house tool, together with template SPARQL queries, and a quality check tool turns the results into a human-readable report. The authors also report that a lack of knowledge of linked data technologies is not uncommon in the clinical domain, so providers and users need extra training.

Declerck and colleagues tested SHACL validation in the AIDAVA framework on 13,607 admissions from the MIMIC-III critical care database. Without added noise, time sequence consistency scored 99.9 per cent (13,594 of 13,607 admissions), and the errors were mainly discharge times recorded earlier than admission times, which the authors call a known artefact of MIMIC-III. A key finding was that consistency scores alone cannot be fully trusted without adequate completeness, because some contradictions may go undetected when the data needed to see them are missing. For real-world data drawn from an electronic health record, these checks come before any length of stay or episode cost is computed.

The HL7 FHIR R5 specification uses Shape Expressions (ShEx), not SHACL, to define and validate FHIR RDF, and ShEx 2.1 is a Community Group report, not a W3C standard.

Worked example checking an admissions costing extract

All identifiers, dates and costs here are hypothetical and illustrative. An analyst loads five admission records into an RDF graph and validates it against one node shape whose class target is Admission, where ex stands for the analyst's namespace and every recorded time is a typed date and time literal (the XSD dateTime datatype).

Step 1. A1 and A5 meet every condition and produce no results.

Step 2. A2's admission time is later than its discharge time, so the lessThan component produces one result.

Step 3. A3 has no discharge time, so the minCount component on the discharge path produces one result. The lessThan component compares pairs of values, and with no discharge time there is no pair, so it produces nothing for A3.

Step 4. A4's cost is a string, so the datatype component produces one result. The comparison of 0 with that string does not return true, so the minInclusive component produces a second result.

Step 5. The report holds 4 results on 3 focus nodes, A2, A3 and A4, and its conforms value is false.

Step 6. Declerck and colleagues score each rule category as

$$Q = 1 - e, \qquad e = \frac{v}{n}$$

where $Q$ is the quality score for a category, $e$ is its error rate, $v$ is the number of violations and $n$ is the number of checked nodes. For time sequence, counting all five admissions as checked gives

$$Q = 1 - \frac{1}{5} = 1 - 0.20 = 0.80$$

where 1 is A2's violation and 5 is the number of admissions. A3 could not be compared, so counting only the admissions with both times gives

$$Q = 1 - \frac{1}{4} = 1 - 0.25 = 0.75$$

where 4 is the number of admissions with both times, so the missing value in A3 raised the apparent score.

Step 7. An analysis that silently dropped A4's text value would average the four decimal costs, $(2100 + 3400 + 1800 + 2900) / 4 = 10200 / 4 = 2550$, or GBP 2,550 per admission. Correcting A4 to the decimal 2450.00 gives $(10200 + 2450) / 5 = 12650 / 5 = 2530$, or GBP 2,530. The report shows which records failed, while the decision to correct, exclude or query them stays with the analyst and belongs in the methods of the economic evaluation.

Choices that change what a validation reports

The level of inference changes which nodes are checked. A shapes graph can declare the entailment it needs, processors may but need not support entailment regimes, and a processor that meets an unsupported one must signal a failure. Hogan and colleagues add that inference before validation can bring more nodes under a shape's target, so the shapes may need adapting and open shapes may be preferred.

A closed shape rejects any property it does not list. That suits a fixed extract specification, while a source that adds a field makes every record fail. A shape that does not suit a local context can be switched off with the deactivated flag, so shapes written by others can be reused. The specification's security section warns that triples from outside an organisation's network of trust can change what shapes mean, and it names trusted, verified sources as the protection.

What conformance does and does not show

Conformance means that the data meet the conditions written in the shapes graph, and no more. A record can conform and still be wrong, and a well-formed extract can still be unfit for the decision at hand, since data quality is judged against a specific use. Declerck and colleagues note that domain rules need expert consensus, and because MIMIC-III lacks the quality problems typical of routine systems, they tested their rules mainly on injected noise. Shapes also say nothing about why values are absent, which is the question missing data methods address.

SHACL validation is also distinct from model validation, which asks whether a decision model is accurate and credible for its purpose. A shapes graph can confirm that every model input carries a value, a datatype and a source reference, but it cannot judge whether the source was the right one for a health technology assessment.

An OWL ontology states what follows from the data, while SHACL states what the data must contain. The SKOS Reference, for example, sets the integrity condition that a resource has no more than one preferred label per language tag, and a property shape using uniqueLang could test that condition on HEO, the HealthEconomics.wiki concept scheme. Shapes do not make two systems agree on meaning, so they add to digital interoperability only when the vocabularies behind them are shared.

Sources

• Declerck J, Kılıç ÖD, Emir Erol E, Mehryar S, Kalra D, de Zegher I, Celebi R. Assessing data quality in heterogeneous health care integration: simulation study of the AIDAVA framework. JMIR Medical Informatics. 2025;13:e75275. https://doi.org/10.2196/75275
• HL7 International. FHIR Release 5 (v5.0.0), section 2.1.6.6, Resource Description Framework (RDF) Representation. 2023. https://hl7.org/fhir/rdf.html
• Hogan A, Blomqvist E, Cochez M, et al. Knowledge graphs. ACM Computing Surveys. 2021;54(4):1-37. Section 3.1.2, Validating schema. https://doi.org/10.1145/3447772 (text checked in the extended version, arXiv 2003.02320v6)
• Knublauch H, Allemang D, Steyskal S, eds. SHACL Advanced Features. W3C Working Group Note, 8 June 2017. https://www.w3.org/TR/shacl-af/
• Knublauch H, Bergwinkl T, Taghzouti Y, Wright J, eds. SHACL 1.2 Core. W3C Working Draft, 2 November 2026. https://www.w3.org/TR/shacl12-core/
• Knublauch H, Kontokostas D, eds. Shapes Constraint Language (SHACL). W3C Recommendation, 20 July 2017. https://www.w3.org/TR/shacl/
• Miles A, Bechhofer S, eds. SKOS Simple Knowledge Organization System Reference. W3C Recommendation, 18 August 2009. Section 5.4, Integrity Conditions. https://www.w3.org/TR/skos-reference/
• Prud'hommeaux E, Boneva I, Labra Gayo JE, Kellogg G, eds. Shape Expressions Language 2.1. Final Community Group Report, 8 October 2019. http://shex.io/shex-semantics/
• Touré V, Krauss P, Gnodtke K, et al. FAIRification of health-related data using semantic web technologies in the Swiss Personalized Health Network. Scientific Data. 2023;10:127. https://doi.org/10.1038/s41597-023-02028-y