Re: UIMA Ruta next steps

[Peter Klügl <pk...@uni-wuerzburg.de>]

Hi,

I wonder if the next version should be 2.2.0 instead of 2.1.1 since the
new import syntax and functionality is not a small change and the
improvements in UIMA-2332 will maybe have a obvious impact for the users.

Any opinions?

Peter

Am 19.12.2013 15:28, schrieb Peter Klügl:
> Hi,
>
> I just want to start a discussion about the next release and maybe
> interesting directions for extensions.
>
> I am planning a bugfix release for the end of January, UIMA Ruta version
> 2.1.1
>
> List of the 26 already resolved issues for 2.1.1:
> https://issues.apache.org/jira/browse/UIMA-3342?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.1.1ruta%22%20AND%20component%20%3D%20ruta%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>
> List of currently unresolved issues:
> https://issues.apache.org/jira/browse/UIMA-2982?jql=project%20%3D%20UIMA%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20ruta%20ORDER%20BY%20priority%20DESC
>
> I think the following issues should (at least) be resolved in addition
> for 2.1.1 (some of them are already fixed, but the documentation is not
> yet up-to-date):
> - UIMA-3137: Cleanup Ruta launch configuration tabs
> - UIMA-3471: Arrays in Annotation Browser View
> - UIMA-3347: Ruta: Missing False Positives in "Annotation Test" view
> - UIMA-3286: Start anchor after optional literal
> - UIMA-3280: Option to specify vm arguments for Ruta launch config
> - UIMA-3283: Matching reference pointing outside of current window
> - UIMA-3303: Add a way to alias types in RUTA (e.g. "IMPORT type AS alias")
> - UIMA-3495: Report ambiguous types in Ruta Editor
> - UIMA-3441: Ruta: Extend classpath for Annotation Test run
> - UIMA-3469: Ruta: Annotation Browser View Extensions
> - UIMA-3275: Minor discrepencies in license and notice files
> - UIMA-3309: Ruta: Filter file names in Query View
> - UIMA-3485: Ruta: Workbench extension point for "Script execution finished"
>
> Maybe the issues for dropins-support should also be included.
>
> Are there any wishes/opinions which other issues should be included?
>
> ###
>
> Here are a few ideas of major changes for a 2.2.x or 3.x release:
>
> 1. Making UIMA Ruta faster
> There are four aspects that can be considered:
> a) Parallelization/Scale-Out, already supported by UIMA-AS and friends
> b) Improvements in the current implementation. I know of at least four
> code fragments that can be improved
> c) Add new language constructs that are simply faster in some
> situations. I am thinking of an FST implementation similar to JAPE Plus
> and of an extension of the dynamic anchoring towards the operator plan
> optimization of SystemT
> d) Write faster rules. Some rules are just faster than others. This
> leads to a cookbook for best practices
>
> 2. Improve support for coreference information
> There are some nice ideas of unification-based grammars that can be
> included in the rule language. It does not have to be as mature as in
> SProUT, but maybe something like in CAFETIERE. This would automatically
> solve the restriction of value assignments in actions vs conditions
>
> 3. Support arbitrary CAS collections in the Ruta Workbench
> The Workbench currently only supports normal xmi files. There is no
> concept of a collection reader or similar stuff. It would maybe be nice
> for some users, if the Workbench can operate on CASs stored in a
> database or on any collection reader.
>
> 4. Actually useful rule induction algorithm
> After about six implementations of supervised rule learners, I think I
> have an idea of the layout of an actually useful algorithm for Ruta. I
> think it's also the time to adapt some ideas of semi-supervised machine
> learning for rule-based systems.
>
> 5. Support generic type systems in the Workbench
> Sometimes you cannot avoid specifying the semantics of an annotation in
> the feature values instead of in the type. However, most of the tooling
> will be not as useful then, e.g., the Annotation Browser view shows only
> one type with a lot of annotations. There should be some additional,
> configurable views that support those situations.
>
>
> All opinions or wishes are welcome :-)
>
> Best,
>
> Peter
>

Re: UIMA Ruta next steps

