clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <a...@apache.org>
Subject Re: Sparql 1.1 and Fastlane
Date Wed, 20 Mar 2013 09:32:50 GMT
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 <reto@apache.org> 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 <hasan@apache.org> 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 <reto@apache.org>
>>> 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 <reto@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Hasan
>>>>>
>>>>> On Tue, Feb 26, 2013 at 4:11 AM, Hasan <hasan@apache.org> 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
>>>>>
>>>>
>>>
>>
>


Mime
View raw message