Re: UIMA Ruta next steps
On 14-01-31 04:39 AM, Peter Klügl wrote: It's now end of January. We (Martin and I) are currently quite busy, but the release process should be started soon. Here's the list of unresolved issues for this release: https://issues.apache.org/jira/browse/UIMA-3590?jql=project%20%3D%20UIMA%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.2.0ruta%22%20AND%20component%20%3D%20ruta%20ORDER%20BY%20priority%20DESC UIMA-3303 Add a way to alias types in RUTA (e.g. "IMPORT type AS alias") Alexandre, do you know when you are able to resolve this issue? We could maybe defer the missing piece to the next release. I will close this issue this weekend. The only thing missing is type aliases when strictImports mode is off. Best, Alexandre -- Alexandre Patry, Ph.D Chercheur / Researcher http://KeaText.com
Re: UIMA Ruta next steps
It's now end of January. We (Martin and I) are currently quite busy, but the release process should be started soon. Here's the list of unresolved issues for this release: https://issues.apache.org/jira/browse/UIMA-3590?jql=project%20%3D%20UIMA%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%222.2.0ruta%22%20AND%20component%20%3D%20ruta%20ORDER%20BY%20priority%20DESC UIMA-3303 Add a way to alias types in RUTA (e.g. "IMPORT type AS alias") Alexandre, do you know when you are able to resolve this issue? We could maybe defer the missing piece to the next release. UIMA-3495 Report ambiguous types in Ruta Editor UIMA-3533 Support new import functionality in Workbench I will try to implement both issues ASAP after UIMA-3303 is resolved UIMA-3347 Ruta: Missing False Positives in "Annotation Test" view This issue can be resolved. We should maybe set the default for "useAllTypes" to true. UIMA-3441 Ruta: Extend classpath for Annotation Test run Martin, can you please update the documentation and resolve the issue? UIMA-3309 Ruta: Filter file names in Query View Martin, can you please update the documentation and resolve the issue? UIMA-3469 Ruta: Annotation Browser View Extensions Martin, can you please update the documentation and resolve the issue? UIMA-3539 Prepare Ruta 2.2.0 release No work left here, I think. Best, 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
Re: UIMA Ruta next steps
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 > 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
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 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
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 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.toep...@uni-wuerzburg.de www: http://www.is.informatik.uni-wuerzburg.de/mitarbeiter/toepfer/
Re: UIMA Ruta next steps
+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 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.toep...@uni-wuerzburg.de www: http://www.is.informatik.uni-wuerzburg.de/mitarbeiter/toepfer/
Re: UIMA Ruta next steps
+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 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
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 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
+ 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 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
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 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
Am 10.01.2014 12:48, schrieb Richard Eckart de Castilho: > On 10.01.2014, at 09:29, Peter Klügl 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
On 10.01.2014, at 09:29, Peter Klügl 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
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
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 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
+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 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
+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 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
+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 >> >
Re: UIMA Ruta next steps
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 >
