xsd:string is the datatype by default and becomes implicit in SPARQL results srx srj #76
Conversation
|
There is at least one major triple store that provides RDF 1.0, not RDF 1.1. There are probably RDF1.0 data around on the web. These tests would work in a SPARQL 1.1/RDF 1.0 system as well because the data files align with the result files. jsonres tests also involve ORDER BY so there may be other effects. While I wouldn't go out of the way to retain RDF 1.0 compatibility for new work, I don't think making a change when there isn't a need (bug or necessary change) helps overall. SPARQL client software still has to deal with explicit xsd:string to be compliant so these do check something. Minor: the original EARL reports were with RDF 1.0. |
|
@BorderCloud based on @afs's response, I've marked this as "wont fix". If you agree, you can close the PR. |
|
It does ask the question what is this for - this community could decide that this repo is only about "now", or should reflect the history. There are good arguments for either. |
|
At some point, the test suite, if not the SPARQL specs, need to fully align with RDF 1.1, particularly with regards to plain literals and xsd:string handling. the point of this repo is to curate these tests with regard to the current specs, but if a SPARQL CG would like to move the specs forwards, we could/should track the changes here. It wouldn’t make sense to fork the test suite again. |
|
Agreed. The test suite here should be RDF 1.1 usable - not another fork! SPARQL 1.1 (and 1.0) is written with the anticipation that simple literals (SPARQL terminology) merge xsd:string. But it is good to test for the case of RDF 1.0 written data and not see tests as a showcase of preferred usage. |
|
The JSON-LD tests have a |
|
@gkellogg - I'm neutral. The situation hasn't changed. There is at least one major triple store, OpenLink Virtuoso, that provides RDF 1.0. For them, the explicit datatype is necessary. I found at least one test that has some data with and some without explicit In the light of RDF-star (RDF 1.2) WG starting, if the rdf-tests community wants to align to RDF 1.1 then make this change (which I have checked and it seems OK) and also #83. To check where the community opinion is, I've raised an issue to collect votes #88 because I think we need to be completely clear as to the decision going forward. Give this at least some business-days to conclude. If the community wishes to maintain as RDF 1.1 (and soon RDF 1.2), merge this. If the community wishes to retain the current position (roughly - on a case-by-case basis), we should not make changes that are unnecessary and close this PR unmerged. |
I am not sure what is meant by "not another fork". I think having branches focused on RDF 1.0, 1.1, and 1.2 (and actually, a matrix of these with SPARQL 1.0, 1.1, and 1.2) would be quite useful, for reasons discussed in #88, #83 and related. |
|
I've tagged the repository with |
| } , | ||
| { | ||
| "s": { "type": "uri" , "value": "http://example.org/s4" } , | ||
| "p": { "type": "uri" , "value": "http://example.org/p4" } , | ||
| "o": { "datatype": "http://www.w3.org/2001/XMLSchema#integer" , "type": "literal" , "value": "4" } | ||
| "o": { "type": "literal" , "value": "4" } |
There was a problem hiding this comment.
This introduces the implicit rule "if a literal value is a JSON number that looks like a xsd:integer, then it should be parsed as a xsd:integer literal". Is it intended? It is not specified anywhere at my knowledge.
If we want to introduce it, it might also be nice to add more tests to cover more cases (boolean, the numbers 0.1 (xsd:decimal?) 0.1e3 (xsd:double?), 0. (??)...
There was a problem hiding this comment.
No, that's not intended. Thank you for catching that.
I missed it because json-res isn't run by manifest-sparq11-query.
csv-tsv-res/csvtsv02.tsv is damaged as well.
manifest-all contains remote tests, which need special setup and the entailment tests.
I wonder if it would be useful to have manifest.ttl that is the "all local" part -- query, update and the result set formats.
There was a problem hiding this comment.
A manifest.ttl with result set formats but not entailment tests seems a bit arbitrary to me but why not.
There was a problem hiding this comment.
The entailment tests includes ones with complex OWL reasoning.
The idea of manifest.ttl is a single place for the majority of triplestores.
Or manifest-results.ttl.
Or both!
There was a problem hiding this comment.
Makes sense. +1 to manifest.ttl or something like manifest-with-results.ttl.
There was a problem hiding this comment.
I'll add it to the reorg.
I'm currently minded to have manifest-results and manifest includes -query,, -update and -results.
xsd:string seems to become the datatype by default and so, it becomes implicit in sparql results.
Here, I propose to modify the SPARQL results of tests in order to be in coformity with the SPARQL results generate today by the classic SPARQL services.