[Martin Toepfer <ma...@uni-wuerzburg.de>]

I'll keep my eyes opened ;-) Peter already told me that the release 
process may take some time.

-- Martin

Am 10.01.2014 16:56, schrieb Marshall Schor:
> On 1/10/2014 6:29 AM, Peter Klügl wrote:
>> Btw, Martin volunteered as release manager for the upcoming ruta release
>> if nobody objects.
> Great!
>
> If you keep some notes about what you find might be missing or confusing on our
> web site's instructions for doing releases, you can improve our web site, too :-).
>
> One thing you'll need to get is an appropriate code signing key; instructions
> for that are on our website.
>
> -Marshall
>> Peter
>>
>> Am 07.01.2014 19:08, schrieb Martin Toepfer:
>>> +1 for "2.2.0" because there will be several improvements in the next
>>> release.
>>>
>>>> Martin
>>>> +1 for 2nd digit. Last digit be minor features and bug fixes.
>>>>
>>>> I usually update the 2nd digit by default when I do
>>>> releases and reserve the last digit for shoving in intermediate
>>>> maintenance revisions of the last release.
>>>>
>>>> -- Richard
>>>>
>>>> On 07.01.2014, at 13:17, Marshall Schor <ms...@schor.com> wrote:
>>>>
>>>>> +1 to having the 2nd digit increment if there are more than minor
>>>>> changes,
>>>>> especially if some of those changes might require some user action.
>>>>>
>>>>> -Marshall
>>>>> On 1/7/2014 5:13 AM, Peter Klügl wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I wonder if the next version should be 2.2.0 instead of 2.1.1 since
>>>>>> the
>>>>>> new import syntax and functionality is not a small change and the
>>>>>> improvements in UIMA-2332 will maybe have a obvious impact for the
>>>>>> users.
>>>>>>
>>>>>> Any opinions?
>>>>>>
>>>>>> Peter

-- 

MSc. Martin Toepfer      Raum: B008
Universität Würzburg     Tel.: +49-(0)931-31-81856
Am Hubland               Fax.: -
97074 Würzburg           mail: martin.toepfer@uni-wuerzburg.de

www: http://www.is.informatik.uni-wuerzburg.de/mitarbeiter/toepfer/

Re: UIMA Ruta next steps

[Marshall Schor <ms...@schor.com>]

On 1/10/2014 6:29 AM, Peter Klügl wrote:
> Btw, Martin volunteered as release manager for the upcoming ruta release
> if nobody objects.

Great!

If you keep some notes about what you find might be missing or confusing on our
web site's instructions for doing releases, you can improve our web site, too :-).

One thing you'll need to get is an appropriate code signing key; instructions
for that are on our website.

-Marshall
>
> Peter
>
> Am 07.01.2014 19:08, schrieb Martin Toepfer:
>> +1 for "2.2.0" because there will be several improvements in the next
>> release.
>>
>>> Martin
>>> +1 for 2nd digit. Last digit be minor features and bug fixes.
>>>
>>> I usually update the 2nd digit by default when I do
>>> releases and reserve the last digit for shoving in intermediate
>>> maintenance revisions of the last release.
>>>
>>> -- Richard
>>>
>>> On 07.01.2014, at 13:17, Marshall Schor <ms...@schor.com> wrote:
>>>
>>>> +1 to having the 2nd digit increment if there are more than minor
>>>> changes,
>>>> especially if some of those changes might require some user action.
>>>>
>>>> -Marshall
>>>> On 1/7/2014 5:13 AM, Peter Klügl wrote:
>>>>> Hi,
>>>>>
>>>>> I wonder if the next version should be 2.2.0 instead of 2.1.1 since
>>>>> the
>>>>> new import syntax and functionality is not a small change and the
>>>>> improvements in UIMA-2332 will maybe have a obvious impact for the
>>>>> users.
>>>>>
>>>>> Any opinions?
>>>>>
>>>>> Peter
>

Re: UIMA Ruta next steps

[Jörn Kottmann <ko...@gmail.com>]

