Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPARQL 1.1 Federation test service5 should be retracted #138

Open
kasei opened this issue Jun 21, 2024 · 4 comments
Open

SPARQL 1.1 Federation test service5 should be retracted #138

kasei opened this issue Jun 21, 2024 · 4 comments

Comments

@kasei
Copy link
Contributor

kasei commented Jun 21, 2024

SPARQL 1.1 SERVICE test 5 is marked as Approved in the test manifest with a link to the working group's minutes from 2012-01-31.

However, this test uses the SERVICE ?var form (where the endpoint to be federated is determined from the value of a variable binding:

SELECT ?service ?title
WHERE {
  {
    # Find the service with subject "remote".
    # Inner block to fix the FILTER not be over
    # just this local pattern.
    ?p dc:subject ?projectSubject ;
       void:sparqlEndpoint ?service  
       FILTER regex(?projectSubject, "remote")
  }

  # Query that service projects.
 
  SERVICE ?service {
     ?project  doap:name ?title . } 
}

This part of the SPARQL 1.1 Federation spec (SERVICE Variables) is not normative. The document section is marked "Informative," and includes this text:

In the this section we do not present official evaluation semantics for the SPARQL pattern SERVICE VAR.

It seems likely that this test was mistakenly approved (the WG minutes indicate that the approval was determined for all then-unapproved federation tests by a single vote). Since this test requires features beyond the normative parts of the SPARQL 1.1 Federation spec, I think it should probably be un-approved/retracted (or at the very least marked with extra annotation in the manifest indicating that its evaluation requires extensions beyond the spec). Such retraction/modification probably needs approval by the current WG; I'd assume the CG does not have the authority to change a previously-approved test.

@rubensworks
Copy link
Member

+1 on un-approving, but keeping the test part of the manifest.

@lisp
Copy link

lisp commented Jun 21, 2024

would it not be better to retain the approved status but make it dependent on a profile?
it does reflect the formulation which is present in a recommendation.
in that sense it does clarify expectations.

@afs
Copy link
Contributor

afs commented Jun 21, 2024

Good investigation of the minutes!

Remove the approval and remove it from the list of tests at the start. Leave in the manifest with comments.

Rationale: the manifest should be runnable for a compliant system with as little burden as possible. The more effort to
disentangle the tests, the less takeup there will be. I think it is better to make the default required-only; having something included that isn't spec and would need investigation by the test user is a burden.

Alt: a separate manifest-extra of "extras" which isn't linked into the grouping-level manifests.

@afs
Copy link
Contributor

afs commented Jun 21, 2024

I'd assume the CG does not have the authority to change a previously-approved test.

This could be dealt with as an errata. The current WG can then execute on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants