Re: Feature request: IN operator

I was about to suggest that inference could handle that particular
example, as far as I can tell the case is handled by sub properties
(happy to be corrected, but with the variable in another position this
feature would be desirable for batch operations involving a list of
subjects or objects of interest.  It is used very frequently in SQL.

Possible use cases would be augmenting, say a few hundred thousand
records about musicians with information about the genre of music they
play (something I am likely to do in the near future).

Another use case might involve retrieving additional columns of data in
a tabular UI, with batch sizes equal to the number of records in the
viewport and the content of the IN group taken from a column bound to an
inverse functional property. This would allow extra columns to be
requested and populated on the fly without performing a fresh query for
the whole table.

Having an explicit syntax would allow implementors to infer the
possibility of a longer list than || might suggest and therefore they
might be able to trigger appropriate optimizations. This might in turn
yield a higher maximum batch size and better overall performance.

FWIW I would prioritize aggregation functions (MIN, MAX, COUNT, AVERAGE,
GROUP BY etc) above this feature as the distribution of graphs allows a
work around for the missing IN (see e.g. Talis' augmentation
functionality) as does  the || operator.

Toby Inkster wrote:
> Analogous to the SQL operator of the same name.
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
> SELECT ?thing ?name
> WHERE {
>   ?thing ?p ?name .
>   FILTER (?p IN (foaf:name foaf:nick rdfs:label))
> }
>
> This query can already be written as
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
> SELECT ?thing ?name
> WHERE {
>   ?thing ?p ?name .
>   FILTER (?p = foaf:name || ?p = foaf:nick || ?p = rdfs:label)
> }
>
> But I hope people agree that the former syntax is more legible.
>
> Formally, IN would be an infix operator taking a term as its first
> argument and an rdf:List as its second argument.
>
>