SPARQL VERSION semantics

[jitsedesmet]

Hi all, second issue, and again, great work!

The background is the same as here: #240, I implemented the VERSION announcement.
While implementing it, I found choosing to use a string for the version a peculiar choice - of course I understand it from a UX point of view.
So I started wondering whether the versions declared as strings in the VERSION clause could implicitly be transformed into IRIs.

The use of IRIs, beside being best practice, has some interesting consequences, since it allows us to define relationships between various versions (outside of SPARQL spec versions, see vendor-specific versions, but also things like GeoSPARQL and C-SPARQL)
An example relation would be the definition of what version a SPARQL endpoint operates on (probably described in the service description , although I do not see something like that right now?)
Such definitions would allow you to provide reasoning rules that an endpoint supporting SPARQL 1.2 also supports SPARQL 1.1 queries.
This could facilitate better interoperability between SPARQL versions with minimal cost for the implementor to expose the version (same as now).
These version definitions might then also be usable for vendor specific SPARQL versions, where various vendors slightly modify the SPARQL grammar, using IRIs and semantics in general, one could describe how these various versions differ from one another.

By providing a bijection between the version string and an IRI, we can more easily talk about query versions.
This bijection could simply involve the WG choosing a namespace and then using URL-encoding/ Percent-encoding on the string provided in the version clause.

[afs]

It is a string to give uniformity with use in the media type parameter.

[jitsedesmet]

@afs Thank you for the reply. I think having it a string is not a bad choice. I just wonder whether the SPARQL spec could create a mapping from the string to a URI, allowing the semantic web community to capture the SPARQL versions as entities.

Example:
The spec could choose some namespace like <https://example.org/sparql-version#>
And say to get the IRI representation of the VERSION string you take the percent encoding of the string and append it such that that string "1.2-basic" maps to the concept IRI <https://example.org/sparql-version#1.2-basic>. Now that the version has a persistent identifier, we can assert facts on it.

[Tpt]

I think we already have URIs for SPARQL versions in the Service Description vocabulary (example). It's true that using strings here for something that should be a quite controlled vocabulary is a bit weird.

[constraintAutomaton]

Dear @afs,

Thank you for your reply.

I was curious about the importance of maintaining uniformity with the media type parameter in that context. From my understanding, the version is already declared inline with the query ¹:

VERSION "1.2"
PREFIX : <http://example/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?s ?date {
    ?s ?p ?o .
    BIND( <<( ?s ?p ?o )>> AS ?tt )
    :myreifier rdf:reifies ?tt .
    :myreifier :tripleAdded ?date .
}

Given this, and especially considering that the following line includes a PREFIX declaration (an IRI), I'm not entirely sure why this limitation is necessary. However, I may not understand the full context.

It seems to me that the potential benefits of allowing an IRI in this position, such as improved interoperability between vendors, SPARQL version alignment, and extensibility, could outweigh the potential drawbacks. I’m very open to learning more about the rationale behind the current approach.

Footnotes

1. https://www.w3.org/TR/sparql12-query/#syntaxVersionAnnouncement ↩

[rubensworks]

@constraintAutomaton The media type version parameter is not described in the SPARQL query spec. It's currently being written up for the SPARQL protocol spec: w3c/sparql-protocol#34
What is being written there should clarify part of your question.

[jitsedesmet]

It's true that using strings here for something that should be a quite controlled vocabulary is a bit weird.

@Tpt , I agree, although I also think adding the version declaration could allow the SPARQL spec to embrace the open world of true SPARQL endpoints, where different vendors will support different SPARQL versions and dialects. This aligns with what @constraintAutomaton talks about, I think.

[afs]

I think we already have URIs for SPARQL versions in the Service Description vocabulary (example). It's true that using strings here for something that should be a quite controlled vocabulary is a bit weird.

We could put them in the SPARQL NS document.
I'll make a PR for discussion.

[afs]

From my understanding, the version is already declared inline with the query

It may be declared inline for a SPARQL Query. The content negotiation parameter is another mechanism for one request and it applies to plain GET of data and the SPARQL Graph Store Protocol.

Having the version in RDF data (and, to a less extent, queries/updates) is also metadata for the long term record.

That's a different requirement to version= in the Accept header which is content negotiation.

Because 1.2 only adds features, there isn't a necessity to have a version mechanism.

My reading is that we have it because there is "1.2" and "1.2-basic" making sufficient reason to provide VERSION.

"1.2-basic" exists for semantic extensions to RDF and other standards that build on RDF otherwise we need to update the whole stack at once. Fortunately, SHACL and JSON-LD are active at the moment but OWL, for example, isn't.

As we are doing one, we can make it for future version of RDF standards as well.

FYI:
RDF 1.0 to RDF 1.1 had a change that affected data and it wasn't incremental. It was done carefully and happened smoothly.
SPARQL 1.0 to SPARQL 1.1 added a large number of features and happened smoothly.

It seems to me that the potential benefits of allowing an IRI in this position, such as improved interoperability between vendors, SPARQL version alignment, and extensibility, could outweigh the potential drawbacks. I’m very open to learning more about the rationale behind the current approach.

VERSION is specifically for the evolution of RDF and SPARQL standards. It is expected that there would be few of versions, and a linear evolution. There is a controlled vocabulary for versions owned by the RDF & SPARQL Working Group.

This is standards work. W3C is a relative late stage standardization organisation. It defines world-wide standards based on prior work or (less commonly) an established need for a new "1.0". It is not speculative. That's is what outside work or CGs provide.

Specifically, "1.2" is all of the new work - not a set of choices.

