What is SPARQL DEV?

[JervenBolleman]

This is to discuss how far one sees compatibility with SPARQL 1.1. Here the goal is to find the philosophy of where we want to go, what would we dare to break. At this early stage this is about framing opinions, opinions which are allowed to change.

[TallTed]

Similar to the ways that other evolving protocols and query languages work (see SQL, ODBC, HTTP for examples), it seems to me that there should be a way for SPARQL client tools to ask the SPARQL endpoint what it understands -- which of course will fail for older servers, indicating that it only understands the older SPARQL version(s) -- and for SPARQL servers to more generally advertise/announce their features, avoiding the direct question.

The only alternative I see is for SPARQL 1.2 clients to try a SPARQL 1.2 query, get an inelegant failure, try a SPARQL 1.1 version of the query, possibly get another inelegant failure, and fall back to a SPARQL 1.0 version of the query...

In a perfect world, there should also be a way for a SPARQL 1.2 client to declare to a SPARQL 1.2 server that it should use SPARQL 1.2 rules when processing the query being submitted -- lacking which declaration, SPARQL 1.1 rules should be followed (or SPARQL 1.0 rules, if SPARQL 1.1 rules lead to failure, given that there's no way to declare "this is a SPARQL 1.1 query").

[kasei]

@TallTed Unless I've misunderstood your intent, the way for SPARQL endpoints to "advertise/announce their features" is the service description. There is existing vocabulary to describe what query languages are supported, as well as an extensible way to describe supported features and functions.

[dydra]

one of the service description properties, supported language, would suffice to report supported versions.
it would be possible for the client to communicate its intent in the request content type as a version parameter, but i found no precedents for that. notably, xml includes it in the body only.

[VladimirAlexiev]

@JervenBolleman call me thick but can you give an example of a 1.1 feature that is so broken that we'd want to change it in an incompatible way?

[jindrichmynarz]

I think we all enjoy a plateau of productivity given by the relative stability of SPARQL 1.1. Thus I'd like to focus on backwards-compatible accretive changes, perhaps a soft deprecation here and there, so that existing SPARQL implementations don't have to change.

Regarding the mechanism for communicating what SPARQL functionality is supported, we have the SPARQL 1.1 Service Description @kasei mentioned. An alternative mechanism is custom MIME type delivered via the Content-Type HTTP header, such as the default application/sparql-query.

[afs]

The definition "SPARQL 1.1 query produces the same answers with a SPARQL 1.2" is one natural criterion. The most impactful changes at SPARQL 1.1 I have seen have been the RDF 1.1 changes,not SPARQL itself.

Operationally, a SPARQL invocation at its simplest is "send query string, get back results" so one implication would be that a client application using a SPARQL library could send a query string with a SPARQL 1.2 feature, and get back a result set (etc). Most toolkits seem to have a way to send a string even if they also provide a way to send a parsed query object they have created.

It is changes to the result set format that have the impact on the client-side SPARQL library.

I don't believe in any switchover where client-side and server-engine have to move together without a very strong reason for it. There are many client libraries for many languages/systems that are independent of server providers.

[jindrichmynarz]

That's a nice operational description of the scope of changes to SPARQL. Correspondingly, SPARQL 1.2 implementations should still pass the SPARQL 1.1 Test Suite in its current form.

[pfps]

I hope that at the very least we are allowed to change (or not depend on) the parts of SPARQL 1.1 that are broken.

[TallTed]

@dydra @kasei - Ah, yes, sd:Language addresses the server's advertisement.

If SPARQL 1.2 execution maintains absolute backward compatibility, there may not be a need to implement a client-submitted query version hint. Past experience suggests that such absolute backward compatibility may not be maintainable, in future SPARQL if not 1.2, so I would suggest that standardizing such a hint now would be better than kicking it down the road.

[TallTed]

@pfps - If you can be specific about "the parts of SPARQL 1.1 that are broken", optimally raising each in its own issue here, they become addressable. Handwaves do none of us any good.

If addressing those parts breaks backward compatibility (i.e., if SPARQL 1.1 queries would then produce different results on SPARQL 1.2 endpoints than on SPARQL 1.1 endpoints), then my suggestion above, about a client-issued version hint (which would therefore be required on SPARQL 1.2 queries; it's absence would flag a SPARQL 1.1 query), comes into play.

[pfps]

The specification of EXISTS is broken in SPARQL 1.1, even though there is a formal definition of EXISTS is SPARQL 1.1. No one implements the specification. Implementations of EXISTS differ from each other in the results they provide. The formal specification of EXISTS is counter to the spirit of the rest of SPARQL 1.1. It is not possible to carve out a useful syntactic restriction of EXISTS where problems do not arise. As a result, there are zero (0) implementations of SPARQL 1.1. Multiple papers have been written on this brokenness. peter

…

On Wed, Apr 3, 2019 at 12:12 PM Ted Thibodeau Jr ***@***.***> wrote: @pfps <https://github.com/pfps> - If you can be specific about "the parts of SPARQL 1.1 that are broken", optimally raising each in its own issue here, they become addressable. Handwaves do none of us any good. If addressing those parts breaks backward compatibility (i.e., if SPARQL 1.1 queries would then produce different results on SPARQL 1.2 endpoints than on SPARQL 1.1 endpoints), then my suggestion above, about a client-issued version hint (which would therefore be required on SPARQL 1.2 queries; it's absence would flag a SPARQL 1.1 query), comes into play. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGT8e4Lq4IQwTSQBGIArcxrT5mpfy1Zeks5vdP0igaJpZM4cXcni> .

[cygri]

@pfps Which is the best paper on that topic?

[pfps]

I'm partial to EXISTStential Aspects of SPARQL Peter F. Patel-Schneider and David Martin ISWC 2016 http://ceur-ws.org/Vol-1690/paper72.pdf The paper Daniel Hernndez, Claudio Gutierrez, and Renzo Angles. Correlation and substitution in SPARQL. https://scirate.com/arxiv/1606.01441, 7 June 2016 is also useful. peter

…

On Wed, Apr 3, 2019 at 2:15 PM Richard Cyganiak ***@***.***> wrote: @pfps <https://github.com/pfps> Which is the best paper on that topic? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGT8e5v5NIW_jfoNupiHjyCWbmYqwdGMks5vdRnqgaJpZM4cXcni> .

[afs]

Peter wrote a summary email: https://lists.w3.org/Archives/Public/public-sparql-exists/2016Jul/0014.html

[cygri]

There is a lot of discussion here about what kind of changes to the query language would be acceptable.

How about the protocol? What kind of changes would be acceptable there?

• What about a change that prevents some 1.1 protocol clients from talking to 1.2 protocol servers?
• What about a change that prevents some 1.2 protocol clients from talking to 1.1 protocol servers?

[kasei]

@cygri I wouldn't entirely rule out breaking changes to the Protocol, but I'd be very reluctant about them if there was any way to achieve similar results while maintaining compatibility.

[cygri]

@kasei That is a politician's answer :-)

• What does “breaking change” mean?
• What does “maintaining compatibility” mean?

[kasei]

@cygri I assume "breaking change" means (in your words) "a change that prevents some 1.1 protocol clients from talking to 1.2 protocol servers" and vice versa.

"Prevents" is the issue here for me. I think that would be really bad. My point is that if there are paths forward that can avoid "preventing," such as (strawman) version numbers in the request headers, I think that would be a preferable solution.

[BorderCloud]

@cygri

What about a change that prevents some 1.1 protocol clients from talking to 1.2 protocol servers?
What about a change that prevents some 1.2 protocol clients from talking to 1.1 protocol servers?

I can enable my JMeter tests to check the backward compatibility with the protocol 1.1.

[jindrichmynarz]

Breaking change is caused by removing or replacing existing behaviour. Maintaining compatibility can mean avoiding these breaking changes. As discussed above, an operational definition of maintaining compatibility is passing the SPARQL 1.1 Test Suite, with the caveats discussed in #38.

[cygri]

@jindrichmynarz The question was about the SPARQL Protocol. It is not clear what “behaviour” means for a protocol. There are no tests for the SPARQL Protocol in the test suite AFAICT.

[kasei]

@cygri

There are no tests for the SPARQL Protocol in the test suite AFAICT.

FWIW, I was using this hacked-together sparql11-protocolvalidator code as a sanity check during the SPARQL 1.1 WG work.

[BorderCloud]

After several years of debate about the protocol, I think: it is not possible to reach a consensus between historic SPARQL editors to improve SPARQL 1.1 protocol.

Has the time come to imagine a new organization to build SPARQL 2.0 with a real balance between customers and editors ?

[afs]

An issue that isn't compatibility of the language or execution but might be a factor in "SPARQL 1.2" is implementation impact.

For example, the current grammar is structurally simple and can be developed using a wide range of parser generators. This was a consideration that the WG members wanted for 1.0, and

In order to get adoption of features, implementations have to do some work, and the extent of the changes will be a factor in the rate of adoption.

(The spec content for was actually generated using javacc, LL(1), ot maintain the grammar, then custom processing to produce HTML; it was also validated independently with an LALR(1) parser generator.)

[jindrichmynarz]

@cygri Can we consider the relations between requests and responses the behaviour of a SPARQL 1.1 Protocol implementation? SPARQL 1.1 Test Suite lists several protocol/* tests, but they are blank. Does it mean they weren't finished?

[kasei]

@jindrichmynarz As mentioned above, SPARQL protocol tests were implemented by this validator. I hadn't remembered specifics of the testing for the protocol, but reviewing the test suite and the implementation summary, I believe this validator was used to test protocol implementations during the lead-up to 1.1 standardization.