Add SEP for Alignment of SPARQL Functions with ISO SQL Standard

[domel]

This PR adds a new SEP: “Alignment of SPARQL Built-in Functions with ISO SQL Standard Functions”.

Highlights

• Introduces SEP-XX (sparql-sql-functions.md).
• Proposes adding non-aggregate functions from ISO/IEC 9075:2023 (SQL:2023) to SPARQL.
• Covers:
  • String: TRIM, LPAD, RPAD, POSITION, LTRIM, RTRIM
  • Numeric: MOD, POWER, SQRT, EXP, LN, LOG10, SIN, COS, TAN
  • Date/Time: DATE_ADD, TIMESTAMPDIFF, INTERVAL
  • Logic: CASE, NULLIF
  • Comparative: GREATEST, LEAST
• Includes Appendix A: mapping table (SQL ↔ SPARQL 1.1).

Motivation

SPARQL 1.1 lacks many functions common in SQL. Aligning with ISO SQL:

• Improves interoperability with relational DBs.
• Eases adoption for SQL-trained developers.
• Increases query expressivity.

References

• ISO/IEC 9075:2023 (SQL:2023)
• W3C SPARQL 1.1 (2013)

[domel]

@afs and @TallTed your comments are welcome.

[namedgraph]

Why?? Most of these are either already supported or covered by Extending the lists of expected functions taken from new versions of XPath and XQuery and SEP-0002.

[afs]

There are two considerations:

1. It increases the work for implementers. Not all SPARQL engines are backed by commercial vendors. We may get partial implementations of SPARQL.
2. SQL != F&O. The evaluation models are different in the details, date/time handling is quite different.

[Tpt]

Isn't it already covered by xsd: duration that is supported by a few implementations?

[domel]

xsd:duration is indeed supported in some implementations, but it only provides the datatype. What is missing are standardized functions and operators (e.g., DATE_ADD, TIMESTAMPDIFF) that make such durations practically usable within queries across engines.

[domel]

Why?? Most of these are either already supported or covered by Extending the lists of expected functions taken from new versions of XPath and XQuery and SEP-0002.

You are right that some of the proposed functions are already supported or covered by SEP-0002 and the plan to adopt functions from XPath/XQuery.

However, the motivation here is slightly different:

• Explicit SQL alignment: Many developers come to SPARQL from SQL. Having familiar ISO SQL functions (TRIM, MOD, POWER, GREATEST, LEAST, etc.) explicitly included lowers the learning curve and improves interoperability with relational systems.
• Coverage gaps: Even with XPath/XQuery alignment, important SQL functions (DATE_ADD, TIMESTAMPDIFF, INTERVAL, NULLIF) remain unsupported. These are widely used in analytical and integration scenarios.
• Interoperability: RDF datasets are often queried alongside SQL databases. Providing equivalent function sets allows smoother query translation and hybrid use cases without ad-hoc workarounds.
• User experience: While in theory many operations could be offloaded to the backend or implemented in an external programming language, this is not always practical or desirable for end users who expect the query language itself to handle these operations directly.

I see this SEP as complementary to SEP-0002: the XPath/XQuery path ensures alignment with XML technologies, while this proposal highlights ISO SQL alignment. Both perspectives help broaden SPARQL’s adoption. Perhaps the SQL-related functions could be integrated as an extension to SEP-0002, or tracked separately for clarity.

[domel]

There are two considerations:

1. It increases the work for implementers. Not all SPARQL engines are backed by commercial vendors. We may get partial implementations of SPARQL.

2. SQL != F&O. The evaluation models are different in the details, date/time handling is quite different.

I agree that adding functions increases the burden on implementers, especially for non-commercial projects, so a staged or optional profile could help ease adoption while still improving interoperability. I also acknowledge that SQL and F&O differ in evaluation models, particularly for date/time. The aim is not strict equivalence but functional parity where it makes sense, with semantics adapted to RDF datatypes while staying close enough to SQL to support translation and interoperability.

[JervenBolleman]

comments on content

nullif

Instead of nullif I would first prefer to see UNDEF being allowed in more locations, and if not that the function was called undefif. RDF has no null, and SPARQL has UNDEF. So having such a function would be confusing.

SELECT ?test
WHERE
{ 
  BIND(1 AS ?a)
  BIND(1 AS ?b)
  BIND(IF(?a = ?b, ?a = ?b, UNDEF) AS ?test)
}

greatest/least

I think these functions should just be called min/max even if they are already aggregate functions. Which actually leads to a different request that aggregate functions could be used inside the where clause.

comment on merging

That said, I don't object for this SEP to exist, or be merged. I would like a few more links to relevant SQL concepts, or if no free/other source the postgresql documentation.

[niklasl]

Instead of nullif I would first prefer to see UNDEF being allowed in more locations, and if not that the function was called undefif. RDF has no null, and SPARQL has UNDEF. So having such a function would be confusing.

SELECT ?test
WHERE
{ 
  BIND(1 AS ?a)
  BIND(1 AS ?b)
  BIND(IF(?a = ?b, ?a = ?b, UNDEF) AS ?test)
}

I would also appreciate this (having resorted to e.g. ?_undef far too often).

[afs]

allowed in more locations

Let's enumerate the places.

BIND(IF(?a = ?b, ?a = ?b, UNDEF)

IF is already special.
What if SPARQL had an "if-then", with no "else" -- BIND(IF(?a = ?b, "equal!") AS ?test)?

[niklasl]

allowed in more locations

Let's enumerate the places.

BIND(IF(?a = ?b, ?a = ?b, UNDEF)

IF is already special. What if SPARQL had an "if-then", with no "else" -- BIND(IF(?a = ?b, "equal!") AS ?test)?

Good point! IIRC, that'd be enough for my cases (and certainly both simpler and easier to use).