What is SPARQL DEV? about sparql-dev HOT 26 OPEN

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.

from sparql-dev.

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 ?

from sparql-dev.

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.

from sparql-dev.

from sparql-dev.

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.

from sparql-dev.

@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?

from sparql-dev.

@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.

from sparql-dev.

@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.

from sparql-dev.

@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.

from sparql-dev.

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").

from sparql-dev.

@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.

from sparql-dev.

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.

from sparql-dev.

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.

from sparql-dev.

@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.

from sparql-dev.

from sparql-dev.

@pfps Which is the best paper on that topic?

from sparql-dev.

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

from sparql-dev.

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?

from sparql-dev.

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

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

from sparql-dev.

@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.

from sparql-dev.

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.

from sparql-dev.

@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.

from sparql-dev.

@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.

from sparql-dev.

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.)

from sparql-dev.

@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?

from sparql-dev.

@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.

from sparql-dev.