Fix a wrong expected SPARQL protocol test result

[joka921]

The test case "query specifying dataset in both query string and protocol; test for use of protocol-specified dataset"
reads as follows originally:

#### Request

    POST /sparql/?default-graph-uri=http%3A%2F%2Fkasei.us%2F2009%2F09%2Fsparql%2Fdata%2Fdata2.rdf HTTP/1.1
    Host: www.example
    User-agent: sparql-client/0.1
    Content-Type: application/sparql-query
    Content-Length: XXX

    ASK FROM <http://kasei.us/2009/09/sparql/data/data1.rdf> { <data1.rdf> ?p ?o }
    
#### Response

    2xx or 3xx response
    Content-Type: application/sparql-results+xml or application/sparql-results+json

    true

As far as I understand, the expected result of true is wrong, because

• The protocol specifies (via default-graph-uri) the default graph ...data2.rdf
• The query specifies (via FROM) the default graph data1.rdf
• SPARQL 1.1 Protocol as well as the name of the test specify, that in this case, the dataset specification ofthe protocol (so data2.rdf) should be used, which only contains theIRI <...data2.rdf>
• Therefore the expected result should be false

Additionally, the IRI in the query body doesn't use an absolute IRI and there is no base declaration, I have also added the full IRI for thi PR.

An alternative way to fix this would be to leave the expected result at "true" and change the query s.t. it asks for data2.rdf in the WHERE clause.

Please let me know what you think, and (possibly if so) were I am mistaken.
Best regards

[afs]

I agree the answer should be false and that default-graph-uri= overrides FROM in the query.

Not to do with the PR as proposed

Test setup in index.html is unclear what "The following RDF files are loaded as appropriate" means. It can mean all read into the same (default) graph, it can mean as named graphs (the implication of this test).

It might be better to have a TriG file.

Another assumption is that "FROM" picks graphs from the dataset's named graphs. This is, in my experience, the most common behaviour of systems but it isn't the only one permitted.

cc @kasei

[kasei]

This seems to be an old error in copying the actual tests from the code into the README file describing the tests. Apparently nobody noticed until you did. Here is the original test code. It shows that the expected behavior is to load rdf files into named graphs before the test run, and then to run a very different query + HTTP parameters than the ones that were mistakenly in the adjacent README markdown document.

Since this error seems to have been reproduced whenever the tests were transcribed into what is now the manifest.ttl file (apparently from the README, not the code), I'm not sure the current state is even providing good test coverage compared to the original validator. It might be a good idea to try to dig up what tests were actually approved by the 1.1 WG and figure out if they were (mistakenly) the ones with the error, or if they were approving the tests as encoded in the working code. Then we'll have some fun work in fixing things so that we have the coverage we expect along with whatever WG approvals might be necessary to fix the past mistakes.

[kasei]

Unfortunately, the WG approval does appear to have been on the tests in the README with the mistakes. I'll try to go through the code and the manifest and see if there are any other tests that have mistakes.