On 01/10/2014 12:29 PM, Peter Klügl wrote:
> Btw, Martin volunteered as release manager for the upcoming ruta release
> if nobody objects.

+1

Jörn

Re: UIMA Ruta next steps

[Peter Klügl <pk...@uni-wuerzburg.de>]

Am 10.01.2014 17:03, schrieb Richard Eckart de Castilho:
> +1 to move to 6 or 7. It seems to me that projects are on the move to 7 now anyways.
> I just upgraded DKPro Core trunk to Java 7 because we start having dependencies
> that are built with Java 7. 
>
> Personally, I'd suggest upgrading to the level that is necessary. E.g. if you need
> features from Java 6 but not from Java 7, then going just to 6 would imho be better.

Then it will be java 6, I guess :-)

Peter


> -- Richard
>
> On 10.01.2014, at 13:53, Martin Toepfer <ma...@uni-wuerzburg.de> wrote:
>
>> +1 to move to Java 6. We sometimes use Ruta without the Eclipse workbench in applications. Java 7 would also be fine, however, I think we should not move to Java 8 until required.
>>
>> -- Martin
>>
>>> + 1 to move to Java 6 or Java 7  (or Java 8, GA due in mid-March).
>>>
>>> Here's my rationale (which will probably expose some of my ignorance about the
>>> Ruta details :-) ):
>>>
>>> Ruta is an Eclispe workbench.  This means that the way you use it is to run
>>> Eclipse, and then Ruta runs "within it".  [If Ruta is a thing which is used via
>>> being embedded into other systems, then the argument doesn't apply].
>>>
>>> So, forcing a dependency on Java 7 or 8 means you have to run just one app,
>>> namely, Eclipse, on that Java.  And Eclipse runs fine on Java 8 (candidates)
>>> already :-).
>>>
>>> So it's unlikely that will be much of an issue for your customers.
>>>
>>> This is in contrast to other deployments of UIMA things, where they're more
>>> likely (possibly) integrated into other systems, and those systems would need (a
>>> lot of testing- investment) to move to more recent versions of Java.
>>>
>>> -Marshall
>>> On 1/10/2014 7:04 AM, Peter Klügl wrote:
>>>> I know we already have talked about the strategy of the required java
>>>> version, but I think I have seen that ducc depends on java 6.
>>>>
>>>> I would like to move ruta also to java 6 since I could really need some
>>>> methods only available in java 6.
>>>>
>>>> Opinions?
>>>>
>>>> Peter

Re: UIMA Ruta next steps

[Richard Eckart de Castilho <re...@apache.org>]

+1 to move to 6 or 7. It seems to me that projects are on the move to 7 now anyways.
I just upgraded DKPro Core trunk to Java 7 because we start having dependencies
that are built with Java 7. 

Personally, I'd suggest upgrading to the level that is necessary. E.g. if you need
features from Java 6 but not from Java 7, then going just to 6 would imho be better.

-- Richard

On 10.01.2014, at 13:53, Martin Toepfer <ma...@uni-wuerzburg.de> wrote:

> +1 to move to Java 6. We sometimes use Ruta without the Eclipse workbench in applications. Java 7 would also be fine, however, I think we should not move to Java 8 until required.
> 
> -- Martin
> 
>> + 1 to move to Java 6 or Java 7  (or Java 8, GA due in mid-March).
>> 
>> Here's my rationale (which will probably expose some of my ignorance about the
>> Ruta details :-) ):
>> 
>> Ruta is an Eclispe workbench.  This means that the way you use it is to run
>> Eclipse, and then Ruta runs "within it".  [If Ruta is a thing which is used via
>> being embedded into other systems, then the argument doesn't apply].
>> 
>> So, forcing a dependency on Java 7 or 8 means you have to run just one app,
>> namely, Eclipse, on that Java.  And Eclipse runs fine on Java 8 (candidates)
>> already :-).
>> 
>> So it's unlikely that will be much of an issue for your customers.
>> 
>> This is in contrast to other deployments of UIMA things, where they're more
>> likely (possibly) integrated into other systems, and those systems would need (a
>> lot of testing- investment) to move to more recent versions of Java.
>> 
>> -Marshall
>> On 1/10/2014 7:04 AM, Peter Klügl wrote:
>>> I know we already have talked about the strategy of the required java
>>> version, but I think I have seen that ducc depends on java 6.
>>> 
>>> I would like to move ruta also to java 6 since I could really need some
>>> methods only available in java 6.
>>> 
>>> Opinions?
>>> 
>>> Peter

