SPARQL syntax test classes in test manifest vocabulary include version in IRI (11)

[rubensworks]

The test manifest vocabulary introduces the following:

:PositiveSyntaxTest11 rdf:type rdfs:Class ;
      rdfs:label "Positive Syntax Test for SPARQL1.1 Query" ;
      rdfs:comment "A type of test specifically for syntax testing of new features in the SPARQL1.1 Query Language. Syntax tests are not required to have an associated result, only an action." .

:PositiveUpdateSyntaxTest11 rdf:type rdfs:Class ;
      rdfs:label "Positive Syntax Test for SPARQL1.1 Update" ;
      rdfs:comment "A type of test specifically for syntax testing of SPARQL1.1 Update. Syntax tests are not required to have an associated result, only an action." .

:NegativeSyntaxTest11 rdf:type rdfs:Class ;
      rdfs:label "Negative Syntax Test for SPARQL1.1 Query" ;
      rdfs:comment "A type of test specifically for syntax testing of new features in the SPARQL1.1 Query Language. Syntax tests are not required to have an associated result, only an action. Negative syntax tests are tests of which the result should be a parser error." .

:NegativeUpdateSyntaxTest11 rdf:type rdfs:Class ;
      rdfs:label "Negative Syntax Test for SPARQL1.1 Update" ;
      rdfs:comment "A type of test specifically for syntax testing of SPARQL1.1 Update. Syntax tests are not required to have an associated result, only an action. Negative syntax tests are tests of which the result should be a parser error." .

This means that the test classes are hardcoded to SPARQL 1.1, which is inconsistent with the test classes for RDF syntaxes (PositiveSyntaxTest and NegativeSyntaxTest), which do not include such a version label.

In order to add new syntax tests for SPARQL 1.2, we can either

1. broaden the usage of the SPARQL test classes, and keep using classes such as PositiveSyntaxTest11 for SPARQL 1.2, or
2. introduce PositiveSyntaxTestSparql and variants into the vocabulary, and deprecate PositiveSyntaxTest11 and variants.

Option 2 seems like the cleanest option to me.

[afs]

For completeness, there is a "3":
3. Add a PositiveSyntaxTest12 and related names.

Note:
In PositiveSyntaxTestSparql - the 'Sparql' is redundant because the namespace is http://www.w3.org/2001/sw/DataAccess/tests/test-manifest# ("DataAccess" being the SPARQl 1.0 WG name) and also distinguishing 1.1 vs 1.2 is by file path name.

IMO find saying "SPARQL 1.1" when it is SPARQL 1.2 is a bit misleading.

(3) is slightly more preferable; (2) is OK.

Apache Jena has separate parsers for versions of SPARQL (1.0, 1.1. and now 1.2). I don't recall any feedback about their usage. The default is SPARQL+extensions. All extensions are additions and do not change/invalidate any standard SPARQL syntax.

[rubensworks]

For completeness, there is a "3":
3. Add a PositiveSyntaxTest12 and related names.

I'm less in favor of that one, as the RDF syntaxes tests also don't have versions in their test classes (PositiveSyntaxTest and NegativeSyntaxTest).
So this might be a good opportunity to become aligned with those.

My current preference is on option (2).

Any other opinions on this @hartig @kasei @Tpt @hartig ?

[hartig]

I don't have a particularly strong opinion here, but option (2) seems to me as the most logical one.

[Tpt]

+1 to option 2 but I don't have a really strong opinion too

[kasei]

I prefer option 3, but could accept 2.

I like knowing that a certain test is specific to a specific version based on the manifest data. This might be accomplished by an extra property hanging off of the test (similar to what we do with mf:requires), but that hasn't been what we've done in the past, so I'd prefer to continue with the existing trajectory.

[gkellogg]

Option 3 could allow implementations to know if they need to invoke some 1.2-specific rules; In JSON-LD we added another test entry property to indicate the spec version associated with a given test. My personal preference would be option 2, and if we need to distinguish specific behavior to use another property to signal this, which is not uncommon in other test manifests. Otherwise, continuing to create new version-specific classes for the different test types would seem to become more and more difficult to manage over time.

[rubensworks]

Ok, to compromise between option 2 and 3, I'll look into making a PR for option 2, but with an additional test property to mark the SPARQL version, similar to what JSON-LD does.

[rubensworks]

I've included this change in PR #144 as 52735fd
The new mf:specVersion predicate uses the same syntax as JSON-LD 1.1's https://w3c.github.io/json-ld-api/tests/vocab#specVersion (json-ld-1.1).

[gkellogg]

I note that the 1.0 syntax tests use (for example) mf:PositiveSyntaxTest and mf:NegativeSyntaxTest, while the 1.1 tests use mf:PositiveSyntaxTest11 and mf:NegativeSyntaxTest11. These new tests use mf:PositiveSyntaxTestSparql and mf:NegativeSyntaxTestSparql.

@afs pointed out that the "Sparql" suffix is redundant, I would favor consolidating to mf:PositiveSyntaxTest and mf:NegativeSyntaxTest for both 1.1 and 1.2 tests. But, this should at least be done for #144.

[rubensworks]

Ah, you're right @gkellogg, I missed that comment from @afs.
I was mistakenly assuming that mf:PositiveSyntaxTest was also used for defining RDF parsing tests, but they actually use their own dedicated classes, so there's no danger of clashes here.