You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de> on 2011/10/06 17:47:21 UTC
Re: UIMA and uimaFIT
Am 15.09.2011 um 16:48 schrieb Jörn Kottmann:
> On 9/15/11 2:33 PM, Richard Eckart de Castilho wrote:
>> Maybe there would be a way to discuss migrating the injection feature or even more from uimaFIT to UIMA. That would need to be discussed with the other uimaFIT creators of course. What do you think about that?
>
> I think that would be great, the injection feature will be more useful and be available to more people by default.
As a short update: there is a generally positive tenor towards this amongst the uimaFIT developers. I'll draft up an action plan, discuss that with my the others and afterwards present it here.
Be patient with me though ;)
Best,
Richard
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckartde@tk.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: UIMA and uimaFIT
Posted by Jörn Kottmann <ko...@gmail.com>.
On 10/19/11 2:51 PM, Marshall Schor wrote:
>> In my use cases I always create an AAE which contains a couple of AEs. Is it
>> > possible
>> > to import the AE descriptor from a jar and then override the parameter
>> > settings in
>> > the AAE?
> Yes. The Configuration Descriptor Editor makes this a point-and-click operation
> (no need to remember how to spell parameter names, etc.)
Is this a practice we like AE implementers to do?
Would you suggest that I do that for the OpenNLP UIMA Integration?
Jörn
Re: UIMA and uimaFIT
Posted by Marshall Schor <ms...@schor.com>.
On 10/19/2011 4:56 AM, Jörn Kottmann wrote:
> On 10/19/11 4:52 AM, Marshall Schor wrote:
>> Our annotators in our "addons" often package a "typical use" xml descriptor in
>> the Jar file - so this is doable (except it doesn't address making the
>> configuration parameters a separate "thing"). I think Adam/Eddie have proposed
>> some thoughts on having some kind of separate "settings" file for complex sets
>> of annotators that can collect things together in one place, maybe as a
>> properties file - see:http://uima.markmail.org/thread/r2vrblnzkq4hdqnu )
>
> An assembler might just want to read some documentation which explains the
> existing
> configuration parameters. If that is the point we can make a small tool which
> turns
> our configuration parameters in some kind of *readable* format (e.g. html).
>
> This solution would solve the two issues, that the descriptor gets out of sync
> and
> that it must be duplicated all the time.
>
> In my use cases I always create an AAE which contains a couple of AEs. Is it
> possible
> to import the AE descriptor from a jar and then override the parameter
> settings in
> the AAE?
Yes. The Configuration Descriptor Editor makes this a point-and-click operation
(no need to remember how to spell parameter names, etc.)
-Marshall
>
> Jörn
>
Re: UIMA and uimaFIT
Posted by Jörn Kottmann <ko...@gmail.com>.
On 10/19/11 4:52 AM, Marshall Schor wrote:
> Our annotators in our "addons" often package a "typical use" xml descriptor in
> the Jar file - so this is doable (except it doesn't address making the
> configuration parameters a separate "thing"). I think Adam/Eddie have proposed
> some thoughts on having some kind of separate "settings" file for complex sets
> of annotators that can collect things together in one place, maybe as a
> properties file - see:http://uima.markmail.org/thread/r2vrblnzkq4hdqnu )
An assembler might just want to read some documentation which explains
the existing
configuration parameters. If that is the point we can make a small tool
which turns
our configuration parameters in some kind of *readable* format (e.g. html).
This solution would solve the two issues, that the descriptor gets out
of sync and
that it must be duplicated all the time.
In my use cases I always create an AAE which contains a couple of AEs.
Is it possible
to import the AE descriptor from a jar and then override the parameter
settings in
the AAE?
Jörn
Re: UIMA and uimaFIT
Posted by Marshall Schor <ms...@schor.com>.
On 10/18/2011 5:35 PM, Jörn Kottmann wrote:
> On 10/18/11 10:41 PM, Marshall Schor wrote:
>> I'm thinking (outloud) here of another kind of approach. Suppose we keep the
>> idea that the main "place" for parameter definitions / settings, is in the XML.
>> Perhaps we could use injection ideas + Java annotations to simplify the Java
>> code.
>>
>> Here's how it might work. You would define the parameters, etc., externally in
>> the XML, as is now done. But in the Java code, you would write something like
>> // this form if the name of the external parm differs from the variable name
>> @uimaParameter(ExternalParmName1)
>> String myStringParm;
>>
>> // this form if the name of the external parm is the same as the variable
>> name
>> @uimaParameter
>> int myIntParam;
>
> One of the things with the current approach which always annoys me is that I
> have to specify the "configurationParameters" element over and over again,
> and that it can easily get out of sync with the current implementation.
>
> I always thought that we should cut it out, and put it in another xml descriptor
> which is included in the jar file.
Our annotators in our "addons" often package a "typical use" xml descriptor in
the Jar file - so this is doable (except it doesn't address making the
configuration parameters a separate "thing"). I think Adam/Eddie have proposed
some thoughts on having some kind of separate "settings" file for complex sets
of annotators that can collect things together in one place, maybe as a
properties file - see: http://uima.markmail.org/thread/r2vrblnzkq4hdqnu )
-Marshall
>
> But today it might be better to use annotations to define these configuration
> parameters, when they are strongly attached to the implementation.
>
> When I can rely on the framework to check for my configuration parameters
> settings (e.g. throw an
> exception when one is not provided by a user) then I don't need to do this
> error checking
> twice (which e.g. OpenNLP does) and therefore I have to write less code to do
> the same.
>
> Additionally using annotations to inject parameters into instance variables
> makes things
> even easier and nicer to use.
>
> Jörn
>
Re: UIMA and uimaFIT
Posted by Jörn Kottmann <ko...@gmail.com>.
On 10/18/11 10:41 PM, Marshall Schor wrote:
> I'm thinking (outloud) here of another kind of approach. Suppose we keep the
> idea that the main "place" for parameter definitions / settings, is in the XML.
> Perhaps we could use injection ideas + Java annotations to simplify the Java code.
>
> Here's how it might work. You would define the parameters, etc., externally in
> the XML, as is now done. But in the Java code, you would write something like
> // this form if the name of the external parm differs from the variable name
> @uimaParameter(ExternalParmName1)
> String myStringParm;
>
> // this form if the name of the external parm is the same as the variable name
> @uimaParameter
> int myIntParam;
One of the things with the current approach which always annoys me is that I
have to specify the "configurationParameters" element over and over again,
and that it can easily get out of sync with the current implementation.
I always thought that we should cut it out, and put it in another xml
descriptor
which is included in the jar file.
But today it might be better to use annotations to define these
configuration
parameters, when they are strongly attached to the implementation.
When I can rely on the framework to check for my configuration
parameters settings (e.g. throw an
exception when one is not provided by a user) then I don't need to do
this error checking
twice (which e.g. OpenNLP does) and therefore I have to write less code
to do the same.
Additionally using annotations to inject parameters into instance
variables makes things
even easier and nicer to use.
Jörn
Re: UIMA and uimaFIT
Posted by Marshall Schor <ms...@schor.com>.
It's a simple point. Let's say you are not a programmer, but rather, an
"assembler" of annotators. Let's imagine that you can't read Java (assuming
annotators written in Java) or C++ (assuming annotators written in C++), but you
can read XML.
Then you can see by looking at the XML what the parameters are; while, if they
are kept inside the "code", only people who can read the code can see this.
The other reason for having externalized things in XML, is to enable tooling
that can be "driven" from this. For example, the Component Descriptor Editor
has various features that work from the XML specifications of configuration
parameters. It's quite simple to add a bunch of overrides by just clicking in
an aggregate - the CDE is using the XML to figure out the details.
Configuration parameters can also be quite complex, grouped into various "sets"
(I don't recall the details right now, but it's something like being able to
select different parameter settings in a group depending on things like the
document language --
see http://uima.apache.org/d/uimaj-2.3.1/references.html#ugr.ref.xml.component_descriptor.aes.configuration_parameter_declaration),
and the Component Descriptor Editor goes to some lengths to make this complexity
appropriately usable. There's an old Jira that says the configuration parameter
groups architecture in UIMA is too complex, (
https://issues.apache.org/jira/browse/UIMA-114 ) but I've occasionally heard
from users that are using them, so I don't think we're likely to drop support
for them (unless some much better design comes along to make it worthwhile
giving up backwards compatibility :-) ).
-Marshall
On 10/18/2011 5:55 PM, Jörn Kottmann wrote:
> On 10/18/11 10:41 PM, Marshall Schor wrote:
>> One thing that UIMA is "about" is the creating of compose-able components, and
>> supporting different skill sets / roles for users of the framework. Re: this
>> last point, we have a role called "assembler" in mind, someone who may not know
>> any details of programming languages (annotators might be developed in Java, or
>> C++, or ...), but can do some xml editing (perhaps with a form-based editor),
>> and put together and configure a pipeline of annotators, developed by others.
>>
>> This kind of use case leads to the posture where we have externalized
>> configuration parameters and settings, in XML, outside of the annotator
>> implementation.
>
> Maybe I missed the point, but is there any reason that the configuration
> parameters
> need to be externalized? I can see that people want to change settings, but
> for that
> the "configuration parameter settings" should be enough.
>
> Jörn
>
Re: UIMA and uimaFIT
Posted by Jörn Kottmann <ko...@gmail.com>.
On 10/18/11 10:41 PM, Marshall Schor wrote:
> One thing that UIMA is "about" is the creating of compose-able components, and
> supporting different skill sets / roles for users of the framework. Re: this
> last point, we have a role called "assembler" in mind, someone who may not know
> any details of programming languages (annotators might be developed in Java, or
> C++, or ...), but can do some xml editing (perhaps with a form-based editor),
> and put together and configure a pipeline of annotators, developed by others.
>
> This kind of use case leads to the posture where we have externalized
> configuration parameters and settings, in XML, outside of the annotator
> implementation.
Maybe I missed the point, but is there any reason that the configuration
parameters
need to be externalized? I can see that people want to change settings,
but for that
the "configuration parameter settings" should be enough.
Jörn
Re: UIMA and uimaFIT
Posted by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>.
> On Wed, Oct 19, 2011 at 2:06 AM, Richard Eckart de Castilho
> <ec...@tk.informatik.tu-darmstadt.de> wrote:
>> In Darmstadt we completely rely on descriptors generated at runtime form the annotations in the Java
>> files and find that very very convenient. I understand others will prefer static XML files to
>> runtime-generated descriptors.
>
> Another advantage for real descriptor files is scale out frameworks. I
> don't understand how uimaFit will work in UIMA-AS or other scale out
> frameworks.
uimaFIT is used in the context of UIMA-HPC [1] as a means to dynamically create component descriptions (including CPE descriptions) for UIMA pipelines that run within a Grid workflow architecture. Here, the scale-out happens outside of UIMA and supports other kinds of processing steps as well.
-- Richard
[1] http://www.uima-hpc.de/en/technical.html
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD)
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckart@ukp.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: UIMA and uimaFIT
Posted by Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de>.
Am 20.10.2011 um 01:08 schrieb Eddie Epstein:
> On Wed, Oct 19, 2011 at 2:06 AM, Richard Eckart de Castilho
> <ec...@tk.informatik.tu-darmstadt.de> wrote:
>> In Darmstadt we completely rely on descriptors generated at runtime form the annotations in the Java
>> files and find that very very convenient. I understand others will prefer static XML files to
>> runtime-generated descriptors.
>
> This is a common approach for users with complex systems with many
> configuration parameters. However, for systems with many annotators,
> and particularly deeply nested annotators, parameter overrides becomes
> more of a problem and working with temporary descriptors is another
> complication. This is why Adam has submitted a jira to allow a Java
> property file to override parameters anywhere in such a system. All
> the descriptors become more like code, they live in the classpath and
> are all imported by name, and any parameter values are easily changed
> via a single property file.
>
> Another advantage for real descriptor files is scale out frameworks. I
> don't understand how uimaFit will work in UIMA-AS or other scale out
> frameworks.
The context injection will work with UIMA-AS or any other scale out system
because is only an extra step that happens in the "initialize" phase of the
component life-cycle. Currently uimaFIT invokes the logic from the initialize()
method - if it was integrated into UIMA, then the core framework would call
the logic before invoking initialize().
Run-time generated descriptors will go nicely with UIMA-AS or other scale
out frameworks that require that a remote service permanently runs. It
will work nicely with scale-out systems that support on-demand deployment,
e.g. Hadoop. Instead of shipping a static descriptor with the Job-JAR,
the map/reduce code can generate a descriptor at runtime, create an AAE
from it and run it.
However, the "factories" of uimaFIT were initially not intended to support
scale out, but to allow for the simple creation of descriptors in unit tests.
Meanwhile we also intensively use it in our day-to-day resereach business because
we need highly flexible pipeline configurations (parameter-wise and flow-wise),
but we do not make much use of scale-out at the moment.
Again: uimaFIT context injection and uimaFIT factories are largely independent
from each other. You can use either one alone or both together - depending on
how it fits into your usage scenario.
Best,
Richard
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckartde@tk.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: UIMA and uimaFIT
Posted by Eddie Epstein <ea...@gmail.com>.
On Wed, Oct 19, 2011 at 2:06 AM, Richard Eckart de Castilho
<ec...@tk.informatik.tu-darmstadt.de> wrote:
> In Darmstadt we completely rely on descriptors generated at runtime form the annotations in the Java
> files and find that very very convenient. I understand others will prefer static XML files to
> runtime-generated descriptors.
This is a common approach for users with complex systems with many
configuration parameters. However, for systems with many annotators,
and particularly deeply nested annotators, parameter overrides becomes
more of a problem and working with temporary descriptors is another
complication. This is why Adam has submitted a jira to allow a Java
property file to override parameters anywhere in such a system. All
the descriptors become more like code, they live in the classpath and
are all imported by name, and any parameter values are easily changed
via a single property file.
Another advantage for real descriptor files is scale out frameworks. I
don't understand how uimaFit will work in UIMA-AS or other scale out
frameworks.
Eddie
Re: UIMA and uimaFIT
Posted by Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de>.
Hello everybody,
thanks for the feedback. I'll reply to Marshal's first mail.
> I'm thinking (outloud) here of another kind of approach. Suppose we keep the
> idea that the main "place" for parameter definitions / settings, is in the XML.
> Perhaps we could use injection ideas + Java annotations to simplify the Java code.
uimaFIT is about several things. The part I have described so far is only how
*context injection* works. I still have not fully described the part about the
factories, which is what the "description", "mandatory" and "defaultValue"
parameters of the @ConfigurationParameter annotation are for.
Maybe we could postpone that discussion until I have written up a spec and some
examples for that part.
> Here's how it might work. You would define the parameters, etc., externally in
> the XML, as is now done. But in the Java code, you would write something like
> // this form if the name of the external parm differs from the variable name
> @uimaParameter(ExternalParmName1)
> String myStringParm;
>
> // this form if the name of the external parm is the same as the variable name
> @uimaParameter
> int myIntParam;
>
> etc.
> And then we would have the normal UIMA initialize code path, before it called
> initialize, find the @uimaParameter items and set them from the XML parameter
> settings.
That's the context injection part and that is how it's currently done in uimaFIT
(with minor differences, e.g. names of annotations and default parameter names).
In the component base classes uimaFIT provides, the initialize() method is overwritten
to do the context injection part. Optimally, that would be done before by the UIMA core
framework before ever reaching the initialize() method, as you say.
Please mind that there are currently two aspects to the @ConfigurationParameter annotation:
- its a marker for context injection
- its a declaration for information from which an XML descriptor can be generated
I was expecting that this may lead to confusion and discussion here. For an integration into
the UIMA core, it may be a good idea to separate these concerns, e.g. into several annotations
(possibly JSR-250 compatible). This has not been done so far because it was considered that
a single @ConfigurationParameter annotation is "nicer" that a set of annotation:
> // For a mandatory parameter with the default name "myStringParam" and the default value "Hello"
> @Parameter @DefaultValue("Hello") @Required
> String myStringParam;
>
> // For an optional shared resource with the name "StopWords"
> @Resource(name="StopWords")
> StopWordList stopWordList;
Regarding XML vs. Annotations as the definitive specification: both approaches should be supported.
Take a look at Hibernate for example. Either Java <-> DB mapping can be provided in the form of XML
mapping files or in the form of annotations. Each has its benefits and draw-backs.
In Darmstadt we completely rely on descriptors generated at runtime form the annotations in the Java
files and find that very very convenient. I understand others will prefer static XML files to
runtime-generated descriptors.
I do not suggest to obsolete XML files as the definitive specification and in fact uimaFIT does not
prohibit that. It is perfectly possible to use XML files with context injection.
From the discussion, I gather that the form of the specification is ok. I'll continue to write up
something for the factories part next.
Best,
Richard
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckartde@tk.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: UIMA and uimaFIT
Posted by Marshall Schor <ms...@schor.com>.
Hi Richard,
Thanks for the writeup. I'm starting to think about this...
One thing that UIMA is "about" is the creating of compose-able components, and
supporting different skill sets / roles for users of the framework. Re: this
last point, we have a role called "assembler" in mind, someone who may not know
any details of programming languages (annotators might be developed in Java, or
C++, or ...), but can do some xml editing (perhaps with a form-based editor),
and put together and configure a pipeline of annotators, developed by others.
This kind of use case leads to the posture where we have externalized
configuration parameters and settings, in XML, outside of the annotator
implementation.
I agree with the general observation that it's nice to writing things down once
(don't repeat yourself), and our current approach for configuration parameters
does fall short I think, in this regard; you have to write them in XML and then
also write them in Java... (or C++ ...).
I'm thinking (outloud) here of another kind of approach. Suppose we keep the
idea that the main "place" for parameter definitions / settings, is in the XML.
Perhaps we could use injection ideas + Java annotations to simplify the Java code.
Here's how it might work. You would define the parameters, etc., externally in
the XML, as is now done. But in the Java code, you would write something like
// this form if the name of the external parm differs from the variable name
@uimaParameter(ExternalParmName1)
String myStringParm;
// this form if the name of the external parm is the same as the variable name
@uimaParameter
int myIntParam;
etc.
And then we would have the normal UIMA initialize code path, before it called
initialize, find the @uimaParameter items and set them from the XML parameter
settings.
-Marshall
On 10/18/2011 3:21 PM, Richard Eckart de Castilho wrote:
> Hello Jörn,
>
> I have added a page with some information about the context injection mechanism in uimaFIT to the uimaFIT wiki. The intention is to
>
> - illustrate how it currently works
> - point out the currently unresolved issues and feature ideas
> - provide some information on related DI mechanisms (e.g. JSR 250)
>
> Maybe you could have a look at that and tell me if additional information is required.
>
> Before an integration into the core UIMA framework I think it should be discussed whether custom DI annotations should be used (as currently done in uimaFIT), or if UIMA should support use JSR 250, or both since JSR 250 does not cover all our needs.
>
> Also, I think the open some of the open issues listed on the page should be resolved before an integration.
>
> It would be great if you could have a look at the page and tell me if that is a suitable format for the desired specification or at least a starting point for discussions.
>
> http://code.google.com/p/uimafit/wiki/ContextInjection
>
> Best,
>
> Richard
>
> Am 11.10.2011 um 22:11 schrieb Jörn Kottmann:
>
>> On 10/11/11 9:31 PM, Richard Eckart de Castilho wrote:
>>> Am 06.10.2011 um 18:31 schrieb Jörn Kottmann:
>>>
>>>>> On 10/6/11 5:47 PM, Richard Eckart de Castilho wrote:
>>>>>>> As a short update: there is a generally positive tenor towards this amongst the uimaFIT developers. I'll draft up an action plan, discuss that with my the others and afterwards present it here.
>>>>>>>
>>>>>>> Be patient with me though;)
>>>>> Regards the AE Java annotation part I believe we should work out a proposal which
>>>>> describes how to implement it in the UIMA core framework. Then it is easier to get consensus on it.
>>> That sounds reasonable. What form do you suggest that proposal should take?
>> I suggest that we write it down in a wiki page in a similar style like
>> it was done
>> for other proposals which are already in our wiki.
>>
>> Jörn
Re: UIMA and uimaFIT
Posted by Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de>.
Hello Jörn,
I have added a page with some information about the context injection mechanism in uimaFIT to the uimaFIT wiki. The intention is to
- illustrate how it currently works
- point out the currently unresolved issues and feature ideas
- provide some information on related DI mechanisms (e.g. JSR 250)
Maybe you could have a look at that and tell me if additional information is required.
Before an integration into the core UIMA framework I think it should be discussed whether custom DI annotations should be used (as currently done in uimaFIT), or if UIMA should support use JSR 250, or both since JSR 250 does not cover all our needs.
Also, I think the open some of the open issues listed on the page should be resolved before an integration.
It would be great if you could have a look at the page and tell me if that is a suitable format for the desired specification or at least a starting point for discussions.
http://code.google.com/p/uimafit/wiki/ContextInjection
Best,
Richard
Am 11.10.2011 um 22:11 schrieb Jörn Kottmann:
> On 10/11/11 9:31 PM, Richard Eckart de Castilho wrote:
>> Am 06.10.2011 um 18:31 schrieb Jörn Kottmann:
>>
>>>> On 10/6/11 5:47 PM, Richard Eckart de Castilho wrote:
>>>>>> As a short update: there is a generally positive tenor towards this amongst the uimaFIT developers. I'll draft up an action plan, discuss that with my the others and afterwards present it here.
>>>>>>
>>>>>> Be patient with me though;)
>>>>
>>>> Regards the AE Java annotation part I believe we should work out a proposal which
>>>> describes how to implement it in the UIMA core framework. Then it is easier to get consensus on it.
>> That sounds reasonable. What form do you suggest that proposal should take?
>
> I suggest that we write it down in a wiki page in a similar style like
> it was done
> for other proposals which are already in our wiki.
>
> Jörn
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckartde@tk.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: UIMA and uimaFIT
Posted by Jörn Kottmann <ko...@gmail.com>.
On 10/11/11 9:31 PM, Richard Eckart de Castilho wrote:
> Am 06.10.2011 um 18:31 schrieb Jörn Kottmann:
>
>> > On 10/6/11 5:47 PM, Richard Eckart de Castilho wrote:
>>> >> As a short update: there is a generally positive tenor towards this amongst the uimaFIT developers. I'll draft up an action plan, discuss that with my the others and afterwards present it here.
>>> >>
>>> >> Be patient with me though;)
>> >
>> > Regards the AE Java annotation part I believe we should work out a proposal which
>> > describes how to implement it in the UIMA core framework. Then it is easier to get consensus on it.
> That sounds reasonable. What form do you suggest that proposal should take?
I suggest that we write it down in a wiki page in a similar style like
it was done
for other proposals which are already in our wiki.
Jörn
Re: UIMA and uimaFIT
Posted by Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de>.
Am 06.10.2011 um 18:31 schrieb Jörn Kottmann:
> On 10/6/11 5:47 PM, Richard Eckart de Castilho wrote:
>> As a short update: there is a generally positive tenor towards this amongst the uimaFIT developers. I'll draft up an action plan, discuss that with my the others and afterwards present it here.
>>
>> Be patient with me though;)
>
> Regards the AE Java annotation part I believe we should work out a proposal which
> describes how to implement it in the UIMA core framework. Then it is easier to get consensus on it.
That sounds reasonable. What form do you suggest that proposal should take?
Best,
-- Richard
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckartde@tk.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: UIMA and uimaFIT
Posted by Jörn Kottmann <ko...@gmail.com>.
On 10/6/11 5:47 PM, Richard Eckart de Castilho wrote:
> As a short update: there is a generally positive tenor towards this amongst the uimaFIT developers. I'll draft up an action plan, discuss that with my the others and afterwards present it here.
>
> Be patient with me though;)
Regards the AE Java annotation part I believe we should work out a
proposal which
describes how to implement it in the UIMA core framework. Then it is
easier to get consensus on it.
Jörn