Re: UIMA Ruta next steps

[Martin Toepfer <ma...@uni-wuerzburg.de>]

+1 to move to Java 6. We sometimes use Ruta without the Eclipse 
workbench in applications. Java 7 would also be fine, however, I think 
we should not move to Java 8 until required.

-- Martin

> + 1 to move to Java 6 or Java 7  (or Java 8, GA due in mid-March).
>
> Here's my rationale (which will probably expose some of my ignorance about the
> Ruta details :-) ):
>
> Ruta is an Eclispe workbench.  This means that the way you use it is to run
> Eclipse, and then Ruta runs "within it".  [If Ruta is a thing which is used via
> being embedded into other systems, then the argument doesn't apply].
>
> So, forcing a dependency on Java 7 or 8 means you have to run just one app,
> namely, Eclipse, on that Java.  And Eclipse runs fine on Java 8 (candidates)
> already :-).
>
> So it's unlikely that will be much of an issue for your customers.
>
> This is in contrast to other deployments of UIMA things, where they're more
> likely (possibly) integrated into other systems, and those systems would need (a
> lot of testing- investment) to move to more recent versions of Java.
>
> -Marshall
> On 1/10/2014 7:04 AM, Peter Klügl wrote:
>> I know we already have talked about the strategy of the required java
>> version, but I think I have seen that ducc depends on java 6.
>>
>> I would like to move ruta also to java 6 since I could really need some
>> methods only available in java 6.
>>
>> Opinions?
>>
>> Peter
>>
>> Am 10.01.2014 12:29, schrieb Peter Klügl:
>>> Btw, Martin volunteered as release manager for the upcoming ruta release
>>> if nobody objects.
>>>
>>> Peter
>>>
>>> Am 07.01.2014 19:08, schrieb Martin Toepfer:
>>>> +1 for "2.2.0" because there will be several improvements in the next
>>>> release.
>>>>
>>>>> Martin
>>>>> +1 for 2nd digit. Last digit be minor features and bug fixes.
>>>>>
>>>>> I usually update the 2nd digit by default when I do
>>>>> releases and reserve the last digit for shoving in intermediate
>>>>> maintenance revisions of the last release.
>>>>>
>>>>> -- Richard
>>>>>
>>>>> On 07.01.2014, at 13:17, Marshall Schor <ms...@schor.com> wrote:
>>>>>
>>>>>> +1 to having the 2nd digit increment if there are more than minor
>>>>>> changes,
>>>>>> especially if some of those changes might require some user action.
>>>>>>
>>>>>> -Marshall
>>>>>> On 1/7/2014 5:13 AM, Peter Klügl wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I wonder if the next version should be 2.2.0 instead of 2.1.1 since
>>>>>>> the
>>>>>>> new import syntax and functionality is not a small change and the
>>>>>>> improvements in UIMA-2332 will maybe have a obvious impact for the
>>>>>>> users.
>>>>>>>
>>>>>>> Any opinions?
>>>>>>>
>>>>>>> Peter

-- 

MSc. Martin Toepfer      Raum: B008
Universität Würzburg     Tel.: +49-(0)931-31-81856
Am Hubland               Fax.: -
97074 Würzburg           mail: martin.toepfer@uni-wuerzburg.de

www: http://www.is.informatik.uni-wuerzburg.de/mitarbeiter/toepfer/

Re: UIMA Ruta next steps

[Peter Klügl <pk...@uni-wuerzburg.de>]

