w3c / sparql-dev

SPARQL dev Community Group
https://w3c.github.io/sparql-dev/
Other
124 stars 19 forks source link

treat unbound optional query param as "no restriction" #162

Open VladimirAlexiev opened 2 years ago

VladimirAlexiev commented 2 years ago

First read #57 and #161

Why?

If you use query parameterization and a param is unbound, you'd want to treat that as "no restriction" rather than "no values".

Eg https://github.com/viaacode/grasp-org-api/blob/main/resources/Organization.sparql#L44 by @mielvds uses some conditional processing like this (I think that's a Moustache template); id1 is a single-valued literal param, and iri1 a multi-valued IRI param:

      {{#if id}}
      ?iri schema:identifier "{{id1}}" .
      {{/if}}

      {{#if iri}}
      VALUES ?iri { {{join " " (as-iriref iri1)}} }
      {{/if}}

The disadvantage is that this requires query preprocessing conditionalized on the presence or absence of params.

For single-value params, you can use bound() guards (and maybe some union clauses), eg

      ?iri schema:identifier ?id.
      filter(!bound($id1) || ?id=$id1)

But things quickly get complicated if ?id is an optional field, etc.

For multi-valued params, I don't know how it can be expressed in SPARQL since it has no conception of multi-valued params. #161 shows the two typical ways you can use them in SPARQL (as in or values). Empty in and values lists are allowed in SPARQL, and as expected lead to no solutions, eg

select * {
    bind(3.14 as ?y)
    values $x {}  # no solutions
    # filter($x in ())  # same
}

Previous work

Proposed solution

No idea, and I'm not optimistic one can be made in SPARQL without breaking backward compatibility. But at least some best practices for conditional processing would be nice.