You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by Reto Bachmann-Gmür <re...@apache.org> on 2013/04/29 09:49:53 UTC
Re: What's the current status on sparql 1.1?
Hi Minto
With you update to the latest jena we got closer to it :)
The plan is to drop the query parsing in clerezza and forward the query as
a string to the QueryableTcProvider (i.e. a provider supporting fastlane)
or to use the backend independent implementation (based on jena arq).
As the result formats didn't change with this changes sparql 1.1 will be
supported. What there is todo is:
- Adapt QueryEngine to take a String rather than a query
- Adapt implementation (arq based) and client of the QueryEngine
- Make TdbTcProvider implement QueryableTcProvider
- Forward query to fast- or slowlane using the Preparerser Hasan recently
implemented
Cheers,
Reto
On Fri, Apr 26, 2013 at 9:52 AM, Minto van der Sluis <mi...@multimach.com>wrote:
> Hi,
>
> I was wondering what the current status is on supporting sparql 1.1?
>
> Can I be of any help?
>
> Please let me know.
>
> Regards,
>
> Minto
>
Re: What's the current status on sparql 1.1?
Posted by Hasan <ha...@apache.org>.
Hi Minto, all
Sorry for being slow. I was on holiday and just returned yesterday.
I need to make some small changes in the preparser to return null if no
named graphs are specified in the query as discussed with Reto.
The preparser can be used with some limitations after this change (see
CLEREZZA-761).
Then, I'll implement an initial support of sparql update (LOAD, etc.).
I appreciate, if you can later help in completing the preparser with
support of
[125] ExistsFunc ::= 'EXISTS' GroupGraphPattern
[126] NotExistsFunc ::= 'NOT' 'EXISTS' GroupGraphPattern
Regards
Hasan
On Mon, Apr 29, 2013 at 9:49 AM, Reto Bachmann-Gmür <re...@apache.org> wrote:
> Hi Minto
>
> With you update to the latest jena we got closer to it :)
>
> The plan is to drop the query parsing in clerezza and forward the query as
> a string to the QueryableTcProvider (i.e. a provider supporting fastlane)
> or to use the backend independent implementation (based on jena arq).
>
> As the result formats didn't change with this changes sparql 1.1 will be
> supported. What there is todo is:
>
> - Adapt QueryEngine to take a String rather than a query
> - Adapt implementation (arq based) and client of the QueryEngine
> - Make TdbTcProvider implement QueryableTcProvider
> - Forward query to fast- or slowlane using the Preparerser Hasan recently
> implemented
>
> Cheers,
> Reto
>
>
> On Fri, Apr 26, 2013 at 9:52 AM, Minto van der Sluis <minto@multimach.com
> >wrote:
>
> > Hi,
> >
> > I was wondering what the current status is on supporting sparql 1.1?
> >
> > Can I be of any help?
> >
> > Please let me know.
> >
> > Regards,
> >
> > Minto
> >
>
Re: What's the current status on sparql 1.1?
Posted by Reto Bachmann-Gmür <re...@apache.org>.
On Tue, Apr 30, 2013 at 7:35 PM, Minto van der Sluis <mi...@xup.nl> wrote:
> Seems like QueryableTcProvider is already present, but not yet used.
> Have other part already been implemented as well? Shouldn't work like
> this, due to its intrusive nature, be done in a separate branch?
>
I assumed this might be feasible in an incremental way so that it would not
be so intrusive. A branch is needed when one wants to commit an
intermediate version that's not yet be regression free.
Cheers,
Reto
Re: What's the current status on sparql 1.1?
Posted by Minto van der Sluis <mi...@xup.nl>.
Hi Reto,
See remarks below.
Regards,
misl
[1] https://issues.apache.org/jira/browse/CLEREZZA-726
Op 29-4-2013 9:49, Reto Bachmann-Gmür schreef:
> Hi Minto
>
> With you update to the latest jena we got closer to it :)
I did some commits in a separate branch, see also [1]. There is however,
as far as I can tell, one issue that remains to fixed. A single module
contains a failing unittest.
Tomorrow (wednesday) I will check if usage of Clerezza still works as
expected. I hope someone else do the same for other parts of Clerezza.
> The plan is to drop the query parsing in clerezza and forward the query as
> a string to the QueryableTcProvider (i.e. a provider supporting fastlane)
> or to use the backend independent implementation (based on jena arq).
>
> As the result formats didn't change with this changes sparql 1.1 will be
> supported. What there is todo is:
>
> - Adapt QueryEngine to take a String rather than a query
> - Adapt implementation (arq based) and client of the QueryEngine
> - Make TdbTcProvider implement QueryableTcProvider
> - Forward query to fast- or slowlane using the Preparerser Hasan recently
> implemented
Seems like QueryableTcProvider is already present, but not yet used.
Have other part already been implemented as well? Shouldn't work like
this, due to its intrusive nature, be done in a separate branch?
I am not sure where to start when helping. I'll have a closer look when
at work (tomorrow).
> Cheers,
> Reto
>
>
> On Fri, Apr 26, 2013 at 9:52 AM, Minto van der Sluis <mi...@multimach.com>wrote:
>
>> Hi,
>>
>> I was wondering what the current status is on supporting sparql 1.1?
>>
>> Can I be of any help?
>>
>> Please let me know.
>>
>> Regards,
>>
>> Minto
>>
Re: Some Questions regarding implementing fastlane
Posted by Minto van der Sluis <mi...@xup.nl>.
Thanks Reto,
This clarifies the difference between fast-lane and slow-lane.
Regards,
Minto
Op 5-5-2013 19:37, Reto Bachmann-Gmür schreef:
> Hi Minto
>
> Great work updating the modules!
>
> Now to the questions.
>
>
>
>>> - Forward query to fast- or slowlane using the Preparerser Hasan recently
>>> implemented
>> Questions: Where is this decision taken? How to decide whether to use
>> QueryEngine of QueryableTcProvider ? Are these both fast-lane?
>>
> (Deferring the where question to when I write the code.)
> The QueryEngine is the slow-lane it works on any set of TripleCollections.
> QueryableTcProvider is the FastLane in that it might benefit from any
> optimization the backend provides it can only be used if the query only
> affects TripleCollections that are all provided by the same TcProvider (and
> this implements QueryableTcProvider).
>
>> - Make TdbTcProvider implement QueryableTcProvider
>> Question: Why is this needed if JenaSparqlEngine (implementation of
>> previous bullet) already takes care of this?
>>
> The JenaSparqleEngine works on any TripleCollections which are passed to
> Jena wrapped as Jena Graphs. JenaSparqlEngine can only access the data in
> these graphs via the provided filter method. The assumption is that TDB can
> handle (some) queries more efficiently by using its internal quad-store or
> other optimization techniques it could provide.
>
>> Of coarse I could wire Tdb*Providers to use JenaSparqlEngine. But I
>> don't see the point.
>>
> This shouldn't be wired to JenaSparqlEngine (only probably reuse response
> wrapping code) but forward the query directly to Jena rather than wrapping
> JenaGraphs as TripleCollections in the Tdb*Provider and wrapping these back
> to Jena Graphs for querying in the JenaSparqlEngine.
>
> Hope this makes things clearer.
>
> Cheers,
> Reto
>
--
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV
Mobiel: +31 (0) 626 014541
Re: Some Questions regarding implementing fastlane
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Hi Minto
Great work updating the modules!
Now to the questions.
> > - Forward query to fast- or slowlane using the Preparerser Hasan recently
> > implemented
> Questions: Where is this decision taken? How to decide whether to use
> QueryEngine of QueryableTcProvider ? Are these both fast-lane?
>
(Deferring the where question to when I write the code.)
The QueryEngine is the slow-lane it works on any set of TripleCollections.
QueryableTcProvider is the FastLane in that it might benefit from any
optimization the backend provides it can only be used if the query only
affects TripleCollections that are all provided by the same TcProvider (and
this implements QueryableTcProvider).
> - Make TdbTcProvider implement QueryableTcProvider
> Question: Why is this needed if JenaSparqlEngine (implementation of
> previous bullet) already takes care of this?
>
The JenaSparqleEngine works on any TripleCollections which are passed to
Jena wrapped as Jena Graphs. JenaSparqlEngine can only access the data in
these graphs via the provided filter method. The assumption is that TDB can
handle (some) queries more efficiently by using its internal quad-store or
other optimization techniques it could provide.
>
> Of coarse I could wire Tdb*Providers to use JenaSparqlEngine. But I
> don't see the point.
>
This shouldn't be wired to JenaSparqlEngine (only probably reuse response
wrapping code) but forward the query directly to Jena rather than wrapping
JenaGraphs as TripleCollections in the Tdb*Provider and wrapping these back
to Jena Graphs for querying in the JenaSparqlEngine.
Hope this makes things clearer.
Cheers,
Reto
Some Questions regarding implementing fastlane
Posted by Minto van der Sluis <mi...@xup.nl>.
Hi Reto,
I have some questions see below.
Regards,
misl
Op 29-4-2013 9:49, Reto Bachmann-Gmür schreef:
> Hi Minto
>
> With you update to the latest jena we got closer to it :)
>
> The plan is to drop the query parsing in clerezza and forward the query as
> a string to the QueryableTcProvider (i.e. a provider supporting fastlane)
> or to use the backend independent implementation (based on jena arq).
>
> As the result formats didn't change with this changes sparql 1.1 will be
> supported. What there is todo is:
>
> - Adapt QueryEngine to take a String rather than a query
(No question)
I didn't Modify QueryEngine to String as I think using Query is more
elegant.
> - Adapt implementation (arq based) and client of the QueryEngine
(No question)
QueryEngine client and implementation
- Client: Did some clean up (TcManger). Changes are basically DRY
releated.
- Implemention: adapted to instanceOf instead of exceptions.
> - Make TdbTcProvider implement QueryableTcProvider
Question: Why is this needed if JenaSparqlEngine (implementation of
previous bullet) already takes care of this?
Of coarse I could wire Tdb*Providers to use JenaSparqlEngine. But I
don't see the point.
> - Forward query to fast- or slowlane using the Preparerser Hasan recently
> implemented
Questions: Where is this decision taken? How to decide whether to use
QueryEngine of QueryableTcProvider ? Are these both fast-lane?