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 : > On 09.09.2016, at 17:37, Asher Stern 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
On 09.09.2016, at 17:37, Asher Stern 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
And I guess you don't get JCAS classes for your type system without going
through JCasGen, which is another disadvantage to generating the types on
the fly. It also kind of goes against the fact that the type system should
be something you can rely on for communication between components, so it
would tend to be static.
Just out of curiosity, what's the use case for this (except maybe unit
testing as Armin mentioned)?
Best,
Jens
On Fri, Sep 9, 2016 at 4:31 PM, Richard Eckart de Castilho
wrote:
> On 09.09.2016, at 13:39, Asher Stern 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 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 :
> On 09.09.2016, at 13:39, Asher Stern 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
On 09.09.2016, at 13:39, Asher Stern 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 :
> 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
>
AW: General question about UimaFIT
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
pgpBfjvrekVRh.pgp
Description: PGP signature
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
