On 20/03/13 06:37, Hasan Hasan wrote:
Hi Reto
Right, the name of all graphs should be returned. But you don't specify any
graphs
in the query, so the default graph is returned.
GRAPH ?graphName {} (which is a Graph Graph Pattern) refers to graphs we
specify in DatasetClause (that is 'FROM' ( DefaultGraphClause |
NamedGraphClause ))
GRAPH ?graphName {} is all the named graphs in the RDF Dataset being
queried.
Like
SELECT DISTINCT ?g { GRAPH ?g { ?s ?p ?o } }
but includes empty named graphs.
Only FROM NAMED affects it.
Andy
cheers
Hasan
On Tue, Mar 19, 2013 at 3:57 PM, Reto Bachmann-Gmür <[email protected]> wrote:
Hi Hasan,
I don't think so. If the defaultGraph is returned this tells the caller
that the query is directed only against the default graph and can thus
fastlane the query to the provider of the default graph. But if I
understand the query correctly the name of all graphs should be returned.
So it can only be fastlaned if the TcManager has exactly one provider, in
all other cases it has to be slowlaned.
Cheers,
Reto
On Tue, Mar 19, 2013 at 7:48 AM, Hasan <[email protected]> wrote:
Hi Reto,
I think it should return the defaultGraph.
http://www.w3.org/TR/rdf-sparql-query/#queryDataset
Cheers
Hasan
On Mon, Mar 18, 2013 at 8:21 PM, Reto Bachmann-Gmür <[email protected]>
wrote:
Hi Hasan
What should
Set<UriRef> getQueryGraphs(Sting query, UriRef defaulGraph)
return for a query like:
SELECT ?graphName WHERE { GRAPH ?graphName {} }
null? throw an exception? Or should we change the method to better suit
these cases?
Cheeers,
Reto
On Tue, Feb 26, 2013 at 4:36 AM, Reto Bachmann-Gmür <[email protected]>
wrote:
Hi Hasan
On Tue, Feb 26, 2013 at 4:11 AM, Hasan <[email protected]> wrote:
- Create subclass of TcProvider that accepts sparql query as
string
Assumed that this string will be used when invoking the underlying
engine
Yes
- Have a minimum parsing of the queries to get the names a query
is
directed against
this would be the datasetclause of the "sparql query" and in case of
"sparql update"
it would be the graphref.
So we need a simple parser to extract iri of the affected graphs.
How should the interface definition of the parser look like for
sparql
update?
What about a class SparqlPreParser with a singe method Set<UriRef>
getReferredGraphs(Sting query). The method should return all graphs
the
query is directed to excluding remote service graph. One issue is the
default graph, the caller should know if the query explicitly sets a
default graph. So it would probably better to have Set<UriRef>
getQueryGraphs(Sting query, UriRef defaulGraph) instead. With this
method
defaultGraph is part of the result if the query has no FROM clause.
Question:
- Did you already model the results of Sparql 1.1? I think there
is
no
big
difference there to 1.0.
afaik it is the same for query, but a sparql update results in
success
or
failure.
Which is the same as for ASK queries. So the result is an Object that
can
be cast either to a ResultSet, a Graph or a Boolean.
Cheers,
Reto
