FROM in subqueries

[turnguard]

According to current grammar FROM is not allowed in subqueries..
The distributed nature of RDF screams for that..

[cygri]

You're assuming that FROM <myGraph> would load <myGraph> from the web? If it's just about selecting a different graph from the local dataset, that can be done with

GRAPH <myGraph> { subquery-without-FROM }

[jindrichmynarz]

Given that SPARQL 1.1 Update has LOAD to get data from the web, I think the dereferencing behaviour of FROM is problematic, because it makes (read-only) queries less tractable.

[afs]

Yes - FROM/FROM NAME describe a static dataset for the whole query execution.

I am wondering what the use case in mind is?

I assume it's discovering a graph you want to query during a query execution. That is a dynamic notion of the dataset but there are other ways to get the same effect, such as combining Update and query in one request or a conceptual dataset of all graphs (can't ask GRAPH ?g !). There are implications for optimization.

Maybe it is best done as two separate queries and not even in a single request.

[rubensworks]

I was just about to report this as a new issue, but then saw that this issue already exists.
Here are my findings according to the issue template:

Why?

According to the SPARQL grammar, FROM and FROM NAMED are not allowed in subqueries, which makes parsers fail for queries such as:

SELECT * WHERE {
  SELECT *
  FROM <http://dbpedia.org>
  WHERE {
    ?s ?p ?o
  }
}

Relevant grammar part:

[7] | SelectQuery    | ::= | SelectClause DatasetClause* WhereClause SolutionModifier
[8] | SubSelect      | ::= | SelectClause WhereClause SolutionModifier ValuesClause
...
[13] | DatasetClause | ::= | 'FROM' ( DefaultGraphClause | NamedGraphClause )

For example, http://sparql.org/query-validator.html gives the following error:

Encountered " "from" "FROM "" at line 3, column 3.
Was expecting one of:
    "where" ...
    "{" ...

(Discovered in RubenVerborgh/SPARQL.js#85 thanks to @kidehen)

Previous work

It looks like Virtuoso accepts such queries.

Proposed solution

As far as I can see, there is no reason why subqueries with FROM and FROM NAMED should not be possible (unless I am missing something?). As such, I would propose to allow these in the grammar, as Virtuoso proves that it can be done.

Considerations for backward compatibility

All 1.1 queries will still work in 1.2.

[cygri]

@rubensworks You do not say why that is a problem. In your example, you can just move the FROM clause to the outer SELECT.

[VladimirAlexiev]

@cygri @afs It is a problem because FROM sometimes invokes special processing that GRAPH doesn't.

A. I want to count implicit and explicit statements in GraphDB, with one query, so I can present a single table keyed by property. This is not allowed by the grammar:

PREFIX onto: <http://www.ontotext.com/>
select ?x ?explicit ?implicit {
    {select ?x (count(*) as ?explicit) 
     from onto:explicit where {
        ?s ?x ?o
    } group by ?x order by ?x}
    {select ?x (count(*) as ?implicit) 
     from onto:implicit where {
        ?s ?x ?o
    } group by ?x order by ?x}
}

If I try it with GRAPH instead, it finds nothing because onto:implicit and onto:explicit are not real graphs but are magic graphs that can only be invoked by FROM

PREFIX onto: <http://www.ontotext.com/>
select ?x ?explicit ?implicit {
    {select ?x (count(*) as ?explicit) {
     graph onto:explicit {
        ?s ?x ?o
     }} group by ?x order by ?x}
    {select ?x (count(*) as ?implicit) {
     graph onto:implicit {
        ?s ?x ?o
     }} group by ?x order by ?x}
}

B. I want to use SPARQL federation to invoke an external endpoint. And it needs FROM to trigger similar special processing.
Because inside SERVICE is a subquery, I cannot do that.

[ericprud]

@cygri @afs It is a problem because FROM sometimes invokes special processing that GRAPH doesn't.

A. I want to count implicit and explicit statements in GraphDB, with one query, so I can present a single table keyed by property. This is not allowed by the grammar:
...
If I try it with GRAPH instead, it finds nothing because onto:implicit and onto:explicit are not real graphs but are magic graphs that can only be invoked by FROM

Ignoring the desire to use the services as they exist today, is this an argument that we need some sort of PRAGMA that can appear in the prolog and in subqueries? This seems more honest to me. (In an ideal world, we wouldn't need magic, but I don't think we know how to construct that world.)

B. I want to use SPARQL federation to invoke an external endpoint. And it needs FROM to trigger similar special processing. Because inside SERVICE is a subquery, I cannot do that.

This sounds like a bug and someone should beat up the guy who wrote that grammar.