Am 10.01.2014 16:37, schrieb Marshall Schor:
> + 1 to move to Java 6 or Java 7  (or Java 8, GA due in mid-March).
>
> Here's my rationale (which will probably expose some of my ignorance about the
> Ruta details :-) ):
>
> Ruta is an Eclispe workbench.  This means that the way you use it is to run
> Eclipse, and then Ruta runs "within it".  [If Ruta is a thing which is used via
> being embedded into other systems, then the argument doesn't apply].

Not exactly. I would categorize the ruta "ecosystem" as a rule-based
analysis engine with additional eclipse-based tooling for developing
those rules (the workbench). We apply the analysis engines most of the
time within the workbench, but also in plain java end applications. I
also heart of people that use a plain text editor for writing their
rules. Both leads to a ruta-usage like a normal java library.

Anyways, I do not worry that dependecy on java 6 or 7 will cause
problems as I do not know of any ruta users or customers that require
java 5. It is not the first time that this topic is dicussed. If there
are requirements, I supose that they would already have called our
attention.

Thanks,

Peter


> So, forcing a dependency on Java 7 or 8 means you have to run just one app,
> namely, Eclipse, on that Java.  And Eclipse runs fine on Java 8 (candidates)
> already :-).
>
> So it's unlikely that will be much of an issue for your customers.
>
> This is in contrast to other deployments of UIMA things, where they're more
> likely (possibly) integrated into other systems, and those systems would need (a
> lot of testing- investment) to move to more recent versions of Java.
>
> -Marshall
> On 1/10/2014 7:04 AM, Peter Klügl wrote:
>> I know we already have talked about the strategy of the required java
>> version, but I think I have seen that ducc depends on java 6.
>>
>> I would like to move ruta also to java 6 since I could really need some
>> methods only available in java 6.
>>
>> Opinions?
>>
>> Peter
>>
>> Am 10.01.2014 12:29, schrieb Peter Klügl:
>>> Btw, Martin volunteered as release manager for the upcoming ruta release
>>> if nobody objects.
>>>
>>> Peter
>>>
>>> Am 07.01.2014 19:08, schrieb Martin Toepfer:
>>>> +1 for "2.2.0" because there will be several improvements in the next
>>>> release.
>>>>
>>>>> Martin
>>>>> +1 for 2nd digit. Last digit be minor features and bug fixes.
>>>>>
>>>>> I usually update the 2nd digit by default when I do
>>>>> releases and reserve the last digit for shoving in intermediate
>>>>> maintenance revisions of the last release.
>>>>>
>>>>> -- Richard
>>>>>
>>>>> On 07.01.2014, at 13:17, Marshall Schor <ms...@schor.com> wrote:
>>>>>
>>>>>> +1 to having the 2nd digit increment if there are more than minor
>>>>>> changes,
>>>>>> especially if some of those changes might require some user action.
>>>>>>
>>>>>> -Marshall
>>>>>> On 1/7/2014 5:13 AM, Peter Klügl wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I wonder if the next version should be 2.2.0 instead of 2.1.1 since
>>>>>>> the
>>>>>>> new import syntax and functionality is not a small change and the
>>>>>>> improvements in UIMA-2332 will maybe have a obvious impact for the
>>>>>>> users.
>>>>>>>
>>>>>>> Any opinions?
>>>>>>>
>>>>>>> Peter

Re: UIMA Ruta next steps

[Marshall Schor <ms...@schor.com>]

+ 1 to move to Java 6 or Java 7  (or Java 8, GA due in mid-March).

Here's my rationale (which will probably expose some of my ignorance about the
Ruta details :-) ):

Ruta is an Eclispe workbench.  This means that the way you use it is to run
Eclipse, and then Ruta runs "within it".  [If Ruta is a thing which is used via
being embedded into other systems, then the argument doesn't apply].

So, forcing a dependency on Java 7 or 8 means you have to run just one app,
namely, Eclipse, on that Java.  And Eclipse runs fine on Java 8 (candidates)
already :-).

So it's unlikely that will be much of an issue for your customers.

This is in contrast to other deployments of UIMA things, where they're more
likely (possibly) integrated into other systems, and those systems would need (a
lot of testing- investment) to move to more recent versions of Java.

