On 16.07.2015, at 18:52, Petr Baudis <pa...@ucw.cz> wrote: > On Fri, Jul 10, 2015 at 01:37:27PM -0400, Marshall Schor wrote: >>> >>> * UIMAfit is not part of core UIMA and UIMA-AS is not part of core >>> UIMA. It seems to me that UIMA-AS is doing things a bit differently >>> than what the original UIMA idea of doing scaleout was. The two >>> things don't play well together. I'd love a way to easily take >>> my plain UIMA pipeline and scale it out, ideally without any code >>> changes, *and* avoid the terrible XML config files. >> Any specifics of what to change here would be helpful. UIMA-AS was designed >> to >> enable scale-out without changing the core UIMA pipeline or it's XML >> descriptor. THe additional information for UIMA-AS scaleout was put into a >> separate xml descriptor which "embeds" the original plain UIMA one. > > I'm sure Richard would be able to explain this better, but I think one > of the core issues is that UIMA-AS embeds the XML descriptor instead of > the AnalysisEngineDescription. So when I want to use it together with > AnalysisEngineDescription built with UIMAfit instead, it's time to > start making crazy workarounds like
Afaik, there is no API in UIMA-AS that allows inject an AnalysisEngineDescription into an UIMA-AS descriptor. UIMA-AS forces one to use an import, so the AED needs to be serialized and then imported again by UIMA-AS... or I just never found the right method call or missed when it was added. In fact, I didn't even find an API to programmatically create a UIMA-AS descriptor and at the time saw myself forced to implement a "AsDeploymentDescription.java" myself. See: https://code.google.com/p/dkpro-lab/source/browse/de.tudarmstadt.ukp.dkpro.lab/de.tudarmstadt.ukp.dkpro.lab.uima.engine.uimaas/src/main/java/de/tudarmstadt/ukp/dkpro/lab/uima/engine/uimaas/ >>> * Connected with the above - I'd love .addToIndexes() to just >>> disappear. Right now, the paradigm is that you build an annotation >>> in an annotator, and the moment it gets saved in a CAS, it becomes >>> basically read-only. >> You certainly can modify any of an Annotation's features subsequently. >> I'm guessing you're referring to another idea - adding additional features >> that were >> not initially defined in the UIMA type system. > > Sorry for the confusion, but that's not quite what I had in mind. > I literally believe that right now, in order to modify value of > a feature, you need to first remove it from an index, change the > value, then re-add it back. Is that a misconception? Well, yes and no. Yes, it was required for the case where the value that you changed was on a feature that was part of some index. No, it should no longer be required as measures have been implemented to handle this automatically. See: "The curious case of the zombie annotation" aka UIMA-4049 https://issues.apache.org/jira/browse/UIMA-4049 > I think that's a bug for the UIMA Tutorial, which mentions FSArray but > not FSList. :-) Then I should tell you also about the uimaFIT FSCollectionFactory which contains all kinds of helpers to manage FSArray and FSList ;) Btw. there is also ArrayFS which is the CAS version of FSArray :P > (Another pain point here - I always ache when I need to work with > FSArray or I guess FSList, since it does not carry the type information > that is in the typesystem - I need to manually typecast all the time > and hope I don't make a mistake.) Did you know that uimaFIT JCasUtil.select() can also be applied to FSList and FSArray to avoid casting? for (Token t : JCasUtil.select(sentence.getTokens(), Token.class) { ... } CasUtil.select() can work also on ArrayFS Cheerio, -- Richard
