Skip to content
New issue

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

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

Already on GitHub? # to your account

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

Open
VladimirAlexiev opened this issue Jun 15, 2022 · 0 comments
Open

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

VladimirAlexiev opened this issue Jun 15, 2022 · 0 comments

Comments

@VladimirAlexiev
Copy link
Contributor

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

  • Basil's convention allows to mark a param as optional (eg __param) but doesn't specify how to handle it

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.

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

No branches or pull requests

1 participant