-Marshall
On 1/10/2014 7:04 AM, Peter Klügl wrote:
> I know we already have talked about the strategy of the required java
> version, but I think I have seen that ducc depends on java 6.
>
> I would like to move ruta also to java 6 since I could really need some
> methods only available in java 6.
>
> Opinions?
>
> Peter
>
> Am 10.01.2014 12:29, schrieb Peter Klügl:
>> Btw, Martin volunteered as release manager for the upcoming ruta release
>> if nobody objects.
>>
>> Peter
>>
>> Am 07.01.2014 19:08, schrieb Martin Toepfer:
>>> +1 for "2.2.0" because there will be several improvements in the next
>>> release.
>>>
>>>> Martin
>>>> +1 for 2nd digit. Last digit be minor features and bug fixes.
>>>>
>>>> I usually update the 2nd digit by default when I do
>>>> releases and reserve the last digit for shoving in intermediate
>>>> maintenance revisions of the last release.
>>>>
>>>> -- Richard
>>>>
>>>> On 07.01.2014, at 13:17, Marshall Schor <ms...@schor.com> wrote:
>>>>
>>>>> +1 to having the 2nd digit increment if there are more than minor
>>>>> changes,
>>>>> especially if some of those changes might require some user action.
>>>>>
>>>>> -Marshall
>>>>> On 1/7/2014 5:13 AM, Peter Klügl wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I wonder if the next version should be 2.2.0 instead of 2.1.1 since
>>>>>> the
>>>>>> new import syntax and functionality is not a small change and the
>>>>>> improvements in UIMA-2332 will maybe have a obvious impact for the
>>>>>> users.
>>>>>>
>>>>>> Any opinions?
>>>>>>
>>>>>> Peter
>

Re: UIMA Ruta next steps

[Peter Klügl <pk...@uni-wuerzburg.de>]

I know we already have talked about the strategy of the required java
version, but I think I have seen that ducc depends on java 6.

I would like to move ruta also to java 6 since I could really need some
methods only available in java 6.

Opinions?

Peter

Am 10.01.2014 12:29, schrieb Peter Klügl:
> Btw, Martin volunteered as release manager for the upcoming ruta release
> if nobody objects.
>
> Peter
>
> Am 07.01.2014 19:08, schrieb Martin Toepfer:
>> +1 for "2.2.0" because there will be several improvements in the next
>> release.
>>
>>> Martin
>>> +1 for 2nd digit. Last digit be minor features and bug fixes.
>>>
>>> I usually update the 2nd digit by default when I do
>>> releases and reserve the last digit for shoving in intermediate
>>> maintenance revisions of the last release.
>>>
>>> -- Richard
>>>
>>> On 07.01.2014, at 13:17, Marshall Schor <ms...@schor.com> wrote:
>>>
>>>> +1 to having the 2nd digit increment if there are more than minor
>>>> changes,
>>>> especially if some of those changes might require some user action.
>>>>
>>>> -Marshall
>>>> On 1/7/2014 5:13 AM, Peter Klügl wrote:
>>>>> Hi,
>>>>>
>>>>> I wonder if the next version should be 2.2.0 instead of 2.1.1 since
>>>>> the
>>>>> new import syntax and functionality is not a small change and the
>>>>> improvements in UIMA-2332 will maybe have a obvious impact for the
>>>>> users.
>>>>>
>>>>> Any opinions?
>>>>>
>>>>> Peter

Re: UIMA Ruta next steps

[Peter Klügl <pk...@uni-wuerzburg.de>]

Am 10.01.2014 12:48, schrieb Richard Eckart de Castilho:
> On 10.01.2014, at 09:29, Peter Klügl <pk...@uni-wuerzburg.de> wrote:
>
>> Btw, Martin volunteered as release manager for the upcoming ruta release
>> if nobody objects.
> I don't see why anybody should object. But maybe you can act as a first
> reviewer to take some load off Marshall.

Of course :-)

Since Martin is sitting in the room next to me, it will be easy to help
him with the release process.

Peter

> -- Richard

Re: UIMA Ruta next steps

[Richard Eckart de Castilho <re...@apache.org>]

