FROM (NAMED) not allowed in SERVICE

[rubensworks]

While this is a valid query as far as I know, it is not accepted by the parser:

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

Error:

Parse error on line 16:
...ql> {    SELECT *	FROM <http://dbpedia
---------------------^
Expecting 'WHERE', '{', got 'FROM'

Also for FROM NAMED:

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

[joachimvh]

Actually not a valid query. Can't find the immediate reason in the spec, but the grammar defines queries and subqueries differently:

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

It's also not accepted on http://sparql.org/validate/query

[rubensworks]

Well that's silly...
I don't immediately see a reason why this would not be allowed.
If true, then this would be a good thing to be resolved in SPARQL 1.2 as well.

For reference, this was reported here: https://discuss.rdf.community/t/sparql-engine-for-node-js/37/15?u=rubensworks

[cygri]

FROM and FROM NAMED are not allowed in subqueries. They need to be set on the outermost level of the query.

Now, if the subquery is inside a SERVICE clause, then the outermost SELECT is generated implicitly as part of the service call (as an implicit SELECT * WHERE). And there is no way for the query writer to add a FROM or FROM NAMED to that query.

Sometimes, the same result can be achieved by adding the &default-graph-uri or &named-graph-uri parameters of the SPARQL protocol to the service endpoint. Or by using GRAPH <x> { } inside the service clause to switch to the desired graph. Either should have worked here, I think.