Re: RUTA in Java: access object contents
Hi, We tested today and for us it looks like you also implemented already the access to values from annotation-less feature structures (so these derived from TOP)? In fact, we could access properly everything we needed, and there was a second commit after your email down below. So, great! It definitely helps on our use case. Thanks a ton :). Have a nice weekend, Best, Sebastian - Ursprüngliche Mail - Von: "Peter Klügl" <peter.klu...@averbis.com> An: "user" <user@uima.apache.org> Gesendet: Donnerstag, 29. September 2016 15:00:55 Betreff: Re: RUTA in Java: access object contents Hi, the first protypical implemenation is ready. What's supported right now is best observed in the new unit test named testFeatureStructureFeature() here: https://svn.apache.org/repos/asf/uima/ruta/trunk/ruta-core/src/test/java/org/apache/uima/ruta/expression/annotation/AnnotationFeatureExpressionTest.java Can you take a look at the functionality? Let me know this help in your use case and if you need something else. I'll add now some support for accessing feature values of feature structures where no annotations are required. Best, Peter Am 29.09.2016 um 10:44 schrieb Sebastian Schaaf: > Hi Peter, > > That's great, thanks a ton in advance! > For us this means we can proceed just in time with a task which requires the > new RUTA feature. > > Keeping fingers crossed. > > Best, > Sebastian > > - Ursprüngliche Mail - > Von: "Peter Klügl" <peter.klu...@averbis.com> > An: "user" <user@uima.apache.org> > Gesendet: Donnerstag, 29. September 2016 10:32:45 > Betreff: Re: RUTA in Java: access object contents > > Hi, > > > yes, I hope I can implement it today or tomorrow. > > > Best, > > > Peter > > > Am 29.09.2016 um 10:30 schrieb Sebastian Schaaf: >> Hi Peter, >> >> As yesterday the RUTA 2.5 release was announced (congrats :) ) and the end >> of the month is near: do you see chances to work on the ticket for feature >> structure support? >> >> Best, >> Sebastian >> >> >> - Ursprüngliche Mail - >> Von: "Sebastian Schaaf" <sebastian.sch...@scai.fraunhofer.de> >> An: "user" <user@uima.apache.org> >> Gesendet: Mittwoch, 14. September 2016 22:08:39 >> Betreff: Re: RUTA in Java: access object contents >> >> Sounds great, thank you in advance! >> Whatever comes up, don't hesitate to query back to us. >> >> Cheers, >> Sebastian >> >> >> - Ursprüngliche Mail - >> Von: "Peter Klügl" <peter.klu...@averbis.com> >> An: "user" <user@uima.apache.org> >> Gesendet: Mittwoch, 14. September 2016 18:33:56 >> Betreff: Re: RUTA in Java: access object contents >> >> Hi, >> >> >> I created an issue for it: https://issues.apache.org/jira/browse/UIMA-5108 >> >> >> I won't be able to fix it this week, and maybe not next week because of >> some deadlines. I guess it will be fixed at least in the trunk before of >> the end of the month. >> >> >> >> Best, >> >> >> Peter >> >> >> Am 14.09.2016 um 18:25 schrieb Sebastian Schaaf: >>> Hi Peter, >>> >>> Indeed, I was talking about UIMA objects. >>> >>> We tried to hunt down the error in deeper means and understood more of the >>> codes. Ahead of any details: again yes, we fail on types extending from >>> TOP. In our case it is "concept", which does not have a covering text. >>> >>> In "SimpleFeatureEx", the public method "getFeatures" contains a for loop >>> in which the different handleable cases are listed in some 'if else' >>> cascade - this one also contains the support for arrays you wrote about. >>> For our concept type the else case holds, so that an UIMA method >>> "getFeatureByBaseName" gets called. This one fails, because it checks if >>> the extracted feature comes from a type that extends from the type we want >>> to use the feature content for. In other words: our NormalizedNamedEntity >>> type (extending from Annotation) is queried for a feature contained in an >>> instance of type concept. As the latter one extends from TOP (and not from >>> NormalizedNamedEntity) getFeatureByBaseName throws the error. Although the >>> desired content is fine (we get the string we want!). >>> >>> We also tried to manipulate types, temporarily declaring concept extends >>> legally, so that this check does not fail.
Re: RUTA in Java: access object contents
Hi Peter, That's great, thanks a ton in advance! For us this means we can proceed just in time with a task which requires the new RUTA feature. Keeping fingers crossed. Best, Sebastian - Ursprüngliche Mail - Von: "Peter Klügl" <peter.klu...@averbis.com> An: "user" <user@uima.apache.org> Gesendet: Donnerstag, 29. September 2016 10:32:45 Betreff: Re: RUTA in Java: access object contents Hi, yes, I hope I can implement it today or tomorrow. Best, Peter Am 29.09.2016 um 10:30 schrieb Sebastian Schaaf: > Hi Peter, > > As yesterday the RUTA 2.5 release was announced (congrats :) ) and the end of > the month is near: do you see chances to work on the ticket for feature > structure support? > > Best, > Sebastian > > > - Ursprüngliche Mail - > Von: "Sebastian Schaaf" <sebastian.sch...@scai.fraunhofer.de> > An: "user" <user@uima.apache.org> > Gesendet: Mittwoch, 14. September 2016 22:08:39 > Betreff: Re: RUTA in Java: access object contents > > Sounds great, thank you in advance! > Whatever comes up, don't hesitate to query back to us. > > Cheers, > Sebastian > > > - Ursprüngliche Mail - > Von: "Peter Klügl" <peter.klu...@averbis.com> > An: "user" <user@uima.apache.org> > Gesendet: Mittwoch, 14. September 2016 18:33:56 > Betreff: Re: RUTA in Java: access object contents > > Hi, > > > I created an issue for it: https://issues.apache.org/jira/browse/UIMA-5108 > > > I won't be able to fix it this week, and maybe not next week because of > some deadlines. I guess it will be fixed at least in the trunk before of > the end of the month. > > > > Best, > > > Peter > > > Am 14.09.2016 um 18:25 schrieb Sebastian Schaaf: >> Hi Peter, >> >> Indeed, I was talking about UIMA objects. >> >> We tried to hunt down the error in deeper means and understood more of the >> codes. Ahead of any details: again yes, we fail on types extending from TOP. >> In our case it is "concept", which does not have a covering text. >> >> In "SimpleFeatureEx", the public method "getFeatures" contains a for loop in >> which the different handleable cases are listed in some 'if else' cascade - >> this one also contains the support for arrays you wrote about. For our >> concept type the else case holds, so that an UIMA method >> "getFeatureByBaseName" gets called. This one fails, because it checks if the >> extracted feature comes from a type that extends from the type we want to >> use the feature content for. In other words: our NormalizedNamedEntity type >> (extending from Annotation) is queried for a feature contained in an >> instance of type concept. As the latter one extends from TOP (and not from >> NormalizedNamedEntity) getFeatureByBaseName throws the error. Although the >> desired content is fine (we get the string we want!). >> >> We also tried to manipulate types, temporarily declaring concept extends >> legally, so that this check does not fail. And it is fine. For the moment, >> because regarding our environment this is not an option. Testing with ruta >> source codes to implement ourselves resulted in many lines of code to be >> subject to adaptation. Also, the variable 'result' in the discussed for loop >> may be changed in an inadequate way . we don't know about the details of >> RUTA. >> >> So, the question is may it be possible for you to implement the handling of >> cases where features extend from TOP? Maybe first as a patch, so that it has >> not to be integrated into your release. And we could test whether it fails >> in our setting. >> >> So far, >> Best, >> >> Sebastian >> >> - Ursprüngliche Mail - >> Von: "Peter Klügl" <peter.klu...@averbis.com> >> An: "user" <user@uima.apache.org> >> Gesendet: Montag, 12. September 2016 13:26:07 >> Betreff: Re: RUTA in Java: access object contents >> >> Hi, >> >> >> first of all: what do you mean exactly by "our objects" and "given Java >> objects"? Real Java objects of some arbitrary class or feature >> structures (annotations) in UIMA? I assume that you were referring to >> UIMA objects and the getters are the getters of features in JCasGen >> cover classes. If not, you can skip the answer below ;-) >> >> >> What you describe that should work just fine, if there weren't the >> feature structures (the types extending TOP). Plain feature structures >> are hardly s
Re: RUTA in Java: access object contents
Hi Peter, As yesterday the RUTA 2.5 release was announced (congrats :) ) and the end of the month is near: do you see chances to work on the ticket for feature structure support? Best, Sebastian - Ursprüngliche Mail - Von: "Sebastian Schaaf" <sebastian.sch...@scai.fraunhofer.de> An: "user" <user@uima.apache.org> Gesendet: Mittwoch, 14. September 2016 22:08:39 Betreff: Re: RUTA in Java: access object contents Sounds great, thank you in advance! Whatever comes up, don't hesitate to query back to us. Cheers, Sebastian - Ursprüngliche Mail - Von: "Peter Klügl" <peter.klu...@averbis.com> An: "user" <user@uima.apache.org> Gesendet: Mittwoch, 14. September 2016 18:33:56 Betreff: Re: RUTA in Java: access object contents Hi, I created an issue for it: https://issues.apache.org/jira/browse/UIMA-5108 I won't be able to fix it this week, and maybe not next week because of some deadlines. I guess it will be fixed at least in the trunk before of the end of the month. Best, Peter Am 14.09.2016 um 18:25 schrieb Sebastian Schaaf: > Hi Peter, > > Indeed, I was talking about UIMA objects. > > We tried to hunt down the error in deeper means and understood more of the > codes. Ahead of any details: again yes, we fail on types extending from TOP. > In our case it is "concept", which does not have a covering text. > > In "SimpleFeatureEx", the public method "getFeatures" contains a for loop in > which the different handleable cases are listed in some 'if else' cascade - > this one also contains the support for arrays you wrote about. For our > concept type the else case holds, so that an UIMA method > "getFeatureByBaseName" gets called. This one fails, because it checks if the > extracted feature comes from a type that extends from the type we want to use > the feature content for. In other words: our NormalizedNamedEntity type > (extending from Annotation) is queried for a feature contained in an instance > of type concept. As the latter one extends from TOP (and not from > NormalizedNamedEntity) getFeatureByBaseName throws the error. Although the > desired content is fine (we get the string we want!). > > We also tried to manipulate types, temporarily declaring concept extends > legally, so that this check does not fail. And it is fine. For the moment, > because regarding our environment this is not an option. Testing with ruta > source codes to implement ourselves resulted in many lines of code to be > subject to adaptation. Also, the variable 'result' in the discussed for loop > may be changed in an inadequate way . we don't know about the details of RUTA. > > So, the question is may it be possible for you to implement the handling of > cases where features extend from TOP? Maybe first as a patch, so that it has > not to be integrated into your release. And we could test whether it fails in > our setting. > > So far, > Best, > > Sebastian > > - Ursprüngliche Mail - > Von: "Peter Klügl" <peter.klu...@averbis.com> > An: "user" <user@uima.apache.org> > Gesendet: Montag, 12. September 2016 13:26:07 > Betreff: Re: RUTA in Java: access object contents > > Hi, > > > first of all: what do you mean exactly by "our objects" and "given Java > objects"? Real Java objects of some arbitrary class or feature > structures (annotations) in UIMA? I assume that you were referring to > UIMA objects and the getters are the getters of features in JCasGen > cover classes. If not, you can skip the answer below ;-) > > > What you describe that should work just fine, if there weren't the > feature structures (the types extending TOP). Plain feature structures > are hardly supported in Ruta mainly for historical reasons. And many > language elements do not make much sense without annotation offsets, > e.g., sequential matching, conditions like contains and partof, ... > > > There is no real technical reason that feature structures are not > completely supported, there was just no reason to support them. I > personally just extended Annotation instead of Feature Structure even if > there was no explicit semantics of the offsets. This is of course not an > option if you already have a type system. > > > I actually have to admit that I do not know right now where feature > structures are and are not supported in Ruta. I added some minimal > support for Arrays lately, and they are also just feature structures. I > have to take a look... > > > Back to your example: > > If you have > > - Type X extends Annotation with feature a with range A > > - Type A extends TOP with feature b with range B > >
Re: RUTA in Java: access object contents
Sounds great, thank you in advance! Whatever comes up, don't hesitate to query back to us. Cheers, Sebastian - Ursprüngliche Mail - Von: "Peter Klügl" <peter.klu...@averbis.com> An: "user" <user@uima.apache.org> Gesendet: Mittwoch, 14. September 2016 18:33:56 Betreff: Re: RUTA in Java: access object contents Hi, I created an issue for it: https://issues.apache.org/jira/browse/UIMA-5108 I won't be able to fix it this week, and maybe not next week because of some deadlines. I guess it will be fixed at least in the trunk before of the end of the month. Best, Peter Am 14.09.2016 um 18:25 schrieb Sebastian Schaaf: > Hi Peter, > > Indeed, I was talking about UIMA objects. > > We tried to hunt down the error in deeper means and understood more of the > codes. Ahead of any details: again yes, we fail on types extending from TOP. > In our case it is "concept", which does not have a covering text. > > In "SimpleFeatureEx", the public method "getFeatures" contains a for loop in > which the different handleable cases are listed in some 'if else' cascade - > this one also contains the support for arrays you wrote about. For our > concept type the else case holds, so that an UIMA method > "getFeatureByBaseName" gets called. This one fails, because it checks if the > extracted feature comes from a type that extends from the type we want to use > the feature content for. In other words: our NormalizedNamedEntity type > (extending from Annotation) is queried for a feature contained in an instance > of type concept. As the latter one extends from TOP (and not from > NormalizedNamedEntity) getFeatureByBaseName throws the error. Although the > desired content is fine (we get the string we want!). > > We also tried to manipulate types, temporarily declaring concept extends > legally, so that this check does not fail. And it is fine. For the moment, > because regarding our environment this is not an option. Testing with ruta > source codes to implement ourselves resulted in many lines of code to be > subject to adaptation. Also, the variable 'result' in the discussed for loop > may be changed in an inadequate way . we don't know about the details of RUTA. > > So, the question is may it be possible for you to implement the handling of > cases where features extend from TOP? Maybe first as a patch, so that it has > not to be integrated into your release. And we could test whether it fails in > our setting. > > So far, > Best, > > Sebastian > > - Ursprüngliche Mail - > Von: "Peter Klügl" <peter.klu...@averbis.com> > An: "user" <user@uima.apache.org> > Gesendet: Montag, 12. September 2016 13:26:07 > Betreff: Re: RUTA in Java: access object contents > > Hi, > > > first of all: what do you mean exactly by "our objects" and "given Java > objects"? Real Java objects of some arbitrary class or feature > structures (annotations) in UIMA? I assume that you were referring to > UIMA objects and the getters are the getters of features in JCasGen > cover classes. If not, you can skip the answer below ;-) > > > What you describe that should work just fine, if there weren't the > feature structures (the types extending TOP). Plain feature structures > are hardly supported in Ruta mainly for historical reasons. And many > language elements do not make much sense without annotation offsets, > e.g., sequential matching, conditions like contains and partof, ... > > > There is no real technical reason that feature structures are not > completely supported, there was just no reason to support them. I > personally just extended Annotation instead of Feature Structure even if > there was no explicit semantics of the offsets. This is of course not an > option if you already have a type system. > > > I actually have to admit that I do not know right now where feature > structures are and are not supported in Ruta. I added some minimal > support for Arrays lately, and they are also just feature structures. I > have to take a look... > > > Back to your example: > > If you have > > - Type X extends Annotation with feature a with range A > > - Type A extends TOP with feature b with range B > > - Type B extends TOP with feature z with range String > > ... you would normally write: > > X.a.b.z=="z"; > > to match on each annotation of type X, get the value of feature a of > annotation X, get the value of feature b of the feature structure of > type A, get the value of feature z of the feature structure of the type > B, and compare it to the string "z". > > > The short answer is that you can
Re: RUTA in Java: access object contents
Hi Peter, Indeed, I was talking about UIMA objects. We tried to hunt down the error in deeper means and understood more of the codes. Ahead of any details: again yes, we fail on types extending from TOP. In our case it is "concept", which does not have a covering text. In "SimpleFeatureEx", the public method "getFeatures" contains a for loop in which the different handleable cases are listed in some 'if else' cascade - this one also contains the support for arrays you wrote about. For our concept type the else case holds, so that an UIMA method "getFeatureByBaseName" gets called. This one fails, because it checks if the extracted feature comes from a type that extends from the type we want to use the feature content for. In other words: our NormalizedNamedEntity type (extending from Annotation) is queried for a feature contained in an instance of type concept. As the latter one extends from TOP (and not from NormalizedNamedEntity) getFeatureByBaseName throws the error. Although the desired content is fine (we get the string we want!). We also tried to manipulate types, temporarily declaring concept extends legally, so that this check does not fail. And it is fine. For the moment, because regarding our environment this is not an option. Testing with ruta source codes to implement ourselves resulted in many lines of code to be subject to adaptation. Also, the variable 'result' in the discussed for loop may be changed in an inadequate way . we don't know about the details of RUTA. So, the question is may it be possible for you to implement the handling of cases where features extend from TOP? Maybe first as a patch, so that it has not to be integrated into your release. And we could test whether it fails in our setting. So far, Best, Sebastian - Ursprüngliche Mail - Von: "Peter Klügl" <peter.klu...@averbis.com> An: "user" <user@uima.apache.org> Gesendet: Montag, 12. September 2016 13:26:07 Betreff: Re: RUTA in Java: access object contents Hi, first of all: what do you mean exactly by "our objects" and "given Java objects"? Real Java objects of some arbitrary class or feature structures (annotations) in UIMA? I assume that you were referring to UIMA objects and the getters are the getters of features in JCasGen cover classes. If not, you can skip the answer below ;-) What you describe that should work just fine, if there weren't the feature structures (the types extending TOP). Plain feature structures are hardly supported in Ruta mainly for historical reasons. And many language elements do not make much sense without annotation offsets, e.g., sequential matching, conditions like contains and partof, ... There is no real technical reason that feature structures are not completely supported, there was just no reason to support them. I personally just extended Annotation instead of Feature Structure even if there was no explicit semantics of the offsets. This is of course not an option if you already have a type system. I actually have to admit that I do not know right now where feature structures are and are not supported in Ruta. I added some minimal support for Arrays lately, and they are also just feature structures. I have to take a look... Back to your example: If you have - Type X extends Annotation with feature a with range A - Type A extends TOP with feature b with range B - Type B extends TOP with feature z with range String ... you would normally write: X.a.b.z=="z"; to match on each annotation of type X, get the value of feature a of annotation X, get the value of feature b of the feature structure of type A, get the value of feature z of the feature structure of the type B, and compare it to the string "z". The short answer is that you can access the getter just with the name of the feature. If this simple example does not work, then the reason is probably a simple instanceof comparing the feature structure to AnnotationFS. Allowing feature structures in feature expression only should not be much work. Do you want me to add this support in Ruta? However, I cannot promise that the changes will be part of the upcoming release. Best, Peter Am 12.09.2016 um 09:42 schrieb Sebastian Schaaf: > Dear all, > > As we needed to integrate a rule-based analysis engine into our UIMA > framework, we ended up using RUTA. The package was encouraging, we > proceeded well with projecting our ideas into RUTA (thanks to the > comprehensive documentation). > > We also saw that there are efforts to offer RUTA in plain Java code > for developers, ignoring the delivered workbench. We could integrate > it well with our modified type system, it is finally running. But, > and that's the reason for this email, currently we are stuck with > extracting some information from our objects, which is not > repres
RUTA in Java: access object contents AKA Re: Entwurf der Mail an Peter Klügl
Dear all, Although my initial message still contained the wrong heading, everybody else is invited to answer :). Best, Sebastian - Initial email - From: "Sebastian Schaaf" <sebastian.sch...@scai.fraunhofer.de> To: "user" <user@uima.apache.org> Sent: Montag, 12. September 2016 09:42:10 Topic: Re: Entwurf der Mail an Peter Klügl Dear all, As we needed to integrate a rule-based analysis engine into our UIMA framework, we ended up using RUTA. The package was encouraging, we proceeded well with projecting our ideas into RUTA (thanks to the comprehensive documentation). We also saw that there are efforts to offer RUTA in plain Java code for developers, ignoring the delivered workbench. We could integrate it well with our modified type system, it is finally running. But, and that's the reason for this email, currently we are stuck with extracting some information from our objects, which is not represented as simple feature. Leaving out the option to introduce major changes to our codes and not liking the idea of permanent workarounds, we were wondering if (and if not maybe when) there is the possibility to generically call methods on given Java objects. Precisely, we have objects with attributes being (linked from other) objects, plus respective getter methods. So, the information we need from our objects is retrievable by calling a getter X.getA, resulting in (background) object A which in turn knows a method .getB, resulting in the desired B (or more precisely: its string Z): ### Example ### Type X (extends Annotation, has offsets) Type A (extends TOP, has no offsets) Type B (extends TOP, has no offsets) String Z How to call "X.getA().getB().getZ()"? ## It appeared that RUTA is capable by some whatever (UIMA-?)magic to get e.g. the covered text of a text annotation by "X.coveredText", although the object only knows a "getCoveredText" method. Let's call it a 'pseudo-feature'. No idea how generic this is, but: if just querying "X.A" RUTA seems to do well, ultimately receiving A. While A is an object (simple data type expected, like integer and string?) everything stops. So no obvious chance to receive our B. Is there an easy, somewhat 'native' way to deal with object-derived data like in the case described above? Thanks in advance! Sebastian --- Sebastian Schaaf, M.Sc. Bioinformatics Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Department of Bioinformatics Schloss Birlinghoven D-53754 Sankt Augustin Room: C3-233 Tel.: +49 2241 14 2280 Email: sebastian.sch...@scai.fraunhofer.de Internet: http://www.scai.fraunhofer.de/
Re: Entwurf der Mail an Peter Klügl
Dear all, As we needed to integrate a rule-based analysis engine into our UIMA framework, we ended up using RUTA. The package was encouraging, we proceeded well with projecting our ideas into RUTA (thanks to the comprehensive documentation). We also saw that there are efforts to offer RUTA in plain Java code for developers, ignoring the delivered workbench. We could integrate it well with our modified type system, it is finally running. But, and that's the reason for this email, currently we are stuck with extracting some information from our objects, which is not represented as simple feature. Leaving out the option to introduce major changes to our codes and not liking the idea of permanent workarounds, we were wondering if (and if not maybe when) there is the possibility to generically call methods on given Java objects. Precisely, we have objects with attributes being (linked from other) objects, plus respective getter methods. So, the information we need from our objects is retrievable by calling a getter X.getA, resulting in (background) object A which in turn knows a method .getB, resulting in the desired B (or more precisely: its string Z): ### Example ### Type X (extends Annotation, has offsets) Type A (extends TOP, has no offsets) Type B (extends TOP, has no offsets) String Z How to call "X.getA().getB().getZ()"? ## It appeared that RUTA is capable by some whatever (UIMA-?)magic to get e.g. the covered text of a text annotation by "X.coveredText", although the object only knows a "getCoveredText" method. Let's call it a 'pseudo-feature'. No idea how generic this is, but: if just querying "X.A" RUTA seems to do well, ultimately receiving A. While A is an object (simple data type expected, like integer and string?) everything stops. So no obvious chance to receive our B. Is there an easy, somewhat 'native' way to deal with object-derived data like in the case described above? Thanks in advance! Sebastian --- Sebastian Schaaf, M.Sc. Bioinformatics Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Department of Bioinformatics Schloss Birlinghoven D-53754 Sankt Augustin Room: C3-233 Tel.: +49 2241 14 2280 Email: sebastian.sch...@scai.fraunhofer.de Internet: http://www.scai.fraunhofer.de/
Re: Problem writing ruta extensions
Peter Klügl pkluegl@... writes:
Hi,
Am 04.12.2013 18:33, schrieb Sebastian:
Hi,
I'm highly interested in ruta, and its potential applications in
industrial
applications. Right know I'm trying to create a simple toy condition
extension that is simply a case insensitive INLIST condition. It is
completely based on the InListCondition class, I also declared an
implementation of the IRutaConditionExtension interface.
With primitve types everything seems to work great, except when the
condition is used with a variable :
STRINGLIST MonthsList = {january, ...};
DECLARE Month;
ANY{INSENSITIVEINLIST(MonthsList) - MARK(Month)};
I get a class cast exception when the condition is being created,
because
MonthsList is a SimpleTypeExpression and I'm expecting a
StringListExpression.
Am I doing something wrong ? I suppose there is a way to resolve the
variable to the actual list, but I missed it somehow.
It's hard to say what went wrong. My first guess would be that there is
a problem in your extension. I just verified that INLIST works at all (I
haven't used it myself for a long time).
The example works with INLIST:
STRINGLIST MonthsList = {january};
DECLARE Month;
ANY{INLIST(MonthsList) - MARK(Month)};
Can you post the stacktrace of the exception? Or can you send me the
source code of your extension (in case you do not want to post it on a
public mailing list)?
Anyways, the usage of INLIST makes only sense if you want to work on
dynamic dictionaries that may change during rule execution. Have you
taken a look at the MARKFAST or TRIE action?
http://uima.apache.org/d/ruta-
current/tools.ruta.book.html#ugr.tools.ruta.language.actions.markfast
They already have options for case-insensitivity and are overall faster
and more powerful.
Best,
Peter
PS: You can, of course, also post a feature request on JIRA for adding a
case-insensitivity to the INLIST condition
Any ideas on how that could be done?
Regards
Sebastian
Hi Peter,
Before giving the code, let me explain why I'm interested in a case
insensitive inlist.
As far as I understand the behaviour of MARKFAST, it cannot be used with
more complex conditions than list containment. The problem with TRIE is that
it requires an external resource that is somewhat read from the file system,
whereas I'm interested in somehow embedding resources in jars and reading
them using classloader getResource capabilities (maybe I missed something
there too).
But you are right, I don't need a dynamic dictionary :)
Anyway, here's how I declared it :
public class CIInListCondition extends TerminalRutaCondition {
private StringListExpression stringList;
public CIInListCondition(StringListExpression list) {
super();
this.stringList = list;
}
@Override
public EvaluatedCondition eval(AnnotationFS annotation,
RuleElement element, RutaStream stream, InferenceCrowd crowd) {
String coveredText = annotation.getCoveredText();
if (StringUtils.isEmpty(coveredText))
return new EvaluatedCondition(this, false);
ListString sList = stringList.getList(element.getParent(),
stream);
return new EvaluatedCondition(this,
sList.contains(coveredText.toLowerCase()));
}
public StringListExpression getStringList() {
return stringList;
}
}
And the associated extension
public class CIInListConditionExtension implements IRutaConditionExtension {
private final String[] knownExtensions = new String[] {
INSENSITIVEINLIST };
private final Class?[] extensions = new Class[] {
CIInListCondition.class };
...
@Override
public AbstractRutaCondition createCondition(String name,
ListRutaExpression args) throws RutaParseException {
if (args != null args.size() == 1) {
System.out.println(args.get(0).getClass().getName()); // prints
org.apache.uima.ruta.expression.type.SimpleTypeExpression
System.out.println(((SimpleTypeExpression)args.get(0)).getTypeString()); //
prints MonthsList
if (!(args.get(0) instanceof StringListExpression)) {
}
} else {
throw new RutaParseException(
INSENSITIVEINLIST accepts exactly a
StringListExpression as arguments);
}
return new CIInListCondition((StringListExpression) args.get(0)); //
It Fails here
}
And here's the stack trace :
java.lang.ClassCastException:
org.apache.uima.ruta.expression.type.SimpleTypeExpression cannot be cast to
org.apache.uima.ruta.expression.list.StringListExpression
at
dictanova.genesis.textpreprocessing.ruta.CIInListConditionExtension.createCo
ndition(CIInListConditionExtension.java:68)
Regards,
Sebastian
Problem writing ruta extensions
Hi,
I'm highly interested in ruta, and its potential applications in industrial
applications. Right know I'm trying to create a simple toy condition
extension that is simply a case insensitive INLIST condition. It is
completely based on the InListCondition class, I also declared an
implementation of the IRutaConditionExtension interface.
With primitve types everything seems to work great, except when the
condition is used with a variable :
STRINGLIST MonthsList = {january, ...};
DECLARE Month;
ANY{INSENSITIVEINLIST(MonthsList) - MARK(Month)};
I get a class cast exception when the condition is being created, because
MonthsList is a SimpleTypeExpression and I'm expecting a StringListExpression.
Am I doing something wrong ? I suppose there is a way to resolve the
variable to the actual list, but I missed it somehow.
Any ideas on how that could be done?
Regards
Sebastian
I don't understand the benefits of CAS
I am writing on a state of the art analysis of frameworks for filtering and analysing information streams. I don't understand why annotators (or any pre-processing components) can only process Objects that specify JCas. Why is it not possible to process arbitrary objects? Best regards, Sebastian
