Node Expressions, SHACL Functions and Custom Targets

A rule that can only state constants is a macro. A rule that can compute is an inference engine. The difference is node expressions, the value-producing sublanguage that runs underneath the whole of SHACL-AF. Once you can read them, functions and custom targets follow in an afternoon, and the three together turn a handful of rules into something you can maintain.

Node expressions: the little language

A node expression is anything that evaluates to a set of RDF nodes for a given focus node. The forms you will use daily are few. sh:this is the focus node itself. A constant is any literal or IRI written directly. A path expression, written as a blank node with sh:path and sh:nodes, walks a property path from a starting set, so [ sh:path ex:manufacturer ; sh:nodes sh:this ] yields the manufacturers of the focus node. A filter shape expression, with sh:filterShape and sh:nodes, keeps only the nodes that conform to a given shape. A function call invokes a SHACL function by IRI with its arguments. On top of those sit the set operations sh:union and sh:intersection, the conditional sh:if with sh:then and sh:else, and sh:exists for a boolean test.

Node expressions are also where the standard is moving: the Data Shapes Working Group has taken this sublanguage out of the Note and given it its own Recommendation-track Working Draft, SHACL 1.2 Node Expressions. They nest, which is the point. The object of a triple rule can be a path expression whose input is a filter shape expression whose input is a function call. Written as prose that stays readable: sh:object [ sh:path ex:ratedPower ; sh:nodes [ sh:filterShape ex:CertifiedShape ; sh:nodes [ sh:path ex:supersededBy ; sh:nodes sh:this ] ] ] . That is “the rated power of the certified thing that supersedes me”, expressed as data rather than as code in an application.

Node expressions also appear outside rules. In a property shape, sh:values declares that the values of a path are exactly those the expression produces, and sh:expression turns any node expression into a constraint that must evaluate to true. Both are quietly useful for the kind of derived-attribute checking that otherwise ends up in a bespoke script.

SHACL functions: naming logic you use twice

The moment the same expression appears in three shapes, it should be a function. A SPARQL-based function is declared with sh:SPARQLFunction, its arguments with sh:parameter, its result type with sh:returnType, and its body with a sh:select query that returns a single result variable. Because the declaration is RDF, the function is discoverable, documentable and versionable in the same repository as the shapes, and the same engine can call it from inside a SPARQL query as well as from a node expression.

The engineering benefit is not elegance, it is review. A named function with a stated signature and a test is something a colleague can approve. The same logic inlined into six CONSTRUCT queries is something a colleague skims and nods at.

Custom targets: reaching nodes that classes cannot

Core SHACL gives five ways to select focus nodes: by class, by explicit node, by subjects of a predicate, by objects of a predicate, and implicitly when a shape is itself a class. That covers most work and then hits a wall. What selects “every asset commissioned before 2010 that has no maintenance record”? Nothing in the core list.

SHACL-AF answers with sh:target and a SPARQL target: a sh:SPARQLTarget carrying a sh:select query that returns the variable ?this. Every binding of ?this becomes a focus node, which then feeds constraints and rules exactly as a class target would. When the same shape of selection recurs with different parameters, sh:SPARQLTargetType lets you declare it once and instantiate it with arguments, so that the target itself becomes a reusable, named thing rather than a copied query.

ex:ContractorEquipmentShape a sh:NodeShape ;
  sh:target [ a sh:SPARQLTarget ;
    sh:prefixes ex:shapes ;
    sh:select """
      SELECT ?this WHERE {
        GRAPH ex:g-contractor { ?this a ex:Equipment }
      } """ ] ;
  sh:property [ sh:path ex:serialNumber ; sh:minCount 1 ] ;
  sh:property [ sh:path ex:pumpModel ; sh:minCount 1 ] .

ex:shapes a owl:Ontology ;
  sh:declare [ sh:prefix "ex" ;
    # was: https://data.example.com/id/
    sh:namespace "https://data.example.org/id/"^^xsd:anyURI ] .

[ a sh:ValidationReport ; sh:conforms true ]

A working habit

Write the target first, and check what it selects before you attach a single constraint or rule to it. A rule that fires on the wrong focus nodes is not a broken rule, it is a broken target, and the symptom appears three steps downstream in triples nobody expected. The next lesson turns that habit into a process: provenance for what the rules produced, termination for the rules themselves, and an honest comparison with the other two engines you could have used instead.

Apply it to your work