On 10.01.2014, at 09:29, Peter Klügl <pk...@uni-wuerzburg.de> wrote:

> Btw, Martin volunteered as release manager for the upcoming ruta release
> if nobody objects.

I don't see why anybody should object. But maybe you can act as a first
reviewer to take some load off Marshall.

-- Richard

Re: UIMA Ruta next steps

[Peter Klügl <pk...@uni-wuerzburg.de>]

Btw, Martin volunteered as release manager for the upcoming ruta release
if nobody objects.

Peter

Am 07.01.2014 19:08, schrieb Martin Toepfer:
> +1 for "2.2.0" because there will be several improvements in the next
> release.
>
>> Martin
>
>> +1 for 2nd digit. Last digit be minor features and bug fixes.
>>
>> I usually update the 2nd digit by default when I do
>> releases and reserve the last digit for shoving in intermediate
>> maintenance revisions of the last release.
>>
>> -- Richard
>>
>> On 07.01.2014, at 13:17, Marshall Schor <ms...@schor.com> wrote:
>>
>>> +1 to having the 2nd digit increment if there are more than minor
>>> changes,
>>> especially if some of those changes might require some user action.
>>>
>>> -Marshall
>>> On 1/7/2014 5:13 AM, Peter Klügl wrote:
>>>> Hi,
>>>>
>>>> I wonder if the next version should be 2.2.0 instead of 2.1.1 since
>>>> the
>>>> new import syntax and functionality is not a small change and the
>>>> improvements in UIMA-2332 will maybe have a obvious impact for the
>>>> users.
>>>>
>>>> Any opinions?
>>>>
>>>> Peter
>>
>

Re: Re: UIMA Ruta next steps

[Martin Toepfer <ma...@uni-wuerzburg.de>]

+1 for "2.2.0" because there will be several improvements in the next release.

> Martin

> +1 for 2nd digit. Last digit be minor features and bug fixes.
>
> I usually update the 2nd digit by default when I do
> releases and reserve the last digit for shoving in intermediate
> maintenance revisions of the last release.
>
> -- Richard
>
> On 07.01.2014, at 13:17, Marshall Schor <ms...@schor.com> wrote:
>
>> +1 to having the 2nd digit increment if there are more than minor changes,
>> especially if some of those changes might require some user action.
>>
>> -Marshall
>> On 1/7/2014 5:13 AM, Peter Klügl wrote:
>>> Hi,
>>>
>>> I wonder if the next version should be 2.2.0 instead of 2.1.1 since the
>>> new import syntax and functionality is not a small change and the
>>> improvements in UIMA-2332 will maybe have a obvious impact for the users.
>>>
>>> Any opinions?
>>>
>>> Peter
>

Re: UIMA Ruta next steps

[Richard Eckart de Castilho <re...@apache.org>]

+1 for 2nd digit. Last digit be minor features and bug fixes.

I usually update the 2nd digit by default when I do
releases and reserve the last digit for shoving in intermediate
maintenance revisions of the last release.

-- Richard

On 07.01.2014, at 13:17, Marshall Schor <ms...@schor.com> wrote:

> +1 to having the 2nd digit increment if there are more than minor changes,
> especially if some of those changes might require some user action. 
> 
> -Marshall
> On 1/7/2014 5:13 AM, Peter Klügl wrote:
>> Hi,
>> 
>> I wonder if the next version should be 2.2.0 instead of 2.1.1 since the
>> new import syntax and functionality is not a small change and the
>> improvements in UIMA-2332 will maybe have a obvious impact for the users.
>> 
>> Any opinions?
>> 
>> Peter

Re: UIMA Ruta next steps

[Marshall Schor <ms...@schor.com>]

+1 to having the 2nd digit increment if there are more than minor changes,
especially if some of those changes might require some user action. 

