You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@epimorphics.com> on 2010/12/14 21:14:09 UTC
Re: [jira] Created: (JENA-9) LARQ as a separate module from ARQ
Be good to split out LARQ(++ for Solr etc etc) from ARQ.
Do you want to organise this as a separate LARQ component in JIRA?
Makes sense to me to have a separate tag if it's a separate code module.
On 13/12/10 15:15, Paolo Castagna (JIRA) wrote:
> LARQ as a separate module from ARQ
> ----------------------------------
>
> Key: JENA-9
> URL: https://issues.apache.org/jira/browse/JENA-9
> Project: Jena
> Issue Type: Test
> Components: ARQ
> Reporter: Paolo Castagna
> Priority: Minor
>
>
> LARQ can be extracted from ARQ as a separate module depending on ARQ.
>
> ARQ should not depend on LARQ (to avoid dependency cycles) and it
could check if LARQ is available in the classpath and wire the property
function in dynamically.
>
> LARQ can have a different release cycle from ARQ and people who do
not need free text search will not need to include Lucene in their
classpath.
>
> A separate (experimental) module is available here:
https://jena.svn.sourceforge.net/svnroot/jena/LARQ/trunk/
>
> List of things to do/decide includes:
>
> - Merge JENA-5 fix
> - Upgrade Lucene version to 2.9.3 and fix tests (if there are
failures).
> - Remove code using deprecated Lucene APIs and upgrade to Lucene 3.0.x.
> - Decide how many results to return when the user does not specify
it, 1000? More?
> - Should we use the index to suppress duplicates instead of
in-memory data structures?
> - How do we implement removals/unindex?
> - We could use the Model to decide when there are no more
triples with a specified literal and therefore it's ok to remove it from
Lucene.
> - See how the new NRT capabilities of Lucene can be used from LARQ.
> - Review package names (currently c.h.h.j.sparql.larq and
c.h.h.j.query.larq). Should we move to c.h.h.j.larq.*?
No rush here IMO, depending any bigger repackagization.
Andy
On 13/12/10 15:15, Paolo Castagna (JIRA) wrote:
> LARQ as a separate module from ARQ
> ----------------------------------
>
> Key: JENA-9
> URL: https://issues.apache.org/jira/browse/JENA-9
> Project: Jena
> Issue Type: Test
> Components: ARQ
> Reporter: Paolo Castagna
> Priority: Minor
>
>
> LARQ can be extracted from ARQ as a separate module depending on ARQ.
>
> ARQ should not depend on LARQ (to avoid dependency cycles) and it could check if LARQ is available in the classpath and wire the property function in dynamically.
>
> LARQ can have a different release cycle from ARQ and people who do not need free text search will not need to include Lucene in their classpath.
>
> A separate (experimental) module is available here: https://jena.svn.sourceforge.net/svnroot/jena/LARQ/trunk/
>
> List of things to do/decide includes:
>
> - Merge JENA-5 fix
> - Upgrade Lucene version to 2.9.3 and fix tests (if there are failures).
> - Remove code using deprecated Lucene APIs and upgrade to Lucene 3.0.x.
> - Decide how many results to return when the user does not specify it, 1000? More?
> - Should we use the index to suppress duplicates instead of in-memory data structures?
> - How do we implement removals/unindex?
> - We could use the Model to decide when there are no more triples with a specified literal and therefore it's ok to remove it from Lucene.
> - See how the new NRT capabilities of Lucene can be used from LARQ.
> - Review package names (currently c.h.h.j.sparql.larq and c.h.h.j.query.larq). Should we move to c.h.h.j.larq.*?
>
>
Re: [jira] Created: (JENA-9) LARQ as a separate module from ARQ
Posted by Paolo Castagna <ca...@googlemail.com>.
Andy Seaborne wrote:
> Be good to split out LARQ(++ for Solr etc etc) from ARQ.
Yep.
For others benefit, these are just proof of concepts:
SARQ is the same as LARQ, but using Solr:
https://github.com/castagna/SARQ
EARQ is the same as LARQ, but using ElasticSearch:
https://github.com/castagna/EARQ
... also, I've tried to redesign the code so that it's easy
for people to plug in different indexes. Still not perfect,
but a first step.
> Do you want to organise this as a separate LARQ component in JIRA?
Yes, please.
I don't think I can create a new "component" on JIRA, but it's a good idea.
> Makes sense to me to have a separate tag if it's a separate code module.
+1
Paolo
>
>
> On 13/12/10 15:15, Paolo Castagna (JIRA) wrote:
> > LARQ as a separate module from ARQ
> > ----------------------------------
> >
> > Key: JENA-9
> > URL: https://issues.apache.org/jira/browse/JENA-9
> > Project: Jena
> > Issue Type: Test
> > Components: ARQ
> > Reporter: Paolo Castagna
> > Priority: Minor
> >
> >
> > LARQ can be extracted from ARQ as a separate module depending on ARQ.
> >
> > ARQ should not depend on LARQ (to avoid dependency cycles) and it
> could check if LARQ is available in the classpath and wire the property
> function in dynamically.
> >
> > LARQ can have a different release cycle from ARQ and people who do
> not need free text search will not need to include Lucene in their
> classpath.
> >
> > A separate (experimental) module is available here:
> https://jena.svn.sourceforge.net/svnroot/jena/LARQ/trunk/
> >
> > List of things to do/decide includes:
> >
> > - Merge JENA-5 fix
> > - Upgrade Lucene version to 2.9.3 and fix tests (if there are
> failures).
> > - Remove code using deprecated Lucene APIs and upgrade to Lucene
> 3.0.x.
> > - Decide how many results to return when the user does not specify
> it, 1000? More?
> > - Should we use the index to suppress duplicates instead of
> in-memory data structures?
> > - How do we implement removals/unindex?
> > - We could use the Model to decide when there are no more
> triples with a specified literal and therefore it's ok to remove it from
> Lucene.
> > - See how the new NRT capabilities of Lucene can be used from LARQ.
> > - Review package names (currently c.h.h.j.sparql.larq and
> c.h.h.j.query.larq). Should we move to c.h.h.j.larq.*?
>
> No rush here IMO, depending any bigger repackagization.
>
> Andy
>
>
> On 13/12/10 15:15, Paolo Castagna (JIRA) wrote:
>> LARQ as a separate module from ARQ
>> ----------------------------------
>>
>> Key: JENA-9
>> URL: https://issues.apache.org/jira/browse/JENA-9
>> Project: Jena
>> Issue Type: Test
>> Components: ARQ
>> Reporter: Paolo Castagna
>> Priority: Minor
>>
>>
>> LARQ can be extracted from ARQ as a separate module depending on ARQ.
>>
>> ARQ should not depend on LARQ (to avoid dependency cycles) and it
>> could check if LARQ is available in the classpath and wire the
>> property function in dynamically.
>>
>> LARQ can have a different release cycle from ARQ and people who do not
>> need free text search will not need to include Lucene in their classpath.
>>
>> A separate (experimental) module is available here:
>> https://jena.svn.sourceforge.net/svnroot/jena/LARQ/trunk/
>>
>> List of things to do/decide includes:
>>
>> - Merge JENA-5 fix
>> - Upgrade Lucene version to 2.9.3 and fix tests (if there are
>> failures).
>> - Remove code using deprecated Lucene APIs and upgrade to Lucene 3.0.x.
>> - Decide how many results to return when the user does not specify
>> it, 1000? More?
>> - Should we use the index to suppress duplicates instead of
>> in-memory data structures?
>> - How do we implement removals/unindex?
>> - We could use the Model to decide when there are no more triples
>> with a specified literal and therefore it's ok to remove it from Lucene.
>> - See how the new NRT capabilities of Lucene can be used from LARQ.
>> - Review package names (currently c.h.h.j.sparql.larq and
>> c.h.h.j.query.larq). Should we move to c.h.h.j.larq.*?
>>
>>