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/ >
