Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of castagna.lists@googlemail.com
 designates 74.125.82.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=qOn7nmkq3UzfjJ/yyk0uOoBCe7yHhi7Mh7snKKYx3T44opGmEROqBH56hh0v4Yvim7
         4Olyf57gyg+VB9ZRh6fyaQrd2AE0js0jiR/z9Q96m/9cnIIcVMrmlP6NIdwLvRiN6uq+
         BHpVGuSozoY2arTOuEMcq1ks/ek9UQKNfsPo0=
Message-ID: <4DCA64A3.9050306@googlemail.com>
Date: Wed, 11 May 2011 11:27:47 +0100
From: Paolo Castagna <castagna.lists@googlemail.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: jena-dev@incubator.apache.org
Subject: Re: LARQ release
References: 
 <256063212.32065.1304935863217.JavaMail.tomcat@hel.zones.apache.org>
	<4DC90B0D.7060107@epimorphics.com>	<4DC91047.4030102@googlemail.com>
	<4DC9130A.8070702@epimorphics.com>	<4DC91C74.7000107@googlemail.com>
	<4DC91EFB.1070603@epimorphics.com>	<4DC9567A.6080601@googlemail.com>
	<4DC99B5E.9030804@epimorphics.com>
	<BANLkTinZvxnhaSLR4mx5gZNNNyYMnjGPAA@mail.gmail.com>
 <BANLkTimEFwc9g29rWRPZk9AXBuOqEz2cSg@mail.gmail.com>
 <4DCA54BF.5020108@epimorphics.com>
In-Reply-To: <4DCA54BF.5020108@epimorphics.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Andy,
short answer: I am happy to release LARQ and at the same time remove the
old/legacy LARQ from ARQ.

long answer: inline.

Paolo

Andy Seaborne wrote:
> I'm still unclear as to why we don't just release LARQ as the way to do 
> free text query with ARQ.  Are there circustances when a user would not 
> want to use LARQ - can we address them in LARQ in someway rather than 
> having the user need to know the difference?

A release of LARQ does not imply removing the old LARQ from ARQ.
The two could coexist.

Leaving the old LARQ in ARQ allows people to chose when they want
to migrate, they could upgrade ARQ without the need to migrate their
Lucene indexes (via reindexing). Removing LARQ from ARQ implies we
decide for them that when they upgrade ARQ they will also be using
the new LARQ. If they are using LARQ, an ARQ upgrade will not be
a drop-in replacement (a reindex is necessary).

The separate LARQ module adds new features (i.e. removals, duplicate
avoidance) and it's an upgrade to Lucene v3.1.0. I'd prefer to gather
some feedback from users before removing what's there in ARQ.

My proposal to gather some feedback from users would be to add the
new LARQ to Fuseki, as shown here: [1].

We are using LARQ, the separate module, with Fuseki in a small internal
pilot. We do not use the old/legacy LARQ included in ARQ because it does
not provide removals and therefore the free text index is not kept up-to
-date with the RDF indexes as people add/remove data.

It seems to me you are in favor of: "releasing LARQ + removing
LARQ from ARQ" at the same time.

> This seems sufficiently useful that we could declare ARQ 2.9.0.

Yes.

> It seems to me that it's better to take the hit of changing over now to 
> reduce long term support costs.

I am happy to release LARQ and at the same time remove the old/legacy
LARQ from ARQ.

For LARQ, the version number has little meaning at the moment. It could
be 0.9.0 to signal that it has not been used in production (AFAIK) or it
could be 1.0.0 (since LARQ is coming from ARQ anyway and it has been
around for a while).

AFAIK there are not pending changes from a code point of view.
However, I'd like to try to do a release "compliant" with the
release process at Apache (should it switch license to ASL? Why not?)

LARQ release needs to happen before we remove LARQ from ARQ.

LARQ release == Maven artifacts published on the Jena repo.
I don't see the need for a .tar.gz since LARQ is like a plug-in
for ARQ and it does not work on its own. It's a library aimed at
developers. Do you agree?

I'd like to publish the documentation for the new LARQ module here:
http://openjena.org/wiki/LARQ
... while things move further on the official Jena website.
What do you think?

For end users, it would be good to have LARQ included (by default)
in Fuseki.

Paolo

> 
>     Andy
> 

  [1] 
https://issues.apache.org/jira/secure/attachment/12478735/JENA-63_Fuseki_r8810.patch