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 ))
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
> > > >
> > >
> >
>
