Re: External resource shared among AEs
Hi Richard. Thanks very much! Asher 2017-01-04 20:59 GMT+02:00 Richard Eckart de Castilho <r...@apache.org>: > Hi Asher, > > > On 04.01.2017, at 15:35, Asher Stern <aste...@gmail.com> wrote: > > > > Hi. > > Using UIMAFit, is it possible to create a single instance of an > > external-resource, and use it in several AEs, that are not connected to > > each other? > > In order to share external resources between unrelated AEs, these AEs > would need to share the same ResourceManager instance. ResourceManagers > are usually created implicitly by UIMA or uimaFIT e.g. in > AnalysisEngineFactory.createEngine(). > > If you have a look at the code of AnalysisEngineFactory.createEngine(desc, > conf...) [1] > (in uimaFIT 2.2.0 around line 202) you can see a few lines of code > illustrating > how to create your own ResourceManager and how to make use of it when > instantiating > your analysis engine or pipeline from an analysis engine description. > > So basically you use uimaFIT to create your analysis engine descriptors, > then you use UIMA to create your shared resource manager and to instantiate > your engines. > > Cheers, > > -- Richard > > [1] https://svn.apache.org/repos/asf/uima/uimafit/trunk/ > uimafit-core/src/main/java/org/apache/uima/fit/factory/ > AnalysisEngineFactory.java > >
External resource shared among AEs
Hi. Using UIMAFit, is it possible to create a single instance of an external-resource, and use it in several AEs, that are not connected to each other? They are *not* combined in an aggregate AE. They are totally independent. Each AE runs in a different thread, and processes different document. But they both need the same resource. What I've realized is that every call to AnalysisEngineFactory.createEngine(), with the analysis engine description creates new instances of the external resources, even though the resources descriptions is shared among the AEs when created by AnalysisEngineFactory.createEngineDescription(). Thanks in advance, Asher
Dynamically configure Sofa to be processed
Hi all. I wanted to ask a question. Using UimaFit, how to tell an analysis engine, which is unaware of Sofas, to process a specific Sofa, without changing its code, after that engine has been created? I mean: I have an analysis engine that operates over the CAS. It uses JCas#getDocumentText() to take the data. It is unaware of Sofas. I want that engine to process a specific Sofa (a specific view). I know that when the engine is being created (using AnalysisEngineFactory#createEngine) I can provide a parameter with the default view, which makes the engine process that view (instead of _InitialView). However, I want *the same engine* to process several Sofas (separately), and I don't want to create an instance of the engine again and again for each Sofa. I need some way to tell the engine that in the next call to process() it shall process a specific Sofa. When I just call process() with either the CAS or a specific view as parameter, it processes the default view (_InitialView). Question is, how to guide it to process another view. Many thanks in advance, Asher
Re: General question about UimaFIT
Hi. Thanks for your answers. So it seems that programming-language independence is the primal reason to do things as they have done. Many thanks, Asher. 2016-09-09 18:49 GMT+03:00 Richard Eckart de Castilho <r...@apache.org>: > On 09.09.2016, at 17:37, Asher Stern <aste...@gmail.com> wrote: > > > > You explanation really makes things clear, and also answers my question. > > > > I still wonder whether some automatic mechanism can be developed to > > automatically generate TypeDescription and TypeSystemDescription directly > > from a Java class (under some conditions). > > This can shorten the learning curve of UIMA and remove the need for > > automatically-generated code, as well as tracking XML files in the > > classpath. (Such benefits are actually part of the primary goals of > > UimaFIT. Isn't it?) > > Though, such a development, even if possible, would not be trivial. > > The way that UIMA works, the JCas files are not meant to be a canonical > source of metadata information. The typesystem is an independent schema > and the JCas classes are a convenience. They can be used, but they do > not have to be used. In some cases, it is more reasonable to use > the CAS API instead of the JCas API and to operate entirely without > the JCas classes. E.g. an annotation editor where you can flexibibly > define types (such as WebAnno) would rely on the CAS API where > annotations are accessed by name instead of on the JCas API where > compiled Java classes are required. > > So JCas is optional, but type descriptors are not. > > With components, it is different. The descriptor is meaningless without > the implementing component. > > If somebody thought it would be worth the effort to generate type > descriptors > from annotated Java classes, it wouldn't be just annotating fields or > methods. > Some code generation would probably be involved, maybe comparable to how > Lombok > works. That approach has its own drawbacks starting from requiring a > compiler > plugin and going until e.g. Eclipse being unable to search for references > of > auto-generated methods. > > I'll not spend my time atm to follow that idea, but maybe you want to try > it? ;) > > Btw. there is ongoing work on a reimplementation of the CAS (and JCas) > towards > a UIMA v3 in the future. If you consider diving into this, you may want to > read a bit in the recent archives of the developer mailing list first. > > Cheers, > > -- Richard
Re: General question about UimaFIT
Hi Richard.
Many thanks!
You explanation really makes things clear, and also answers my question.
I still wonder whether some automatic mechanism can be developed to
automatically generate TypeDescription and TypeSystemDescription directly
from a Java class (under some conditions).
This can shorten the learning curve of UIMA and remove the need for
automatically-generated code, as well as tracking XML files in the
classpath. (Such benefits are actually part of the primary goals of
UimaFIT. Isn't it?)
Though, such a development, even if possible, would not be trivial.
2016-09-09 17:31 GMT+03:00 Richard Eckart de Castilho <r...@apache.org>:
> On 09.09.2016, at 13:39, Asher Stern <aste...@gmail.com> wrote:
> >
> > Hi Armin.
> > Thanks for your quick answer!
> >
> > While the workaround is indeed helpful, I am still curios why is there no
> > regular mechanism to define new types and create new descriptors
> > programmatically, much like all other UIMA components?
>
> Sure you can define types programmatically... it's just that for the
> case of types, defining them through XML is actually more convenient.
> Mind that the type-system is implementation independent! You can think
> of it as of an DTD or XSD.
>
> If you want to programmatically create a type, you can do this:
>
> TypeSystemDescription tsd = new TypeSystemDescription_impl();
> TypeDescription tokenTypeDesc = tsd.addType("Token", "",
> CAS.TYPE_NAME_ANNOTATION);
> tokenTypeDesc.addFeature("length", "", CAS.TYPE_NAME_INTEGER);
>
> CAS cas = CasCreationUtils.createCas(tsd, null, null);
> cas.setDocumentText("This is a test.");
>
> Check out [1] slides 20 following.
>
> Cheers,
>
> -- Richard
>
> [1] https://github.com/dkpro/dkpro-tutorials/blob/master/
> GSCL2013/tags/latest/slides/GSCL2013UIMATutorialUKP.pdf
Re: General question about UimaFIT
Hi Armin.
Thanks for your quick answer!
While the workaround is indeed helpful, I am still curios why is there no
regular mechanism to define new types and create new descriptors
programmatically, much like all other UIMA components?
I mean, what is the difference between type-system and all other UIMA
components, that forced the UimaFIT engineers to leave the XML-based
definitions for types, while getting rid of XMLs for all the rest of UIMA?
2016-09-09 13:59 GMT+03:00 <armin.weg...@bka.bund.de>:
> Hi Asher!
>
> As a work around, you can use an empty type system,
>
> TypeSystemDescription tsd = TypeSystemDescriptionFactory.
> createTypeSystemDescription("EmptyTypeSystem");
>
> add types programmatically,
>
> tsd.addType(typeName, null, CAS.TYPE_NAME_ANNOTATION);
>
> and get them later with
>
> Type type = cas.getTypeSystem().getType(typeName);
>
> The empty type system is an XML descriptor file without types residing
> somewhere in the class path. I use this for unit testing when I need a
> fresh type system.
>
> Cheers,
> Armin
>
>
> -Ursprüngliche Nachricht-
> Von: Asher Stern [mailto:aste...@gmail.com]
> Gesendet: Freitag, 9. September 2016 12:17
> An: user@uima.apache.org
> Betreff: General question about UimaFIT
>
> Hi.
> I have a general question regarding UimaFIT.
> In UimaFIT there is no longer need to write and deal with XML files, thanks
> to new classes and annotations.
>
> This is the case for almost all UIMA components, like AE, AAE, CPE, etc.
> However, for type-system definition, XML files are still required.
> My question is why?
> Is there a technical issue that makes it impossible to get rid of
> type-system XMLs? Or is it intentional due to some policy?
>
>
> Thanks in advance,
> Asher
>
General question about UimaFIT
Hi. I have a general question regarding UimaFIT. In UimaFIT there is no longer need to write and deal with XML files, thanks to new classes and annotations. This is the case for almost all UIMA components, like AE, AAE, CPE, etc. However, for type-system definition, XML files are still required. My question is why? Is there a technical issue that makes it impossible to get rid of type-system XMLs? Or is it intentional due to some policy? Thanks in advance, Asher
Re: Read CAS in node.js
Yes, I agree. What I actually need is a CAS deserialization library in node.js. 2016-08-29 11:58 GMT+03:00 Richard Eckart de Castilho <r...@apache.org>: > Well, then the question is in which format you have your CAS... > > Some time back, a basic JSON serialization module was added to UIMA. > That might help you sending a CAS from Java to node.js. However, > the JSON deserialization on the Java side is still missing. > > Cheers, > > -- Richard > > > On 29.08.2016, at 10:54, Asher Stern <aste...@gmail.com> wrote: > > > > Hi Richard. > > Thanks very much! > > However, we strongly prefer a solution which does not require this > > interoperability of calling Java from node.js. So if such a solution is > > available, it can be very helpful. > > > > Thanks a lot. > > Asher > > > > 2016-08-29 11:45 GMT+03:00 Richard Eckart de Castilho <r...@apache.org>: > > > >> Hi Asher, > >> > >> if you can call Java code from node.js, then check out the CasIOUtil > >> class in uimaFIT or wait a couple of days and then check out the > >> brand new CasIOUtils class in UIMAJ-SDK. > >> > >> Cheers, > >> > >> -- Richard > >> > >>> On 28.08.2016, at 11:11, Asher Stern <aste...@gmail.com> wrote: > >>> > >>> Hi. > >>> I have a question. > >>> > >>> Are there any good methods to read CAS from within node.js? > >>> > >>> Thanks in advance, > >>> Asher > >
Re: Read CAS in node.js
Hi Richard. Thanks very much! However, we strongly prefer a solution which does not require this interoperability of calling Java from node.js. So if such a solution is available, it can be very helpful. Thanks a lot. Asher 2016-08-29 11:45 GMT+03:00 Richard Eckart de Castilho <r...@apache.org>: > Hi Asher, > > if you can call Java code from node.js, then check out the CasIOUtil > class in uimaFIT or wait a couple of days and then check out the > brand new CasIOUtils class in UIMAJ-SDK. > > Cheers, > > -- Richard > > > On 28.08.2016, at 11:11, Asher Stern <aste...@gmail.com> wrote: > > > > Hi. > > I have a question. > > > > Are there any good methods to read CAS from within node.js? > > > > Thanks in advance, > > Asher > >
Read CAS in node.js
Hi. I have a question. Are there any good methods to read CAS from within node.js? Thanks in advance, Asher
Re: Eclipse Neon and version 2.8.2
Thanks 2016-08-03 9:35 GMT+03:00 Peter Klügl <peter.klu...@averbis.com>: > Hi, > > > we are currently solving some other issues for the release. After that, > the release process will be started, but I cannot tell you when the new > version will be released as it also depends on the available time for > reviewing the release candidate. > > > Due to some new features, the next version will be 2.9.0 > > > Best, > > > Peter > > > Am 02.08.2016 um 12:26 schrieb Asher Stern: > > I just wanted to ask when will the Eclipse update site switch to version > > 2.8.2. > > > > I understand that Eclipse Neon is supported only in version 2.8.2, but > that > > version has not yet been released so far. > > > > Thanks. > > > >
Eclipse Neon and version 2.8.2
I just wanted to ask when will the Eclipse update site switch to version 2.8.2. I understand that Eclipse Neon is supported only in version 2.8.2, but that version has not yet been released so far. Thanks.
