Good to hear. Let me know if you need more. Yes, TOP is the common super type for feature structures.
I still had some more available time after I implemented the part for the feature (match) expressions. So I added also feature assignment. The issue is still open since there are many things still missing like FSArrays of Feature Structures, variables and list variables and so on. However, I do not know yet when I will add these. Best, Peter Am 30.09.2016 um 17:36 schrieb Sebastian Schaaf: > 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. 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 >>>>> 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/ >>>>>