"extensibility" other than future standards is not an objective for this working group.

different SPARQL versions and dialects

There is SPARQL Service Description.
There is also media types.

[jitsedesmet]

different SPARQL versions and dialects

There is SPARQL Service Description.
There is also media types.

I'm sorry to ask, but I don't see why the same argument does not apply to the VERSION declaration itself?
What is the goal of the VERSION declaration and how does it differ from what you put in the Service description or content-type header (media types)? Why do we need a special VERSION declaration that is spec specific and does not provide semantics?

[afs]

The goal is not to support vendor-specific extensions/dialects/restrictions/... That is the route to chaos and silos as well as barriers to adoption.

VERSION is specifically for the evolution of RDF and SPARQL standards.

Yes, I'm sure some one will use the string for something else but that does not mean we have to support or encourage it. It is not different to using a non-standard URI. Except you can so easily look for it - NB VERSION as first line seems sensible and that means no prefixes + greping, or head -1, for VERSION is insufficient if you then also have to deal with prefixed names.

[afs]

These version definitions might then also be usable for vendor specific SPARQL versions, where various vendors slightly modify the SPARQL grammar, using IRIs and semantics in general, one could describe how these various versions differ from one another.

It seems to me that the potential benefits of allowing an IRI in this position, such as improved interoperability between vendors, SPARQL version alignment, and extensibility, could outweigh the potential drawbacks.

@jitsedesmet, @constraintAutomaton - let me set you a friendly challenge.

Show a concrete example where you want to talk about the version.

Not the "SPARQL Query version 1.2" but the version itself.

[constraintAutomaton]

Dear @afs,

First I want to address that what you wrote:

The goal is not to support vendor-specific extensions/dialects/restrictions/... That is the route to chaos and silos as well as barriers to adoption.

I strongly agree with your point about avoiding silos, I also believe it is an important goal and worth emphasizing. However, when reviewing the service description, it seems that the specification does allow for custom language features ¹.

In that sense, the spec already seems to permit the use of extensions and dialects. Given this, I believe it would be valuable to introduce a way for the query issuer to declare which extension or dialect they expect their query to be interpreted and I believe that versioning with semantic through IRI is a well suited mechanism.

That said, I might not understand how the versioning approach is intended to differ fundamentally from what’s already described in the service description.

To answer the second question.

Virtuoso offers full-text search capabilities ², Apache Jena supports CONSTRUCT QUAD queries ³, and Oxigraph provides extended date-time-functionality including the ADJUST function ⁴. ⁵

These are all examples of features from popular SPARQL engines that modify the algebra of SPARQL, unlike SPARQL's built-in support for extension functions ⁶.

What I propose is that vendors define their own custom SPARQL version IRIs. For example: <http://example.org#jena_1_2>

This version IRI would declare itself as an extension of SPARQL 1.2 and semantically describe its additional features:

@prefix ex: <http://example.org#> .

ex:jena_1_2 a ex:SparqlVersion ;
    ex:superSet ex:sparql1_2 ;
    ex:extendsWithFeature ex:constructQuad .

ex:constructQuad a ex:ExtendedSparqlFeature .

This approach allows a query issuer to specify that their query is meant to be interpreted using ex:jena_1_2, and expect an endpoint supporting that version. Alternatively, a user could specify that their query is valid under SPARQL 1.2, 1.1, or 1.0 and due to the semantic relationships, a vendor could easily determine whether their engine can safely process that query even if they declare themselves to be an extension of SPARQL.

Footnotes

1. https://www.w3.org/TR/sparql12-service-description/#sd-languageExtension ↩

2. https://docs.openlinksw.com/virtuoso/sparqlextensions/#rdfsparqlrulefulltext ↩

3. https://jena.apache.org/documentation/query/construct-quad.html#Grammar ↩

4. https://github.com/oxigraph/oxigraph/wiki/SPARQL#sep-0002-calendar-and-duration-operations ↩

5. (preprint) https://traqula-demo-semantics-2025.jitsedesmet.be/ ↩

6. https://www.w3.org/TR/sparql11-query/#extensionFunctions ↩

[afs]

Thank you for the background - it makes some of the earlier comments clearer.

Discovering endpoints is the role of service description and I'd expect that layer to be making choices as to which
endpoint to use and its capabilities. By the time a request is sent to a SPARQL processor, the choice made by using service description should be right. That's an area that's evolving and as mentioned previously, W3C is a standard organisation for typically general community agreement.

Versioning at the request level is more a kin to a consistency assertion. The mechanism for explicitly stating the expected version for in the body is the same for the RDF syntaxes. As a matter of user afforance:

VERSION "1.2"

is more human friendly than

VERSION <http://www.w3.org/ns/sparql#version-1.2>

[using prefixes is not so simple (1) the prefix needs to come first (2) it introduces more variance; some level of
parsing is needed to extract it rather than text search.]

There is a tradeoff here.

In your example, you give a version of particular instance of a query language. It is a proxy for talking about the query language.

There is a discussion about a controlled vocabulary for versions - not directly versions of specific specifications, but terms that can be used to give to a particular instance. Such declarations can be made to connect RDF data and to SPARQL Query to a version (in service description presumably).

VERSION "1.2" is common to RDF and SPARQL Query. The semantics that combine in basic graph pattern matching. So there is a slight pun in use "1.2" as the version.

BTW: Literals have semantics - they are self-denoting. A URI is just a global name until/unless some data uses it to give more
information. A controlled vocabulary could utilise a datatype, but the community style is to use URIs in controlled vocabularies.