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.
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, andiri1
a multi-valued IRI param: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 someunion
clauses), egBut 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
orvalues
). Emptyin
andvalues
lists are allowed in SPARQL, and as expected lead to no solutions, egPrevious work
__param
) but doesn't specify how to handle itProposed 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.