Return-Path: Delivered-To: apmail-incubator-uima-user-archive@minotaur.apache.org Received: (qmail 73383 invoked from network); 5 Jun 2009 05:44:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Jun 2009 05:44:43 -0000 Received: (qmail 31071 invoked by uid 500); 5 Jun 2009 05:44:54 -0000 Delivered-To: apmail-incubator-uima-user-archive@incubator.apache.org Received: (qmail 30980 invoked by uid 500); 5 Jun 2009 05:44:54 -0000 Mailing-List: contact uima-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: uima-user@incubator.apache.org Delivered-To: mailing list uima-user@incubator.apache.org Received: (qmail 30950 invoked by uid 99); 5 Jun 2009 05:44:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jun 2009 05:44:52 +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 steven.bethard@gmail.com designates 209.85.221.195 as permitted sender) Received: from [209.85.221.195] (HELO mail-qy0-f195.google.com) (209.85.221.195) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jun 2009 05:44:42 +0000 Received: by qyk33 with SMTP id 33so483946qyk.21 for ; Thu, 04 Jun 2009 22:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=w9FFhHxE7muICJlDFY0PwTmlIInGA5z8BN3HU4V1eDs=; b=U6+ZMvsADSaF5rsi9MEQ6LcEbqHitu1I8BB1t/u/jkpps8kgTGntDAft49O83Kx+yN 8vtVcLuItWrw1pABDlerh6M6M0JXdhejOFCkkP1RSwiYgrIduBD7bbVTar1+1OGpsxpA R/faVKZlW9ZmKIjS9t9FkHYVmT7xvyrno3kiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=WUYaF+j32URg9CobuyqKibBSyw5OgVUra0NMK26V/nmspAcbXSmicqY/zgoSyV3NH6 Ngcq/4n4RcsXF5z1qsrjSf6n6MpyC8FKJfOIlKeuzlW9xoFPnt8WiQ+omIIy49uPID/V diFsBqLIukNUHi194sN8ge2K6fg0k+hh6J5/8= MIME-Version: 1.0 Received: by 10.220.99.144 with SMTP id u16mr2051015vcn.119.1244180661586; Thu, 04 Jun 2009 22:44:21 -0700 (PDT) In-Reply-To: <4A27E0AE.80809@ucdenver.edu> References: <4A2792C7.5000304@gmx.de> <4A27E0AE.80809@ucdenver.edu> Date: Thu, 4 Jun 2009 22:44:21 -0700 Message-ID: Subject: Re: Parameters in uima descriptors From: Steven Bethard To: uima-user@incubator.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Jun 4, 2009 at 7:56 AM, Chris Roeder wr= ote: > If you ship xml descriptors, then someone who creates CPEs with the gui > and runs them with SimpleRunCPE can use them easily. =C2=A0If you don't, > your components are still usable, though with a bit more work. Either > the user writes XML descriptors for them and proceeds =C2=A0with the =C2= =A0CPE editor > and SimpleRunCPE, or they modify SimpleRunCPE or similar code (as I > understand you to have done ) to create the components in java without > getting the meta data from xml. Yep, I think this is a fair description. So I can certainly agree that not providing XML descriptors would make it harder to use SimpleRunCPE (and CPE descriptors in general). I'm uncertain as to how much of a loss this is. In our case at least, getting away from the CPE gui has been a blessing, not a curse. ;-) On Thu, Jun 4, 2009 at 8:26 AM, Thilo Goetz wrote: > The most common way to reuse someone elses component is to embed > said component in your own UIMA processing pipeline. This is done > by referencing the component's XML descriptor in your own aggregate > descriptor. No XML descriptor, no referencing, no reuse. That's > what I mean by "unusable". Does that make sense? You mean "not usable in an XML descriptor". Yep, that's true. However, the code is still usable in a Java descriptor. See for example the various createAggregateAnalysisEngine() methods in org.uutuc.factory.AnalysisEngineFactory: http://code.google.com/p/uutuc/source/browse/trunk/uutuc/src/main/java/org/= uutuc/factory/AnalysisEngineFactory.java Note that if you use something like the above, you can happily aggregate both Java and XML descriptors. But yes, you do have to commit to writing your main methods in Java instead of relying on something like SimpleRunCPE or the CPE gui. I do think that saying they're "unusable" is misleading though. If you want to say they're "unusable by XML descriptors" though, I'd be happy to agree to that. I'm just of the opinion that moving from XML descriptors to Java descriptors is a good idea, particularly for code which undergoes relatively frequent refactoring. Steve --=20 Where did you get the preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus