From uima-user-returnmelissalambert@example.org Wed Apr 01 02:21:15 2009 Return-Path: <uima-user-returnmelissalambert@example.org> Delivered-To: melissalambert@example.org Received: (qmail 94217 invoked from network); 1 Apr 2009 02:21:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Apr 2009 02:21:15 -0000 Received: (qmail 69248 invoked by uid 500); 1 Apr 2009 02:21:14 -0000 Delivered-To: melissalambert@example.org Received: (qmail 69198 invoked by uid 500); 1 Apr 2009 02:21:14 -0000 Mailing-List: contact melissalambert@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:melissalambert@example.org> List-Unsubscribe: <mailto:melissalambert@example.org> List-Post: <mailto:melissalambert@example.org> List-Id: <uima-user.incubator.apache.org> Reply-To: melissalambert@example.org Delivered-To: mailing list melissalambert@example.org Received: (qmail 69188 invoked by uid 99); 1 Apr 2009 02:21:14 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Apr 2009 02:21:14 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO micmail1.mantech.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Apr 2009 02:21:08 +0000 X-SENDER-IP: 83.161.120.155 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.39,305,1235970000"; d="scan'208";a="9470881" Received: from chnmicmbn02.mantech.com (HELO CHNMICMB03.ManTech.com) ([83.161.120.155]) by micmail1.mantech.com with ESMTP; 31 Mar 2009 22:20:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: User configuration params in CPE descriptor Date: Tue, 31 Mar 2009 22:19:53 -0400 Message-ID: <melissalambert@example.org> In-Reply-To: <melissalambert@example.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: User configuration params in CPE descriptor Thread-Index: AcmyQ+XYg9OVHVGWR4au87miXxXuigAJzJ5A References: <melissalambert@example.org> <melissalambert@example.org> From: "Duan, Nick" <melissalambert@example.org> To: <melissalambert@example.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org In CPE component descriptors (AE, Collection Reader, and CASConsumer), one = can specify user-defined parameters in the <ConfigurationParameters/> and <= ConfigurationParameterSettings/> elements. Are there similar tags in CPE d= escriptor? What would be the API for retrieving the parameter values? I a= m trying to define some run-time parameters for the CPE. It would be conve= nient to have the parameters in the CPE descriptor. Otherwise, I would hav= e to define them in a property file, and that means more code to maintain a= nd more configurations for the end user... Nick=20 -----Original Message----- From: Eddie Epstein [mailto:melissalambert@example.org]=20 Sent: Tuesday, March 31, 2009 5:01 PM To: melissalambert@example.org Subject: Re: User configuration params in CPE descriptor I think this means having parameter overrides in a CPE descriptor, and I'm pretty sure the answer is yes. Not supported by cpeGui. Eddie On Tue, Mar 31, 2009 at 3:13 PM, Jaroslaw Cwiklik <melissalambert@example.org> wrote: > Not sure I understand what it is you are trying to accomplish. > Please provide more detail. > > JC > > > Is there any way to specify a user-defined parameter in CPE descriptor > (like what you can do in CPE components' descriptors)? > > Thanks! > > Nick > This communication, along with any attachments, is covered by federal and > state law governing electronic communications and may contain company > proprietary and legally privileged information. > If the reader of this message is not the intended recipient, you are here= by > notified that any dissemination, distribution, use or copying of this > message is strictly prohibited. > If you have received this in error, please reply immediately to the sender > and delete this message. =A0Thank you. > This communication, along with any attachments, is covered by federal and s= tate law governing electronic communications and may contain company propri= etary and legally privileged information. =20 If the reader of this message is not the intended recipient, you are hereby= notified that any dissemination, distribution, use or copying of this mess= age is strictly prohibited. =20 If you have received this in error, please reply immediately to the sender = and delete this message. Thank you. From uima-user-returnmelissalambert@example.org Wed Apr 01 08:18:33 2009 Return-Path: <uima-user-returnmelissalambert@example.org> Delivered-To: melissalambert@example.org Received: (qmail 45401 invoked from network); 1 Apr 2009 08:18:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Apr 2009 08:18:33 -0000 Received: (qmail 75374 invoked by uid 500); 1 Apr 2009 08:18:32 -0000 Delivered-To: melissalambert@example.org Received: (qmail 75302 invoked by uid 500); 1 Apr 2009 08:18:32 -0000 Mailing-List: contact melissalambert@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:melissalambert@example.org> List-Unsubscribe: <mailto:melissalambert@example.org> List-Post: <mailto:melissalambert@example.org> List-Id: <uima-user.incubator.apache.org> Reply-To: melissalambert@example.org Delivered-To: mailing list melissalambert@example.org Received: (qmail 75291 invoked by uid 99); 1 Apr 2009 08:18:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Apr 2009 08:18:32 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of melissalambert@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-fx0-f172.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Apr 2009 08:18:23 +0000 Received: by fxm20 with SMTP id 20so2677316fxm.12 for <melissalambert@example.org>; Wed, 01 Apr 2009 01:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=o4k7OPD0YG1aNTI+wp1xE8zNTLAmQ4JRT8qa5B83TnQ=; b=uLAaduhusQU2vxPDramdLieZFuKmF+fbcGHgz2vxCImgU6bpuwWuXypiIOPYo6YOFI CZcVaFU7RFCvlqNxT4vSTl77TjQsMsI4uR6zjEGJlEwcIH2pJ4PPNyGlzh4xP2WbF7Ep zGVXKIsTpzzBVwPwx1UFBF+qP+5rjhQoVk2+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=aLJemxAR7o15nVxHRYhomqQSjw20B6ML5T22Yxv7azbv4m3ijedAYeYt/aua1vu4BT xZrjp8CUYZ0KxMAu/2Xs8nqwvsmm4h5vKT/oIycykJn8jtm9RakiaRgMsKTbu5zjARON Q72e/hJ/iYTH5ymW3Tg/OwQmfU05z1nlvB7Dk= Received: by 83.161.120.155 with SMTP id a10mr2695580muh.26.1238573881982; Wed, 01 Apr 2009 01:18:01 -0700 (PDT) Received: from ?83.161.120.155? (p54BAECA3.dip.t-dialin.net [83.161.120.155]) by mx.google.com with ESMTPS id w5sm13483459mue.33.283.161.120.155.17.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Apr 2009 01:18:01 -0700 (PDT) Message-Id: <melissalambert@example.org> From: =?ISO-8859-1?Q?J=F6rn_Kottmann?= <melissalambert@example.org> To: melissalambert@example.org In-Reply-To: <melissalambert@example.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: UIMA AS as OSGI bundle Date: Wed, 1 Apr 2009 10:17:52 +0200 References: <melissalambert@example.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On Mar 31, 2009, at 9:47 PM, Jaroslaw Cwiklik wrote: > J=F6rn, not sure how I feel about this yet. What you are proposing is =20= > to add a > list of dependent jars into the > manifest.mf files found in the Uima AS jars. There may be a problem =20= > with > this. ActiveMQ jars, for example, > are named differently in each release.Some users (perhaps) may want to > switch between say AMQ 5.2.2 and 4.1.1 and with a hard > dependency in the manifest there may be a runtime problem. How do you > resolve such a problem? In the OSGI manifest the Import-Package (or Required-Bundle) defines =20 on what the bundle depends, dependencies are then resolved by the OSGI runtime. In our case it should be fine to define a dependency on activemq 4.1.1 or higher, right ? J=F6rn= From uima-user-returnmelissalambert@example.org Wed Apr 01 14:15:20 2009 Return-Path: <uima-user-returnmelissalambert@example.org> Delivered-To: melissalambert@example.org Received: (qmail 64099 invoked from network); 1 Apr 2009 14:15:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Apr 2009 14:15:19 -0000 Received: (qmail 96759 invoked by uid 500); 1 Apr 2009 14:15:19 -0000 Delivered-To: melissalambert@example.org Received: (qmail 96715 invoked by uid 500); 1 Apr 2009 14:15:19 -0000 Mailing-List: contact melissalambert@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:melissalambert@example.org> List-Unsubscribe: <mailto:melissalambert@example.org> List-Post: <mailto:melissalambert@example.org> List-Id: <uima-user.incubator.apache.org> Reply-To: melissalambert@example.org Delivered-To: mailing list melissalambert@example.org Received: (qmail 96705 invoked by uid 99); 1 Apr 2009 14:15:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Apr 2009 14:15:19 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of melissalambert@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO yx-out-1718.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Apr 2009 14:15:12 +0000 Received: by yx-out-1718.google.com with SMTP id 36so46680yxh.0 for <melissalambert@example.org>; Wed, 01 Apr 2009 07:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nekeRE8PkrMtsgrjdcsEjorRDEMGpu17n/t1O8zyCgE=; b=mIXSavIwuEPcdY21N+8gI0phslKpwy6qJs1p14lshTNH1GI4wDNGGkIpMT0uk2/xXx evKjMKyaXHuVWh8a2YKoVHT5rCPgEzXLCfPJzBkF4DfHlvz5EwglCS+WTyafs5cG9D0h WdoqUsxcgcGRdnNgrl1CGTXrcMKLDihkgjtnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=LR9Tmoed/T+6V8DFSm+Tpiwp81MyzZ3/1jgpPqJOiSAyFzIWv4iQp88DCnS7CSREqs r+QIyLe+5B0UMwMTqcO2wkUmumEOmRyCQ+OY97MVGQd2QtLe/YONGCnLsS/ybjkcsFtF NW2eLn+xphbDU+kGVEt//FSCjp0YQ5q3Cp4Ak= MIME-Version: 1.0 Sender: melissalambert@example.org Received: by 83.161.120.155 with SMTP id 2mr6397158ann.79.1238595282716; Wed, 01 Apr 2009 07:14:42 -0700 (PDT) In-Reply-To: <melissalambert@example.org> References: <melissalambert@example.org> <melissalambert@example.org> <melissalambert@example.org> Date: Wed, 1 Apr 2009 10:14:42 -0400 X-Google-Sender-Auth: d4c2fcd564495b9a Message-ID: <melissalambert@example.org> Subject: Re: User configuration params in CPE descriptor From: Adam Lally <melissalambert@example.org> To: melissalambert@example.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Mar 31, 2009 at 10:19 PM, Duan, Nick <melissalambert@example.org> wrote: > In CPE component descriptors (AE, Collection Reader, and CASConsumer), on= e can specify user-defined parameters in the <ConfigurationParameters/> and= <ConfigurationParameterSettings/> elements. =A0Are there similar tags in C= PE descriptor? Yes, there's a <configurationParameterSettings> tag that you can use in the CPE descriptor to set parameter values for each of the CPE components. Documentation is here (see section 83.161.120.155): http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/doc= s/html/references/references.html#ugr.ref.xml.cpe_descriptor.descriptor.cas= _processors.individual >What would be the API for retrieving the parameter values? I am trying to define some run-time parameters for the CPE. It would be convenient to have the parameters in the CPE descriptor. Otherwise, I would have to define them in a property file, and that means more code to maintain and more configurations for the end user... > I forget the exact API, but look at the Javadocs for CpeDescription. The API structure should more or less be parallel with the XML format. -Adam From uima-user-returnmelissalambert@example.org Thu Apr 02 11:23:55 2009 Return-Path: <uima-user-returnmelissalambert@example.org> Delivered-To: melissalambert@example.org Received: (qmail 36205 invoked from network); 2 Apr 2009 11:23:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2009 11:23:54 -0000 Received: (qmail 96425 invoked by uid 500); 2 Apr 2009 11:23:54 -0000 Delivered-To: melissalambert@example.org Received: (qmail 96332 invoked by uid 500); 2 Apr 2009 11:23:54 -0000 Mailing-List: contact melissalambert@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:melissalambert@example.org> List-Unsubscribe: <mailto:melissalambert@example.org> List-Post: <mailto:melissalambert@example.org> List-Id: <uima-user.incubator.apache.org> Reply-To: melissalambert@example.org Delivered-To: mailing list melissalambert@example.org Received: (qmail 96322 invoked by uid 99); 2 Apr 2009 11:23:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 11:23:54 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO mailrelay.rz.uni-wuerzburg.de) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 11:23:46 +0000 Received: from virusscan.mail (localhost [83.161.120.155]) by mailrelay.mail (Postfix) with ESMTP id C6078199159 for <melissalambert@example.org>; Thu, 2 Apr 2009 13:23:23 +0200 (CEST) Received: from localhost (localhost [83.161.120.155]) by virusscan.mail (Postfix) with ESMTP id B6D91199155 for <melissalambert@example.org>; Thu, 2 Apr 2009 13:23:23 +0200 (CEST) Received: from [83.161.120.155] (win6093.informatik.uni-wuerzburg.de [83.161.120.155]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 8DBC71990E6 for <melissalambert@example.org>; Thu, 2 Apr 2009 13:23:23 +0200 (CEST) Message-ID: <melissalambert@example.org> Date: Thu, 02 Apr 2009 13:23:23 +0200 From: =?ISO-8859-15?Q?Peter_Kl=FCgl?= <melissalambert@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090302) MIME-Version: 1.0 To: melissalambert@example.org Subject: Problem accessing annotations in a window Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by melissalambert@example.org X-Virus-Checked: Checked by ClamAV on apache.org Hello, I have a problem accessing annotations, especially annotations of a given type in a window represented by another annotation. I am using type priorities but not in this concrete situation. Therefore i am not using the subiterator to access the contained annotations, but several other methods like this one: public List<AnnotationFS> getAnnotationsInWindow( AnnotationFS windowAnnotation, Type type) { List<AnnotationFS> result = new ArrayList<AnnotationFS>(); FSIterator completeIt = getCas().getAnnotationIndex().iterator(); if (getDocumentAnnotation().getEnd() < windowAnnotation.getEnd()) { completeIt.moveToLast(); } else { completeIt.moveTo(windowAnnotation); } while (completeIt.isValid() && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation .getBegin()) { completeIt.moveToPrevious(); } if (completeIt.isValid()) { completeIt.moveToNext(); } else { completeIt.moveToFirst(); } while (completeIt.isValid() && ((Annotation) completeIt.get()).getBegin() < windowAnnotation .getBegin()) { completeIt.moveToNext(); } while (completeIt.isValid() && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation .getBegin()) { Annotation annotation = (Annotation) completeIt.get(); if (getCas().getTypeSystem().subsumes(type, annotation.getType()) && annotation.getEnd() <= windowAnnotation.getEnd()) { result.add(annotation); } completeIt.moveToNext(); } return result; } I tried already many variations of this (e.g., with the index of the given type, using a new created frame with a higher type priority), but this method returns sometimes simply wrong annotations or no melissalambert@example.org. The only method that seems to work all the time is to iterate over all annotations of the given type and then filter those that are not contained in the window. My problem occurs in many different shapes. Here's one short example: Arguments: windowAnnotation: Annotation sofa: _InitialView begin: 10899 end: 10906 Covered Text: {.8}Bar type: de.uniwue.casetrain.Answers.answerText Information in the eclipse debug view (Variables): SubAnnotations: [0] WordAnswer sofa: _InitialView begin: 10899 end: 10906 SimpleFeedback: <null> PosFactor: 0.8 NegFactor: 0.0 InstanceIsUserAnswer: false Text: <null> IsRegularExpression: false EditDistance: 0 [1] WordAnswer sofa: _InitialView begin: 10886 end: 10892 SimpleFeedback: <null> PosFactor: 1.0 NegFactor: 0.0 InstanceIsUserAnswer: false Text: answerText sofa: _InitialView begin: 10889 end: 10892 IsRegularExpression: false EditDistance: 0 [2] paragraph sofa: _InitialView begin: 10899 end: 10906 ... [20] answerText sofa: _InitialView begin: 10903 end: 10906 ...and so on.... In this example the method above simply stops at the second annotations since start offset is smaller than the one of the window. How can this be? Is the position in the index depending on the values of the features? Did I miss something here? In other examples the method above just steps over the important annotations. Using the brute force approach is not really a solution for me; it slows down my system by more than 50%. I would really appreciate any hints to solve this problem since this method/functionality is quite essential for my application. Of course, i would also not reject any advice about performance. Best regards Peter From uima-user-returnmelissalambert@example.org Thu Apr 02 12:14:54 2009 Return-Path: <uima-user-returnmelissalambert@example.org> Delivered-To: melissalambert@example.org Received: (qmail 59533 invoked from network); 2 Apr 2009 12:14:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2009 12:14:54 -0000 Received: (qmail 62812 invoked by uid 500); 2 Apr 2009 12:14:53 -0000 Delivered-To: melissalambert@example.org Received: (qmail 62760 invoked by uid 500); 2 Apr 2009 12:14:53 -0000 Mailing-List: contact melissalambert@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:melissalambert@example.org> List-Unsubscribe: <mailto:melissalambert@example.org> List-Post: <mailto:melissalambert@example.org> List-Id: <uima-user.incubator.apache.org> Reply-To: melissalambert@example.org Delivered-To: mailing list melissalambert@example.org Received: (qmail 62750 invoked by uid 99); 2 Apr 2009 12:14:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 12:14:53 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of melissalambert@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail.gmx.net) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 02 Apr 2009 12:14:44 +0000 Received: (qmail invoked by alias); 02 Apr 2009 12:14:23 -0000 Received: from blueice4n1.de.ibm.com (EHLO [83.161.120.155]) [83.161.120.155] by mail.gmx.net (mp015) with SMTP; 02 Apr 2009 14:14:23 +0200 X-Authenticated: #25330878 X-Provags-ID: V01U2FsdGVkX1/r/4Qvyp3rkyKXiAxiLd90CQoeokY981AMtoT/BK qDhLc60RzQ2VqG Message-ID: <melissalambert@example.org> Date: Thu, 02 Apr 2009 14:14:23 +0200 From: Thilo Goetz <melissalambert@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090302) MIME-Version: 1.0 To: melissalambert@example.org Subject: Re: Problem accessing annotations in a window References: <melissalambert@example.org> In-Reply-To: <melissalambert@example.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 X-Virus-Checked: Checked by ClamAV on apache.org Hi Peter, I see one issue with your code: you're using the windowAnnotation to position the iterator. Instead, you should be using an annotation of the type you're searching for. This is because annotations are sorted by type as well. If you don't specify explicit type priorities, it doesn't mean that no type priority will be used. It just means that the type priority is arbitrary. I think our documentation is misleading in this respect, I was confused myself when I just read it. The net effect of this is that you can't reliably position an iterator where you're looking for annotations of type a with an annotation of type b. If you were just looking for annotations of a specific type, you could change your code like this: // Warning: untested windowAnnotation = getCas().createAnnotation(type, windowAnnotation.getBegin(), windowAnnotation.getEnd()); However, you also appear to be interested in annotations of subtypes of your input type. Those might be ordered differently again. So what to do? You can either use explicit type priorities (a PITA and not recommended), or you use an annotation for iterator positioning that's guaranteed to position the iterator in front of the first annotation you're interested in. For example, you could do this: AnnotationFS posFS = getCas().createAnnotation(type, windowAnnotation.getBegin(), windowAnnotation.getEnd() + 1); The type could be any annotation type, but note the increased end position. This will get your iterator positioned before, but not necessarily on the first desired annotation. You would then use your original windowAnnotation to check that the FSs you're iterating over are in range. This trick is necessary because you simply can't know how types are ordered in the absence of explicit type priorities. It seems to me like we should really have a built-in API that does this. Most people don't care or even know about type priorities, so the subiterator stuff is often useless. Or we could add yet another flag to the subiterator API, boolean ignoreTypeOrder. --Thilo Peter Klügl wrote: > Hello, > > I have a problem accessing annotations, especially annotations of a > given type in a window represented by another annotation. I am using > type priorities but not in this concrete situation. Therefore i am not > using the subiterator to access the contained annotations, but several > other methods like this one: > > public List<AnnotationFS> getAnnotationsInWindow( > AnnotationFS windowAnnotation, Type type) { > List<AnnotationFS> result = new ArrayList<AnnotationFS>(); > FSIterator completeIt = getCas().getAnnotationIndex().iterator(); > if (getDocumentAnnotation().getEnd() < windowAnnotation.getEnd()) { > completeIt.moveToLast(); > } else { > completeIt.moveTo(windowAnnotation); > } > while (completeIt.isValid() > && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation > .getBegin()) { > completeIt.moveToPrevious(); > } > > if (completeIt.isValid()) { > completeIt.moveToNext(); > } else { > completeIt.moveToFirst(); > } > > while (completeIt.isValid() > && ((Annotation) completeIt.get()).getBegin() < windowAnnotation > .getBegin()) { > completeIt.moveToNext(); > } > > while (completeIt.isValid() > && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation > .getBegin()) { > Annotation annotation = (Annotation) completeIt.get(); > if (getCas().getTypeSystem().subsumes(type, annotation.getType()) > && annotation.getEnd() <= windowAnnotation.getEnd()) { > result.add(annotation); > } > completeIt.moveToNext(); > } > return result; > } > > I tried already many variations of this (e.g., with the index of the > given type, using a new created frame with a higher type priority), but > this method returns sometimes simply wrong annotations or no annotations > at all. The only method that seems to work all the time is to iterate > over all annotations of the given type and then filter those that are > not contained in the window. > > My problem occurs in many different shapes. Here's one short example: > > Arguments: > > windowAnnotation: > Annotation > sofa: _InitialView > begin: 10899 > end: 10906 > Covered Text: {.8}Bar > > type: > de.uniwue.casetrain.Answers.answerText > > > Information in the eclipse debug view (Variables): > SubAnnotations: > [0] > WordAnswer > sofa: _InitialView > begin: 10899 > end: 10906 > SimpleFeedback: <null> > PosFactor: 0.8 > NegFactor: 0.0 > InstanceIsUserAnswer: false > Text: <null> > IsRegularExpression: false > EditDistance: 0 > [1] > WordAnswer > sofa: _InitialView > begin: 10886 > end: 10892 > SimpleFeedback: <null> > PosFactor: 1.0 > NegFactor: 0.0 > InstanceIsUserAnswer: false > Text: answerText > sofa: _InitialView > begin: 10889 > end: 10892 > IsRegularExpression: false > EditDistance: 0 > [2] > paragraph > sofa: _InitialView > begin: 10899 > end: 10906 > ... > [20] > answerText > sofa: _InitialView > begin: 10903 > end: 10906 > > ...and so on.... > > In this example the method above simply stops at the second annotations > since start offset is smaller than the one of the window. How can this > be? Is the position in the index depending on the values of the > features? Did I miss something here? In other examples the method above > just steps over the important annotations. Using the brute force > approach is not really a solution for me; it slows down my system by > more than 50%. > > I would really appreciate any hints to solve this problem since this > method/functionality is quite essential for my application. Of course, i > would also not reject any advice about performance. > > Best regards > > Peter From uima-user-returnmelissalambert@example.org Thu Apr 02 13:41:07 2009 Return-Path: <uima-user-returnmelissalambert@example.org> Delivered-To: melissalambert@example.org Received: (qmail 27400 invoked from network); 2 Apr 2009 13:41:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2009 13:41:07 -0000 Received: (qmail 69292 invoked by uid 500); 2 Apr 2009 13:41:07 -0000 Delivered-To: melissalambert@example.org Received: (qmail 69259 invoked by uid 500); 2 Apr 2009 13:41:07 -0000 Mailing-List: contact melissalambert@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:melissalambert@example.org> List-Unsubscribe: <mailto:melissalambert@example.org> List-Post: <mailto:melissalambert@example.org> List-Id: <uima-user.incubator.apache.org> Reply-To: melissalambert@example.org Delivered-To: mailing list melissalambert@example.org Received: (qmail 69249 invoked by uid 99); 2 Apr 2009 13:41:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 13:41:07 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO mailrelay.rz.uni-wuerzburg.de) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 13:40:57 +0000 Received: from virusscan.mail (localhost [83.161.120.155]) by mailrelay.mail (Postfix) with ESMTP id 8B0BA199133 for <melissalambert@example.org>; Thu, 2 Apr 2009 15:40:36 +0200 (CEST) Received: from localhost (localhost [83.161.120.155]) by virusscan.mail (Postfix) with ESMTP id 77236199141 for <melissalambert@example.org>; Thu, 2 Apr 2009 15:40:36 +0200 (CEST) Received: from [83.161.120.155] (win6093.informatik.uni-wuerzburg.de [83.161.120.155]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 5A282A07DE for <melissalambert@example.org>; Thu, 2 Apr 2009 15:40:36 +0200 (CEST) Message-ID: <melissalambert@example.org> Date: Thu, 02 Apr 2009 15:40:36 +0200 From: =?ISO-8859-15?Q?Peter_Kl=FCgl?= <melissalambert@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090302) MIME-Version: 1.0 To: melissalambert@example.org Subject: Re: Problem accessing annotations in a window References: <melissalambert@example.org> <melissalambert@example.org> In-Reply-To: <melissalambert@example.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by melissalambert@example.org X-Virus-Checked: Checked by ClamAV on apache.org Hi Thilo, first of all, thanks for the detailed answer. I will try the approach with the increased end offset of the window, but I fear that this won't change the results (but should result in some speedup). I already added the additional code fragment in the methods in order to get the correct start position irrespective of the type order: while (completeIt.isValid() && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation .getBegin()) { completeIt.moveToPrevious(); } if (completeIt.isValid()) { completeIt.moveToNext(); } else { completeIt.moveToFirst(); } This should ignore all different orders of types in the index. Beside that, I also tried to use the same type in the window annotation and even a new window with an explictly defined type priority resulting in a (theoretically) correct starting position. But none of those methods returns always the correct list of contained annotations. I must have made a mistake somewhere... for example see the example with the debug information I added to my last mail. How can it be possible that an annotation is "disrespecting" the begin/end indexing strategy? Is it possible that changing a feature value without removeFromIndex/addToIndex can confuse the index in this way? I already started to make a guess. I would love such an ignoreTypeOrder flag. I will try some things now and get back to you with the results. Peter Thilo Goetz schrieb: > Hi Peter, > > I see one issue with your code: you're using the windowAnnotation > to position the iterator. Instead, you should be using an > annotation of the type you're searching for. This is because > annotations are sorted by type as well. If you don't specify > explicit type priorities, it doesn't mean that no type priority > will be used. It just means that the type priority is arbitrary. > I think our documentation is misleading in this respect, I was > confused myself when I just read it. > > The net effect of this is that you can't reliably position an > iterator where you're looking for annotations of type a with an > annotation of type b. If you were just looking for annotations > of a specific type, you could change your code like this: > > // Warning: untested > windowAnnotation = getCas().createAnnotation(type, windowAnnotation.getBegin(), > windowAnnotation.getEnd()); > > However, you also appear to be interested in annotations of subtypes > of your input type. Those might be ordered differently again. > > So what to do? > > You can either use explicit type priorities (a PITA and not recommended), > or you use an annotation for iterator positioning that's guaranteed to > position the iterator in front of the first annotation you're interested > in. For example, you could do this: > > AnnotationFS posFS = getCas().createAnnotation(type, > windowAnnotation.getBegin(), windowAnnotation.getEnd() + 1); > > The type could be any annotation type, but note the increased end position. > This will get your iterator positioned before, but not necessarily on > the first desired annotation. You would then use your original > windowAnnotation to check that the FSs you're iterating over are in > range. > > This trick is necessary because you simply can't know how types are > ordered in the absence of explicit type priorities. > > It seems to me like we should really have a built-in API that does > this. Most people don't care or even know about type priorities, > so the subiterator stuff is often useless. Or we could add yet > another flag to the subiterator API, boolean ignoreTypeOrder. > > --Thilo > > > Peter Klügl wrote: > >> Hello, >> >> I have a problem accessing annotations, especially annotations of a >> given type in a window represented by another annotation. I am using >> type priorities but not in this concrete situation. Therefore i am not >> using the subiterator to access the contained annotations, but several >> other methods like this one: >> >> public List<AnnotationFS> getAnnotationsInWindow( >> AnnotationFS windowAnnotation, Type type) { >> List<AnnotationFS> result = new ArrayList<AnnotationFS>(); >> FSIterator completeIt = getCas().getAnnotationIndex().iterator(); >> if (getDocumentAnnotation().getEnd() < windowAnnotation.getEnd()) { >> completeIt.moveToLast(); >> } else { >> completeIt.moveTo(windowAnnotation); >> } >> while (completeIt.isValid() >> && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation >> .getBegin()) { >> completeIt.moveToPrevious(); >> } >> >> if (completeIt.isValid()) { >> completeIt.moveToNext(); >> } else { >> completeIt.moveToFirst(); >> } >> >> while (completeIt.isValid() >> && ((Annotation) completeIt.get()).getBegin() < windowAnnotation >> .getBegin()) { >> completeIt.moveToNext(); >> } >> >> while (completeIt.isValid() >> && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation >> .getBegin()) { >> Annotation annotation = (Annotation) completeIt.get(); >> if (getCas().getTypeSystem().subsumes(type, annotation.getType()) >> && annotation.getEnd() <= windowAnnotation.getEnd()) { >> result.add(annotation); >> } >> completeIt.moveToNext(); >> } >> return result; >> } >> >> I tried already many variations of this (e.g., with the index of the >> given type, using a new created frame with a higher type priority), but >> this method returns sometimes simply wrong annotations or no annotations >> at all. The only method that seems to work all the time is to iterate >> over all annotations of the given type and then filter those that are >> not contained in the window. >> >> My problem occurs in many different shapes. Here's one short example: >> >> Arguments: >> >> windowAnnotation: >> Annotation >> sofa: _InitialView >> begin: 10899 >> end: 10906 >> Covered Text: {.8}Bar >> >> type: >> de.uniwue.casetrain.Answers.answerText >> >> >> Information in the eclipse debug view (Variables): >> SubAnnotations: >> [0] >> WordAnswer >> sofa: _InitialView >> begin: 10899 >> end: 10906 >> SimpleFeedback: <null> >> PosFactor: 0.8 >> NegFactor: 0.0 >> InstanceIsUserAnswer: false >> Text: <null> >> IsRegularExpression: false >> EditDistance: 0 >> [1] >> WordAnswer >> sofa: _InitialView >> begin: 10886 >> end: 10892 >> SimpleFeedback: <null> >> PosFactor: 1.0 >> NegFactor: 0.0 >> InstanceIsUserAnswer: false >> Text: answerText >> sofa: _InitialView >> begin: 10889 >> end: 10892 >> IsRegularExpression: false >> EditDistance: 0 >> [2] >> paragraph >> sofa: _InitialView >> begin: 10899 >> end: 10906 >> ... >> [20] >> answerText >> sofa: _InitialView >> begin: 10903 >> end: 10906 >> >> ...and so on.... >> >> In this example the method above simply stops at the second annotations >> since start offset is smaller than the one of the window. How can this >> be? Is the position in the index depending on the values of the >> features? Did I miss something here? In other examples the method above >> just steps over the important annotations. Using the brute force >> approach is not really a solution for me; it slows down my system by >> more than 50%. >> >> I would really appreciate any hints to solve this problem since this >> method/functionality is quite essential for my application. Of course, i >> would also not reject any advice about performance. >> >> Best regards >> >> Peter >> From uima-user-returnmelissalambert@example.org Thu Apr 02 13:53:07 2009 Return-Path: <uima-user-returnmelissalambert@example.org> Delivered-To: melissalambert@example.org Received: (qmail 37086 invoked from network); 2 Apr 2009 13:53:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2009 13:53:07 -0000 Received: (qmail 87654 invoked by uid 500); 2 Apr 2009 13:53:06 -0000 Delivered-To: melissalambert@example.org Received: (qmail 87577 invoked by uid 500); 2 Apr 2009 13:53:06 -0000 Mailing-List: contact melissalambert@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:melissalambert@example.org> List-Unsubscribe: <mailto:melissalambert@example.org> List-Post: <mailto:melissalambert@example.org> List-Id: <uima-user.incubator.apache.org> Reply-To: melissalambert@example.org Delivered-To: mailing list melissalambert@example.org Received: (qmail 87567 invoked by uid 99); 2 Apr 2009 13:53:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 13:53:06 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of melissalambert@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail.gmx.net) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 02 Apr 2009 13:52:58 +0000 Received: (qmail invoked by alias); 02 Apr 2009 13:52:36 -0000 Received: from blueice4n1.de.ibm.com (EHLO [83.161.120.155]) [83.161.120.155] by mail.gmx.net (mp026) with SMTP; 02 Apr 2009 15:52:36 +0200 X-Authenticated: #25330878 X-Provags-ID: V01U2FsdGVkX19ULklOU5BUYgJYf+cA01UUv4CUFyLCVJVlxPuFhG SSxCB6Rq8HK72U Message-ID: <melissalambert@example.org> Date: Thu, 02 Apr 2009 15:52:36 +0200 From: Thilo Goetz <melissalambert@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090302) MIME-Version: 1.0 To: melissalambert@example.org Subject: Re: Problem accessing annotations in a window References: <melissalambert@example.org> <melissalambert@example.org> <melissalambert@example.org> In-Reply-To: <melissalambert@example.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 X-Virus-Checked: Checked by ClamAV on apache.org Peter Klügl wrote: > Hi Thilo, > > first of all, thanks for the detailed answer. > > I will try the approach with the increased end offset of the window, but > I fear that this won't change the results (but should result in some > speedup). I already added the additional code fragment in the methods in > order to get the correct start position irrespective of the type order: > > while (completeIt.isValid() > && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation > .getBegin()) { > completeIt.moveToPrevious(); > } > > if (completeIt.isValid()) { > completeIt.moveToNext(); > } else { > completeIt.moveToFirst(); > } > > This should ignore all different orders of types in the index. Beside > that, I also tried to use the same type in the window annotation and > even a new window with an explictly defined type priority resulting in a > (theoretically) correct starting position. But none of those methods > returns always the correct list of contained annotations. I must have > made a mistake somewhere... for example see the example with the debug > information I added to my last mail. How can it be possible that an > annotation is "disrespecting" the begin/end indexing strategy? Is it > possible that changing a feature value without > removeFromIndex/addToIndex can confuse the index in this way? I already > started to make a guess. Hi Peter, yes, if you change the begin/end position of an annotation without removeFromIndex/addToIndex, that will invalidate the whole index. The index has no way of knowing that certain feature values changed, and so can't do automatic reordering of the index. Indexes are kept sorted, so you can't modify members without telling the index about it. This is a speed/convenience trade-off, and we opted for speed at the time... --Thilo > > I would love such an ignoreTypeOrder flag. > > I will try some things now and get back to you with the results. > > > Peter > > > > Thilo Goetz schrieb: >> Hi Peter, >> >> I see one issue with your code: you're using the windowAnnotation >> to position the iterator. Instead, you should be using an >> annotation of the type you're searching for. This is because >> annotations are sorted by type as well. If you don't specify >> explicit type priorities, it doesn't mean that no type priority >> will be used. It just means that the type priority is arbitrary. >> I think our documentation is misleading in this respect, I was >> confused myself when I just read it. >> >> The net effect of this is that you can't reliably position an >> iterator where you're looking for annotations of type a with an >> annotation of type b. If you were just looking for annotations >> of a specific type, you could change your code like this: >> >> // Warning: untested >> windowAnnotation = getCas().createAnnotation(type, >> windowAnnotation.getBegin(), >> windowAnnotation.getEnd()); >> >> However, you also appear to be interested in annotations of subtypes >> of your input type. Those might be ordered differently again. >> >> So what to do? >> >> You can either use explicit type priorities (a PITA and not recommended), >> or you use an annotation for iterator positioning that's guaranteed to >> position the iterator in front of the first annotation you're interested >> in. For example, you could do this: >> >> AnnotationFS posFS = getCas().createAnnotation(type, >> windowAnnotation.getBegin(), windowAnnotation.getEnd() + 1); >> >> The type could be any annotation type, but note the increased end >> position. >> This will get your iterator positioned before, but not necessarily on >> the first desired annotation. You would then use your original >> windowAnnotation to check that the FSs you're iterating over are in >> range. >> >> This trick is necessary because you simply can't know how types are >> ordered in the absence of explicit type priorities. >> >> It seems to me like we should really have a built-in API that does >> this. Most people don't care or even know about type priorities, >> so the subiterator stuff is often useless. Or we could add yet >> another flag to the subiterator API, boolean ignoreTypeOrder. >> >> --Thilo >> >> >> Peter Klügl wrote: >> >>> Hello, >>> >>> I have a problem accessing annotations, especially annotations of a >>> given type in a window represented by another annotation. I am using >>> type priorities but not in this concrete situation. Therefore i am not >>> using the subiterator to access the contained annotations, but several >>> other methods like this one: >>> >>> public List<AnnotationFS> getAnnotationsInWindow( >>> AnnotationFS windowAnnotation, Type type) { >>> List<AnnotationFS> result = new ArrayList<AnnotationFS>(); >>> FSIterator completeIt = getCas().getAnnotationIndex().iterator(); >>> if (getDocumentAnnotation().getEnd() < windowAnnotation.getEnd()) { >>> completeIt.moveToLast(); >>> } else { >>> completeIt.moveTo(windowAnnotation); >>> } >>> while (completeIt.isValid() >>> && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation >>> .getBegin()) { >>> completeIt.moveToPrevious(); >>> } >>> >>> if (completeIt.isValid()) { >>> completeIt.moveToNext(); >>> } else { >>> completeIt.moveToFirst(); >>> } >>> >>> while (completeIt.isValid() >>> && ((Annotation) completeIt.get()).getBegin() < windowAnnotation >>> .getBegin()) { >>> completeIt.moveToNext(); >>> } >>> >>> while (completeIt.isValid() >>> && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation >>> .getBegin()) { >>> Annotation annotation = (Annotation) completeIt.get(); >>> if (getCas().getTypeSystem().subsumes(type, annotation.getType()) >>> && annotation.getEnd() <= windowAnnotation.getEnd()) { >>> result.add(annotation); >>> } >>> completeIt.moveToNext(); >>> } >>> return result; >>> } >>> >>> I tried already many variations of this (e.g., with the index of the >>> given type, using a new created frame with a higher type priority), but >>> this method returns sometimes simply wrong annotations or no annotations >>> at all. The only method that seems to work all the time is to iterate >>> over all annotations of the given type and then filter those that are >>> not contained in the window. >>> >>> My problem occurs in many different shapes. Here's one short example: >>> >>> Arguments: >>> >>> windowAnnotation: >>> Annotation >>> sofa: _InitialView >>> begin: 10899 >>> end: 10906 >>> Covered Text: {.8}Bar >>> >>> type: >>> de.uniwue.casetrain.Answers.answerText >>> >>> >>> Information in the eclipse debug view (Variables): >>> SubAnnotations: >>> [0] >>> WordAnswer >>> sofa: _InitialView >>> begin: 10899 >>> end: 10906 >>> SimpleFeedback: <null> >>> PosFactor: 0.8 >>> NegFactor: 0.0 >>> InstanceIsUserAnswer: false >>> Text: <null> >>> IsRegularExpression: false >>> EditDistance: 0 >>> [1] >>> WordAnswer >>> sofa: _InitialView >>> begin: 10886 >>> end: 10892 >>> SimpleFeedback: <null> >>> PosFactor: 1.0 >>> NegFactor: 0.0 >>> InstanceIsUserAnswer: false >>> Text: answerText >>> sofa: _InitialView >>> begin: 10889 >>> end: 10892 >>> IsRegularExpression: false >>> EditDistance: 0 >>> [2] >>> paragraph >>> sofa: _InitialView >>> begin: 10899 >>> end: 10906 >>> ... >>> [20] >>> answerText >>> sofa: _InitialView >>> begin: 10903 >>> end: 10906 >>> >>> ...and so on.... >>> >>> In this example the method above simply stops at the second annotations >>> since start offset is smaller than the one of the window. How can this >>> be? Is the position in the index depending on the values of the >>> features? Did I miss something here? In other examples the method above >>> just steps over the important annotations. Using the brute force >>> approach is not really a solution for me; it slows down my system by >>> more than 50%. >>> >>> I would really appreciate any hints to solve this problem since this >>> method/functionality is quite essential for my application. Of course, i >>> would also not reject any advice about performance. >>> >>> Best regards >>> >>> Peter >>> From uima-user-returnmelissalambert@example.org Thu Apr 02 15:22:42 2009 Return-Path: <uima-user-returnmelissalambert@example.org> Delivered-To: melissalambert@example.org Received: (qmail 13989 invoked from network); 2 Apr 2009 15:22:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2009 15:22:42 -0000 Received: (qmail 43358 invoked by uid 500); 2 Apr 2009 15:22:42 -0000 Delivered-To: melissalambert@example.org Received: (qmail 43329 invoked by uid 500); 2 Apr 2009 15:22:42 -0000 Mailing-List: contact melissalambert@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:melissalambert@example.org> List-Unsubscribe: <mailto:melissalambert@example.org> List-Post: <mailto:melissalambert@example.org> List-Id: <uima-user.incubator.apache.org> Reply-To: melissalambert@example.org Delivered-To: mailing list melissalambert@example.org Received: (qmail 43319 invoked by uid 99); 2 Apr 2009 15:22:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 15:22:42 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO mailrelay.rz.uni-wuerzburg.de) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 15:22:33 +0000 Received: from virusscan.mail (localhost [83.161.120.155]) by mailrelay.mail (Postfix) with ESMTP id D23FA199150 for <melissalambert@example.org>; Thu, 2 Apr 2009 17:22:12 +0200 (CEST) Received: from localhost (localhost [83.161.120.155]) by virusscan.mail (Postfix) with ESMTP id C3C1019914C for <melissalambert@example.org>; Thu, 2 Apr 2009 17:22:12 +0200 (CEST) Received: from [83.161.120.155] (win6093.informatik.uni-wuerzburg.de [83.161.120.155]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A2947199141 for <melissalambert@example.org>; Thu, 2 Apr 2009 17:22:12 +0200 (CEST) Message-ID: <melissalambert@example.org> Date: Thu, 02 Apr 2009 17:22:12 +0200 From: =?ISO-8859-15?Q?Peter_Kl=FCgl?= <melissalambert@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090302) MIME-Version: 1.0 To: melissalambert@example.org Subject: Re: Problem accessing annotations in a window References: <melissalambert@example.org> <melissalambert@example.org> <melissalambert@example.org> <melissalambert@example.org> In-Reply-To: <melissalambert@example.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by melissalambert@example.org X-Virus-Checked: Checked by ClamAV on apache.org Hi Thilo, > > Hi Peter, > > yes, if you change the begin/end position of an annotation without > removeFromIndex/addToIndex, that will invalidate the whole index. > The index has no way of knowing that certain feature values changed, > and so can't do automatic reordering of the index. Indexes are > kept sorted, so you can't modify members without telling the > index about it. This is a speed/convenience trade-off, and we > opted for speed at the time... > > --Thilo > > I think I located my problem. I often programmatically change the features, but was extremely sure not to touch the begin/end feature for the obvious indexing reasons you mentioned. After adding removeFromIndex/addToIndex everywhere the results of the methods look correct and it should be quite straight-forward to identify the real problem. Thank you for your help! Peter >> I would love such an ignoreTypeOrder flag. >> >> I will try some things now and get back to you with the results. >> >> >> Peter >> >> >> >> Thilo Goetz schrieb: >> >>> Hi Peter, >>> >>> I see one issue with your code: you're using the windowAnnotation >>> to position the iterator. Instead, you should be using an >>> annotation of the type you're searching for. This is because >>> annotations are sorted by type as well. If you don't specify >>> explicit type priorities, it doesn't mean that no type priority >>> will be used. It just means that the type priority is arbitrary. >>> I think our documentation is misleading in this respect, I was >>> confused myself when I just read it. >>> >>> The net effect of this is that you can't reliably position an >>> iterator where you're looking for annotations of type a with an >>> annotation of type b. If you were just looking for annotations >>> of a specific type, you could change your code like this: >>> >>> // Warning: untested >>> windowAnnotation = getCas().createAnnotation(type, >>> windowAnnotation.getBegin(), >>> windowAnnotation.getEnd()); >>> >>> However, you also appear to be interested in annotations of subtypes >>> of your input type. Those might be ordered differently again. >>> >>> So what to do? >>> >>> You can either use explicit type priorities (a PITA and not recommended), >>> or you use an annotation for iterator positioning that's guaranteed to >>> position the iterator in front of the first annotation you're interested >>> in. For example, you could do this: >>> >>> AnnotationFS posFS = getCas().createAnnotation(type, >>> windowAnnotation.getBegin(), windowAnnotation.getEnd() + 1); >>> >>> The type could be any annotation type, but note the increased end >>> position. >>> This will get your iterator positioned before, but not necessarily on >>> the first desired annotation. You would then use your original >>> windowAnnotation to check that the FSs you're iterating over are in >>> range. >>> >>> This trick is necessary because you simply can't know how types are >>> ordered in the absence of explicit type priorities. >>> >>> It seems to me like we should really have a built-in API that does >>> this. Most people don't care or even know about type priorities, >>> so the subiterator stuff is often useless. Or we could add yet >>> another flag to the subiterator API, boolean ignoreTypeOrder. >>> >>> --Thilo >>> >>> >>> Peter Klügl wrote: >>> >>> >>>> Hello, >>>> >>>> I have a problem accessing annotations, especially annotations of a >>>> given type in a window represented by another annotation. I am using >>>> type priorities but not in this concrete situation. Therefore i am not >>>> using the subiterator to access the contained annotations, but several >>>> other methods like this one: >>>> >>>> public List<AnnotationFS> getAnnotationsInWindow( >>>> AnnotationFS windowAnnotation, Type type) { >>>> List<AnnotationFS> result = new ArrayList<AnnotationFS>(); >>>> FSIterator completeIt = getCas().getAnnotationIndex().iterator(); >>>> if (getDocumentAnnotation().getEnd() < windowAnnotation.getEnd()) { >>>> completeIt.moveToLast(); >>>> } else { >>>> completeIt.moveTo(windowAnnotation); >>>> } >>>> while (completeIt.isValid() >>>> && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation >>>> .getBegin()) { >>>> completeIt.moveToPrevious(); >>>> } >>>> >>>> if (completeIt.isValid()) { >>>> completeIt.moveToNext(); >>>> } else { >>>> completeIt.moveToFirst(); >>>> } >>>> >>>> while (completeIt.isValid() >>>> && ((Annotation) completeIt.get()).getBegin() < windowAnnotation >>>> .getBegin()) { >>>> completeIt.moveToNext(); >>>> } >>>> >>>> while (completeIt.isValid() >>>> && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation >>>> .getBegin()) { >>>> Annotation annotation = (Annotation) completeIt.get(); >>>> if (getCas().getTypeSystem().subsumes(type, annotation.getType()) >>>> && annotation.getEnd() <= windowAnnotation.getEnd()) { >>>> result.add(annotation); >>>> } >>>> completeIt.moveToNext(); >>>> } >>>> return result; >>>> } >>>> >>>> I tried already many variations of this (e.g., with the index of the >>>> given type, using a new created frame with a higher type priority), but >>>> this method returns sometimes simply wrong annotations or no annotations >>>> at all. The only method that seems to work all the time is to iterate >>>> over all annotations of the given type and then filter those that are >>>> not contained in the window. >>>> >>>> My problem occurs in many different shapes. Here's one short example: >>>> >>>> Arguments: >>>> >>>> windowAnnotation: >>>> Annotation >>>> sofa: _InitialView >>>> begin: 10899 >>>> end: 10906 >>>> Covered Text: {.8}Bar >>>> >>>> type: >>>> de.uniwue.casetrain.Answers.answerText >>>> >>>> >>>> Information in the eclipse debug view (Variables): >>>> SubAnnotations: >>>> [0] >>>> WordAnswer >>>> sofa: _InitialView >>>> begin: 10899 >>>> end: 10906 >>>> SimpleFeedback: <null> >>>> PosFactor: 0.8 >>>> NegFactor: 0.0 >>>> InstanceIsUserAnswer: false >>>> Text: <null> >>>> IsRegularExpression: false >>>> EditDistance: 0 >>>> [1] >>>> WordAnswer >>>> sofa: _InitialView >>>> begin: 10886 >>>> end: 10892 >>>> SimpleFeedback: <null> >>>> PosFactor: 1.0 >>>> NegFactor: 0.0 >>>> InstanceIsUserAnswer: false >>>> Text: answerText >>>> sofa: _InitialView >>>> begin: 10889 >>>> end: 10892 >>>> IsRegularExpression: false >>>> EditDistance: 0 >>>> [2] >>>> paragraph >>>> sofa: _InitialView >>>> begin: 10899 >>>> end: 10906 >>>> ... >>>> [20] >>>> answerText >>>> sofa: _InitialView >>>> begin: 10903 >>>> end: 10906 >>>> >>>> ...and so on.... >>>> >>>> In this example the method above simply stops at the second annotations >>>> since start offset is smaller than the one of the window. How can this >>>> be? Is the position in the index depending on the values of the >>>> features? Did I miss something here? In other examples the method above >>>> just steps over the important annotations. Using the brute force >>>> approach is not really a solution for me; it slows down my system by >>>> more than 50%. >>>> >>>> I would really appreciate any hints to solve this problem since this >>>> method/functionality is quite essential for my application. Of course, i >>>> would also not reject any advice about performance. >>>> >>>> Best regards >>>> >>>> Peter >>>> >>>> From uima-user-returnmelissalambert@example.org Thu Apr 02 19:52:02 2009 Return-Path: <uima-user-returnmelissalambert@example.org> Delivered-To: melissalambert@example.org Received: (qmail 31007 invoked from network); 2 Apr 2009 19:52:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2009 19:52:02 -0000 Received: (qmail 97053 invoked by uid 500); 2 Apr 2009 19:52:01 -0000 Delivered-To: melissalambert@example.org Received: (qmail 96994 invoked by uid 500); 2 Apr 2009 19:52:01 -0000 Mailing-List: contact melissalambert@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:melissalambert@example.org> List-Unsubscribe: <mailto:melissalambert@example.org> List-Post: <mailto:melissalambert@example.org> List-Id: <uima-user.incubator.apache.org> Reply-To: melissalambert@example.org Delivered-To: mailing list melissalambert@example.org Received: (qmail 96984 invoked by uid 99); 2 Apr 2009 19:52:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 19:52:01 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of melissalambert@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO gateway08.websitewelcome.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 02 Apr 2009 19:51:51 +0000 Received: (qmail 30781 invoked from network); 2 Apr 2009 19:47:05 -0000 Received: from gator74.hostgator.com (83.161.120.155) by gateway08.websitewelcome.com with SMTP; 2 Apr 2009 19:47:05 -0000 Received: from [83.161.120.155] (port=40672 helo=[83.161.120.155]) by gator74.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <melissalambert@example.org>) id 1LpSrC-0004rF-3m for melissalambert@example.org; Thu, 02 Apr 2009 14:45:46 -0500 Message-ID: <melissalambert@example.org> Date: Thu, 02 Apr 2009 15:45:47 -0400 From: Marshall Schor <melissalambert@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090302) MIME-Version: 1.0 To: melissalambert@example.org Subject: Re: UIMA AS as OSGI bundle References: <melissalambert@example.org> <melissalambert@example.org> In-Reply-To: <melissalambert@example.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator74.hostgator.com X-AntiAbuse: Original Domain - incubator.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - schor.com X-Virus-Checked: Checked by ClamAV on apache.org Jörn Kottmann wrote: > > On Mar 31, 2009, at 9:47 PM, Jaroslaw Cwiklik wrote: > >> Jörn, not sure how I feel about this yet. What you are proposing is >> to add a >> list of dependent jars into the >> manifest.mf files found in the Uima AS jars. There may be a problem with >> this. ActiveMQ jars, for example, >> are named differently in each release.Some users (perhaps) may want to >> switch between say AMQ 5.2.2 and 4.1.1 and with a hard >> dependency in the manifest there may be a runtime problem. How do you >> resolve such a problem? > > In the OSGI manifest the Import-Package (or Required-Bundle) defines > on what the bundle > depends, dependencies are then resolved by the OSGI runtime. > In our case it should be fine to define a dependency on > activemq 4.1.1 or higher, right ? In an ideal world, that would be true :-) . In earlier testing, we had discovered that higher level components sometimes did and sometimes did not play nicely with other levels (when talking to each other over the network, for instance). -Marshall > > Jörn > From uima-user-returnmelissalambert@example.org Thu Apr 02 19:53:09 2009 Return-Path: <uima-user-returnmelissalambert@example.org> Delivered-To: melissalambert@example.org Received: (qmail 31400 invoked from network); 2 Apr 2009 19:53:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 Apr 2009 19:53:09 -0000 Received: (qmail 2874 invoked by uid 500); 2 Apr 2009 19:53:09 -0000 Delivered-To: melissalambert@example.org Received: (qmail 2830 invoked by uid 500); 2 Apr 2009 19:53:09 -0000 Mailing-List: contact melissalambert@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:melissalambert@example.org> List-Unsubscribe: <mailto:melissalambert@example.org> List-Post: <mailto:melissalambert@example.org> List-Id: <uima-user.incubator.apache.org> Reply-To: melissalambert@example.org Delivered-To: mailing list melissalambert@example.org Received: (qmail 2820 invoked by uid 99); 2 Apr 2009 19:53:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Apr 2009 19:53:09 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of melissalambert@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO gateway05.websitewelcome.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 02 Apr 2009 19:52:59 +0000 Received: (qmail 5920 invoked from network); 2 Apr 2009 19:53:24 -0000 Received: from gator74.hostgator.com (83.161.120.155) by gateway05.websitewelcome.com with SMTP; 2 Apr 2009 19:53:24 -0000 Received: from [83.161.120.155] (port=52744 helo=[83.161.120.155]) by gator74.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <melissalambert@example.org>) id 1LpSxo-0006mk-56 for melissalambert@example.org; Thu, 02 Apr 2009 14:52:36 -0500 Message-ID: <melissalambert@example.org> Date: Thu, 02 Apr 2009 15:52:36 -0400 From: Marshall Schor <melissalambert@example.org> User-Agent: Thunderbird 83.161.120.155 (Windows/20090302) MIME-Version: 1.0 To: melissalambert@example.org Subject: Re: UIMA AS as OSGI bundle References: <melissalambert@example.org> <melissalambert@example.org> In-Reply-To: <melissalambert@example.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include
{'source': 'Apache Software Foundation Public Mail Archives'}