-Marshall
On 1/7/2014 5:13 AM, Peter Klügl wrote:
> Hi,
>
> I wonder if the next version should be 2.2.0 instead of 2.1.1 since the
> new import syntax and functionality is not a small change and the
> improvements in UIMA-2332 will maybe have a obvious impact for the users.
>
> Any opinions?
>
> Peter
>
> Am 19.12.2013 15:28, schrieb Peter Klügl:
>> Hi,
>>
>> I just want to start a discussion about the next release and maybe
>> interesting directions for extensions.
>>
>> I am planning a bugfix release for the end of January, UIMA Ruta version
>> 2.1.1
>>
>> List of the 26 already resolved issues for 2.1.1:
>> https://issues.apache.org/jira/browse/UIMA-3342?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.1.1ruta%22%20AND%20component%20%3D%20ruta%20AND%20status%20in%20(Resolved%2C%20Closed)%20ORDER%20BY%20priority%20DESC
>>
>> List of currently unresolved issues:
>> https://issues.apache.org/jira/browse/UIMA-2982?jql=project%20%3D%20UIMA%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20ruta%20ORDER%20BY%20priority%20DESC
>>
>> I think the following issues should (at least) be resolved in addition
>> for 2.1.1 (some of them are already fixed, but the documentation is not
>> yet up-to-date):
>> - UIMA-3137: Cleanup Ruta launch configuration tabs
>> - UIMA-3471: Arrays in Annotation Browser View
>> - UIMA-3347: Ruta: Missing False Positives in "Annotation Test" view
>> - UIMA-3286: Start anchor after optional literal
>> - UIMA-3280: Option to specify vm arguments for Ruta launch config
>> - UIMA-3283: Matching reference pointing outside of current window
>> - UIMA-3303: Add a way to alias types in RUTA (e.g. "IMPORT type AS alias")
>> - UIMA-3495: Report ambiguous types in Ruta Editor
>> - UIMA-3441: Ruta: Extend classpath for Annotation Test run
>> - UIMA-3469: Ruta: Annotation Browser View Extensions
>> - UIMA-3275: Minor discrepencies in license and notice files
>> - UIMA-3309: Ruta: Filter file names in Query View
>> - UIMA-3485: Ruta: Workbench extension point for "Script execution finished"
>>
>> Maybe the issues for dropins-support should also be included.
>>
>> Are there any wishes/opinions which other issues should be included?
>>
>> ###
>>
>> Here are a few ideas of major changes for a 2.2.x or 3.x release:
>>
>> 1. Making UIMA Ruta faster
>> There are four aspects that can be considered:
>> a) Parallelization/Scale-Out, already supported by UIMA-AS and friends
>> b) Improvements in the current implementation. I know of at least four
>> code fragments that can be improved
>> c) Add new language constructs that are simply faster in some
>> situations. I am thinking of an FST implementation similar to JAPE Plus
>> and of an extension of the dynamic anchoring towards the operator plan
>> optimization of SystemT
>> d) Write faster rules. Some rules are just faster than others. This
>> leads to a cookbook for best practices
>>
>> 2. Improve support for coreference information
>> There are some nice ideas of unification-based grammars that can be
>> included in the rule language. It does not have to be as mature as in
>> SProUT, but maybe something like in CAFETIERE. This would automatically
>> solve the restriction of value assignments in actions vs conditions
>>
>> 3. Support arbitrary CAS collections in the Ruta Workbench
>> The Workbench currently only supports normal xmi files. There is no
>> concept of a collection reader or similar stuff. It would maybe be nice
>> for some users, if the Workbench can operate on CASs stored in a
>> database or on any collection reader.
>>
>> 4. Actually useful rule induction algorithm
>> After about six implementations of supervised rule learners, I think I
>> have an idea of the layout of an actually useful algorithm for Ruta. I
>> think it's also the time to adapt some ideas of semi-supervised machine
>> learning for rule-based systems.
>>
>> 5. Support generic type systems in the Workbench
>> Sometimes you cannot avoid specifying the semantics of an annotation in
>> the feature values instead of in the type. However, most of the tooling
>> will be not as useful then, e.g., the Annotation Browser view shows only
>> one type with a lot of annotations. There should be some additional,
>> configurable views that support those situations.
>>
>>
>> All opinions or wishes are welcome :-)
>>
>> Best,
>>
>> Peter
>>
>