SPARQL functions with SHACL (SPSH)

Scope

This ontology formalizes existing SPARQL 1.1 functions, operators, and symbols and does not introduce new SPARQL constructs.The scope of the SPSH ontology is limited to the SPARQL functions, operators, and symbols listed in Section 4.5 – SPARQL Functions. Not all of these are illustrated through use cases. The examples in Section 5 – Examples focus on a representative subset.

Conventions

The table below indicates the full list of namespaces and prefixes used in this document.

For readability, the following color-coded boxes are used in the examples throughout this document:

Conformance

This document is entirely non-normative. It does not define a specification, standard, or mandatory implementation.

The concepts, examples, and modelling patterns described here are provided for explanatory and illustrative purposes only.

Modeling approach

Each instance in the SPSH ontology represents uniquely a SPARQL function, operator or symbol found in the SPARQL 1.1 Query language. There is a consistent set of metadata properties that describe:

• basic identity (type, label, comment, seeAlso),
• parameter metadata (order, name, path, datatype, optional),
• execution-related information (prefixes, return type, and a SELECT query).

All instances of SPARQL functions are with capital letters for consistency with SPARQL documentation.

SPARQL Function structure

Each instance of sh:SPARQLFunction follows this structure:

SPARQL Function Parameter structure

Each parameter of a SPARQL Function is represented as a SHACL parameter node and uses the following properties:

Example

SPARQL Functions

The following SPARQL 1.1 functions, operators, and symbols are represented as instances of sh:SPARQLFunction in this ontology. Their behaviour and semantics follow the SPARQL 1.1 specification and are not redefined here.The SPARQL functions are split into three different tables: functions, operators and symbols. This split is only for readability purposes. All instances of the SPSH ontology use the same overall instance pattern and properties.

SPARQL Functions

SPARQL Operators

SPARQL Symbols

Limitations

The following limitations apply:

• OPTIONAL (see SPARQL 1.1 Query Language – Section 6) is not supported.
• Matching alternative patterns (UNION) or negating patterns (MINUS) (see SPARQL 1.1 Query Language – Section 7 and SPARQL 1.1 Query Language – Section 8) are not supported.
• Property paths (see SPARQL 1.1 Query Language – Section 9) are not supported. When needed, SHACL property paths can be used instead.
• Assignment functions (BIND and VALUES) (see SPARQL 1.1 Query Language – Section 10) are not supported. However, all functions behave as implicit BIND operations.
• FILTER is not supported.
• Aggregation functions (see SPARQL 1.1 Query Language – Section 11) and the associated aggregate algebra functions (see SPARQL 1.1 Query Language – Section 18.5) are not supported.
• Solution sequences and modifiers (see SPARQL 1.1 Query Language – Section 15) are not supported.
• SPARQL functions with a variable number of parameters (e.g., COALESCE) are modeled differently from the standard SPARQL structure. For limitations and implementation details, see the functions marked with * in Section 4.5 – SPARQL Functions.

To use the SPARQL functionalities listed above within sh:rule, it is recommended to use sh:SPARQLRule, which allows the definition of a full SPARQL query, rather than sh:TripleRule.

Derived/Computed property

In many datasets, certain values can be derived from other properties rather than being stored directly. Instead of requiring these values to be explicitly provided in the data, they can be computed automatically using SHACL rule-based constructs. This approach can improve data consistency and reduce redundancy by ensuring that derived values are calculated in a uniform way.

In the example below, a rule computes a person’s age from their recorded birth year. The rule applies to all instances of ex:Person. For each focus node, the value of ex:age is calculated by subtracting the value of ex:birthYear from the current year. This is expressed using a sh:TripleRule, where the subject of the generated triple is the focus node (sh:this), the predicate is ex:age, and the object is computed using a chain of functions.

Once these triples are generated, they may also influence validation or querying. For example, shapes or queries that rely on the presence of ex:age can operate on the computed values even if the age was not explicitly stored in the original dataset. This depends on the execution model of the SHACL engine, for example the rules must be executed before performing validation.

Default value computation

In many datasets, some properties are frequently left empty because their values are either obvious from context or follow a domain-wide convention. Instead of requiring users to fill in these values manually, SHACL rule-based constructs can automatically populate them with default values. These defaults can be static or derived dynamically from other properties. This approach ensures data completeness, improves consistency, and reduces errors in validation or querying.

In the example below, a shipping company has a rule for its orders: the shipping method is by default standard unless the customer explicitly requests express shipping. However, for heavy parcels above 10 kilograms, the shipping becomes by default express. This scenario can be implemented as a sh:TripleRule, where the shipping method is computed dynamically using an IF function.

Normalization

In many datasets, the same conceptual value may be recorded in different properties, or in slightly different formats. This can happen when data comes from multiple sources, systems, or historical records. A normalization activity is the process of unifying these multiple representations into a single canonical property or format, ensuring consistency and simplifying querying, reporting, and downstream processing.

For example, a person’s last name might be recorded under different properties such as lastName, surname, and/or familyName. Rather than leaving these values scattered across the dataset, a normalization activity can select a single value on a preferred order, and store it in a canonical property, such as normalisedLastName. This ensures that queries and applications always see the same, consistent value for the last name, regardless of which original property it came from.

The example below shows how this can be implemented using a the SPARQL COALESCE function, which automatically picks the first available value from the prioritized list of properties.

Note on SPARQL Function with multiple parameters

Functions like COALESCE, CONCAT, and IN, support only two parameters at a time. In that case, it is suggested to nest multiple COALESCE functions to handle more values.

Denormalization

In some datasets, related values are represented as separate nodes that contain an explicit order or sequence number. While this structure provides flexibility for modelling ordered lists, it may require additional joins or path expressions when querying the data.

A denormalisation activity can simplify access to such information by rolling up these values directly onto the main resource. Using SHACL rule-based constructs, new predicates can be constructed dynamically based on the sequence number of each related value.

In the example below, an order contains several items, each associated with a sequence number. A SHACL rule generates predicates such as ex:item_1, ex:item_2, and ex:item_3, allowing the ordered items to be accessed directly from the order resource without traversing the intermediate nodes.