You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Michael Baessler <mb...@apache.org> on 2008/05/13 17:09:05 UTC
Annotation Mapping Annotator
Is there some interest/need in the UIMA community to have an annotation mapping annotator?
I think some of you might know the issue that different UIMA components work on different
annotations and type systems. A mapping annotator component could be used to translate the
annotations between these different requirements. E.g. we have a tokenizer component at the
beginning of the analysis flow that produces example.Token annotations with a POS feature set. Later
in the flow have a component that needs that information, but expects an example.Noun annotation.
Unfortunately there is no way to configure both components to produce or read different annotation
types, so in that case we need a mapping.
Tokenizer creates:
example.Token (2,8)
POS = NN
Mapping annotator translates this to:
example.Noun (2,8)
posTag = NN
If there is a need for such a component we can reuse some of the code developed for the UIMA
SimpleServer. The SimpleServer has a mapping syntax with additional filtering as shown below.
The mapping for the example above looks like:
<type name="example.Token" outputTag="example.Noun">
<filters>
<filter featurePath="POS" operator="=" value="NN" />
</filters>
<outputs>
<output featurePath="pos" outputAttribute="posTag"/>
</outputs>
</type>
Any feedback/comments for such a component?
Are there any implementations available?
-- Michael
RE: Annotation Mapping Annotator
Posted by "LeHouillier, Frank D." <Fr...@gd-ais.com>.
At some point I had started a project to create an XSLT style of CAS
transformer, to do all of the annotation based transformations (rather
than data oriented stuff that looks at the text itself). I can look and
see what shape that is in but I haven't had much luck in getting code
donations past management/legal in the past. At any rate this would in
general be a very useful project. I also would like to see Marshall's
suggestion of having a feature-name alias mapping be part of the
framework itself, somewhat similar to the Sofa Name Mapping capability
that is already there.
-----Original Message-----
From: Michael Baessler [mailto:mbaessler@apache.org]
Sent: Tuesday, May 13, 2008 11:09 AM
To: uima-user@incubator.apache.org
Subject: Annotation Mapping Annotator
Is there some interest/need in the UIMA community to have an annotation
mapping annotator?
I think some of you might know the issue that different UIMA components
work on different
annotations and type systems. A mapping annotator component could be
used to translate the
annotations between these different requirements. E.g. we have a
tokenizer component at the
beginning of the analysis flow that produces example.Token annotations
with a POS feature set. Later
in the flow have a component that needs that information, but expects an
example.Noun annotation.
Unfortunately there is no way to configure both components to produce or
read different annotation
types, so in that case we need a mapping.
Tokenizer creates:
example.Token (2,8)
POS = NN
Mapping annotator translates this to:
example.Noun (2,8)
posTag = NN
If there is a need for such a component we can reuse some of the code
developed for the UIMA
SimpleServer. The SimpleServer has a mapping syntax with additional
filtering as shown below.
The mapping for the example above looks like:
<type name="example.Token" outputTag="example.Noun">
<filters>
<filter featurePath="POS" operator="=" value="NN" />
</filters>
<outputs>
<output featurePath="pos" outputAttribute="posTag"/>
</outputs>
</type>
Any feedback/comments for such a component?
Are there any implementations available?
-- Michael
Re: Annotation Mapping Annotator
Posted by David Buttler <bu...@llnl.gov>.
There is a fundamental issue here, and the mapper you describe addresses
the symptom, but not the root problem. The problem is that everyone
creates their own schema, ontology, or type system, and is unwilling to
learn or use other type systems until they have been forced to (e.g. by
a standardization process). So, it is inevitable that many different
type systems will be created -- hampering the interoperability of
components. So, a mapper is an essential component that everyone will
continue to re-invent. UIMA definitely needs such a tool.
An alternative way of using a mapper is to consider it a wrapper for a
component. A wrapper would allow a pipeline to be constructed in a
single type system using heterogeneous components. This would be a
useful way of looking at the mapping functionality when adding a limited
number of external components to an existing pipeline. The mapper as
you described would be more useful in an ad hoc construction of
pipelines from pre-existing components. I think both are valid use cases.
Dave
Michael Baessler wrote:
> Is there some interest/need in the UIMA community to have an annotation mapping annotator?
>
> I think some of you might know the issue that different UIMA components work on different
> annotations and type systems. A mapping annotator component could be used to translate the
> annotations between these different requirements. E.g. we have a tokenizer component at the
> beginning of the analysis flow that produces example.Token annotations with a POS feature set. Later
> in the flow have a component that needs that information, but expects an example.Noun annotation.
> Unfortunately there is no way to configure both components to produce or read different annotation
> types, so in that case we need a mapping.
>
> Tokenizer creates:
>
> example.Token (2,8)
> POS = NN
>
> Mapping annotator translates this to:
>
> example.Noun (2,8)
> posTag = NN
>
>
> If there is a need for such a component we can reuse some of the code developed for the UIMA
> SimpleServer. The SimpleServer has a mapping syntax with additional filtering as shown below.
>
> The mapping for the example above looks like:
>
> <type name="example.Token" outputTag="example.Noun">
> <filters>
> <filter featurePath="POS" operator="=" value="NN" />
> </filters>
> <outputs>
> <output featurePath="pos" outputAttribute="posTag"/>
> </outputs>
> </type>
>
> Any feedback/comments for such a component?
> Are there any implementations available?
>
> -- Michael
>
>
RE: Annotation Mapping Annotator
Posted by "LeHouillier, Frank D." <Fr...@gd-ais.com>.
Like I said, I'm not against publishing type system descriptors, and
having a repository of descriptors seems like a good idea. What makes
me anxious is the idea that some subset of them might be dubbed
"recommended" rather than as "potentially useful sample". If everybody
happens to use only a few of the "potentially useful samples" by voting
with their feet, then so much the better.
-----Original Message-----
From: Thilo Goetz [mailto:twgoetz@gmx.de]
Sent: Thursday, May 15, 2008 10:48 AM
To: uima-user@incubator.apache.org
Subject: Re: Annotation Mapping Annotator
LeHouillier, Frank D. wrote:
> I'm not against publishing type system descriptors. I'm against
having
> them be canonized as part of UIMA proper, particularly of Apache UIMA.
> Apache UIMA is supposed to be an implementation of a standard, not a
> standard itself.
>
> While you might say that it is proactive to put forth your
"recommended"
> type system for NewsML2 events, if I disagree with it for some reason
I
> might think that it is destructive. These are things that should be
> hashed out by committees of interested parties rather than developers,
> who are typically looking at the problem from their own point of view.
[...]
There's no reason that committee couldn't be the uima-user
mailing list. Where else do you get so many interested
parties to show up? As Pascal says somewhere else, we
could have type systems in the sandbox, even competing
ones. Then people can vote with their feet. Most likely,
those type systems will survive that come with the most
useful analysis technology. Conversely, those type systems
that show a lot of activity will receive even more. That's
a more useful standard than one hashed out in a committee
which is later ignored by everybody. And yes, it's
developer driven, open source and open community.
One criterion for acceptance could be that any proposed
type system must come with some useful analysis (even if
it's just an adapter to some non-UIMA technology).
--Thilo
Re: Annotation Mapping Annotator
Posted by Thilo Goetz <tw...@gmx.de>.
LeHouillier, Frank D. wrote:
> I'm not against publishing type system descriptors. I'm against having
> them be canonized as part of UIMA proper, particularly of Apache UIMA.
> Apache UIMA is supposed to be an implementation of a standard, not a
> standard itself.
>
> While you might say that it is proactive to put forth your "recommended"
> type system for NewsML2 events, if I disagree with it for some reason I
> might think that it is destructive. These are things that should be
> hashed out by committees of interested parties rather than developers,
> who are typically looking at the problem from their own point of view.
[...]
There's no reason that committee couldn't be the uima-user
mailing list. Where else do you get so many interested
parties to show up? As Pascal says somewhere else, we
could have type systems in the sandbox, even competing
ones. Then people can vote with their feet. Most likely,
those type systems will survive that come with the most
useful analysis technology. Conversely, those type systems
that show a lot of activity will receive even more. That's
a more useful standard than one hashed out in a committee
which is later ignored by everybody. And yes, it's
developer driven, open source and open community.
One criterion for acceptance could be that any proposed
type system must come with some useful analysis (even if
it's just an adapter to some non-UIMA technology).
--Thilo
RE: Annotation Mapping Annotator
Posted by "LeHouillier, Frank D." <Fr...@gd-ais.com>.
I'm not against publishing type system descriptors. I'm against having
them be canonized as part of UIMA proper, particularly of Apache UIMA.
Apache UIMA is supposed to be an implementation of a standard, not a
standard itself.
While you might say that it is proactive to put forth your "recommended"
type system for NewsML2 events, if I disagree with it for some reason I
might think that it is destructive. These are things that should be
hashed out by committees of interested parties rather than developers,
who are typically looking at the problem from their own point of view.
I should also say that I think it _is_ useful to have tools which
translate between UIMA type systems and other representations such as
OWL/RDF or MOF as Olivier had suggested. To the extent that these
automatically create type systems for FOAF, SKOS and others, then there
won't be a need for such a committee because Apache won't have to
explicitly provide a type system. I'm also more comfortable with these
sorts of type systems because they are in essence part of the
meta-language rather than the object language, and will specify what
semantically gets annotated rather than how they get annotated
syntactically.
I really just don't like the idea of having c-command annotations or
illocutionary force annotations or anything remotely similar showing up
as part of Apache and I feel like that is the road that you are headed
down when you talk about "recommended type system" because someone is
going to want those things and is going to feel frustrated if they are
left out.
-----Original Message-----
From: Pascal Coupet [mailto:pascal.coupet@temis.com]
Sent: Thursday, May 15, 2008 6:44 AM
To: uima-user@incubator.apache.org
Subject: RE: Annotation Mapping Annotator
Well, standards are recommended objects. UIMA restricts your freedom too
with the promises that you will be able to interact in a much easier way
with others. I think we are at the early beginning but that standards
will emerge to represents common entities and this will make
applications and the web more useful. As stated by Olivier in another
mail, people in the web semantic domain are producing interesting
thinks, ACE is interesting also as you noted, NewsML2 is useful for
events in the news space and so on.
...
I agree. There are 2 levels for recommendations: one for the semantic
and a lot of work is already in progress, the second is how to represent
it using UIMA type systems. It will be nice to have recommended type
systems for ACE, NewML2 events, and so on because a same semantic
description can be encoded in various ways as UIMA type systems. This
can be triggered by the organization behind each proposal but it may be
much more efficient to be pro-active and propose type systems as part of
the UIMA Apache project for recognized standards. I think it will be
very useful to have a Sandbox for type systems in a similar ways than
the one for Annotators.
RE: Annotation Mapping Annotator
Posted by Pascal Coupet <pa...@temis.com>.
> From: LeHouillier, Frank D. [mailto:Frank.LeHouillier@gd-ais.com]
> Sent: Thursday, May 15, 2008 11:41 AM
> To: uima-user@incubator.apache.org
> Subject: RE: Annotation Mapping Annotator
>
> The case where you need a simple name mapping is not going to be a
> result of unrelated annotators being used together but rather as a
> result of the development process. Decoupling the type system from
the
> analysis engine should allow developers to do things like have
multiple
> JCas implementations of a single CAS type within a single jvm, for
> instance.
>
> Also, I have to say that I get nervous when I hear people talking
about
> getting some sort of "recommended type systems", especially when they
Well, standards are recommended objects. UIMA restricts your freedom too
with the promises that you will be able to interact in a much easier way
with others. I think we are at the early beginning but that standards
will emerge to represents common entities and this will make
applications and the web more useful. As stated by Olivier in another
mail, people in the web semantic domain are producing interesting
thinks, ACE is interesting also as you noted, NewsML2 is useful for
events in the news space and so on.
> are talking about syntactic sorts of things like syntactic trees,
> because having these presupposes some set of algorithms. Even getting
> the semantics for something like "token" down (is it simply white
space
> delimited? Is <n't> part of <can't> or a separate token?) forces one
You need to understand algorithms when you select a new tokenizer to
decide if it is acceptable to you, but if yes, your problem is now to
map its tags to what your following annotators are expecting.
> into using a particular set of algorithms. I'm not saying that there
> can't be recommendations but they should be completely divorced from
> UIMA, the OASIS standard or the Apache implementation. If I thought
> that most developers on UIMA were targeting something like a
Minimalist
> Syntax named entity/relationship recognizer for ACE annotation types
> because a recommendation saying such was part of the spec, I wouldn't
go
> near the thing. We should encourage NIST to adopt UIMA for ACE,
rather
> than having UIMA adopt the ACE types.
I agree. There are 2 levels for recommendations: one for the semantic
and a lot of work is already in progress, the second is how to represent
it using UIMA type systems. It will be nice to have recommended type
systems for ACE, NewML2 events, and so on because a same semantic
description can be encoded in various ways as UIMA type systems. This
can be triggered by the organization behind each proposal but it may be
much more efficient to be pro-active and propose type systems as part of
the UIMA Apache project for recognized standards. I think it will be
very useful to have a Sandbox for type systems in a similar ways than
the one for Annotators.
>
> -----Original Message-----
> From: Steven Bethard [mailto:steven.bethard@gmail.com]
> Sent: Wednesday, May 14, 2008 2:57 PM
> To: uima-user@incubator.apache.org
> Cc: mbaessler@apache.org
> Subject: Re: Annotation Mapping Annotator
>
> On Tue, May 13, 2008 at 11:36 AM, Pascal Coupet
> <pa...@temis.com> wrote:
> > However a simple mapping solves only a part of the issue. In a lot
of
> > case, the mapping operation requires a lot of intelligence. For a
> tagger
> > by example, one will have 17 tags related to Verbs and another 4: a
> > simple mapping will not work. For a name extractor, one will provide
2
> > fields, firstName and lastName, and another one will have a middle
> > initial, a title and so on. So a lot of time you have to modify the
> data
> > themselves to move those from one typesystem to another one and this
> > require simple or not so simple code.
>
> FWIW, the annotation mapping problems I've run into are all of this
> type - where a simple name-to-name mapping is insufficient. The
> solution so far has simply been to write an appropriate AnalysisEngine
> that does the translation. I like this option better than introducing
> a scripting language or an XML file -- if I'm forced to write in Java
> in the first place, I at least want to get the most out of its type
> checking.
>
> > A flexible mapping annotator will be very useful in the UIMA. This
is
> > one way which is needed and pragmatic. Another important and
> > complementary way to tackle the issue is to have some
recommendations
> > for standards entity types like People names, dates, places and so
on,
> > like Dublin Core for Metadata. If we do this, people providing
> > annotators will be able to add this type as output and will do the
> > mapping themselves to be "UIMA people compliant" by example. This
can
> be
> > a degraded mode for them in regard of their standard capabilities
but
> > this will be nice for fast prototyping.
>
> Having some recommended type systems for common types would be
> incredibly useful. Common things we run into: sentences, tokens,
> stems, parts of speech, named entities, syntactic trees, semantic role
> structures. If there were standard representations for these, we'd be
> happy to use them instead of inventing our own.
>
> Steve
> --
> I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
> tiny blip on the distant coast of sanity.
> --- Bucky Katt, Get Fuzzy
RE: Annotation Mapping Annotator
Posted by "LeHouillier, Frank D." <Fr...@gd-ais.com>.
The case where you need a simple name mapping is not going to be a
result of unrelated annotators being used together but rather as a
result of the development process. Decoupling the type system from the
analysis engine should allow developers to do things like have multiple
JCas implementations of a single CAS type within a single jvm, for
instance.
Also, I have to say that I get nervous when I hear people talking about
getting some sort of "recommended type systems", especially when they
are talking about syntactic sorts of things like syntactic trees,
because having these presupposes some set of algorithms. Even getting
the semantics for something like "token" down (is it simply white space
delimited? Is <n't> part of <can't> or a separate token?) forces one
into using a particular set of algorithms. I'm not saying that there
can't be recommendations but they should be completely divorced from
UIMA, the OASIS standard or the Apache implementation. If I thought
that most developers on UIMA were targeting something like a Minimalist
Syntax named entity/relationship recognizer for ACE annotation types
because a recommendation saying such was part of the spec, I wouldn't go
near the thing. We should encourage NIST to adopt UIMA for ACE, rather
than having UIMA adopt the ACE types.
-----Original Message-----
From: Steven Bethard [mailto:steven.bethard@gmail.com]
Sent: Wednesday, May 14, 2008 2:57 PM
To: uima-user@incubator.apache.org
Cc: mbaessler@apache.org
Subject: Re: Annotation Mapping Annotator
On Tue, May 13, 2008 at 11:36 AM, Pascal Coupet
<pa...@temis.com> wrote:
> However a simple mapping solves only a part of the issue. In a lot of
> case, the mapping operation requires a lot of intelligence. For a
tagger
> by example, one will have 17 tags related to Verbs and another 4: a
> simple mapping will not work. For a name extractor, one will provide 2
> fields, firstName and lastName, and another one will have a middle
> initial, a title and so on. So a lot of time you have to modify the
data
> themselves to move those from one typesystem to another one and this
> require simple or not so simple code.
FWIW, the annotation mapping problems I've run into are all of this
type - where a simple name-to-name mapping is insufficient. The
solution so far has simply been to write an appropriate AnalysisEngine
that does the translation. I like this option better than introducing
a scripting language or an XML file -- if I'm forced to write in Java
in the first place, I at least want to get the most out of its type
checking.
> A flexible mapping annotator will be very useful in the UIMA. This is
> one way which is needed and pragmatic. Another important and
> complementary way to tackle the issue is to have some recommendations
> for standards entity types like People names, dates, places and so on,
> like Dublin Core for Metadata. If we do this, people providing
> annotators will be able to add this type as output and will do the
> mapping themselves to be "UIMA people compliant" by example. This can
be
> a degraded mode for them in regard of their standard capabilities but
> this will be nice for fast prototyping.
Having some recommended type systems for common types would be
incredibly useful. Common things we run into: sentences, tokens,
stems, parts of speech, named entities, syntactic trees, semantic role
structures. If there were standard representations for these, we'd be
happy to use them instead of inventing our own.
Steve
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
RE: Annotation Mapping Annotator
Posted by Pascal Coupet <pa...@temis.com>.
Well, using a scripting language has scripting language advantages! It
can be interesting or not depending of your context.
It's fast to do a modification like correcting a regexp and anybody can
do it. No need too be a Java developper and have a Java development
environment at hand. So a quick fix on a server is much easier this way.
It's mainly a glue program and scripting languages are good at that.
We use something very similar to the BSF annotator which is in the UIMA
sandbox.
Pascal
-----Original Message-----
From: Steven Bethard [mailto:steven.bethard@gmail.com]
Sent: Wednesday, May 14, 2008 8:57 PM
To: uima-user@incubator.apache.org
Cc: mbaessler@apache.org
Subject: Re: Annotation Mapping Annotator
On Tue, May 13, 2008 at 11:36 AM, Pascal Coupet
<pa...@temis.com> wrote:
> However a simple mapping solves only a part of the issue. In a lot of
> case, the mapping operation requires a lot of intelligence. For a
tagger
> by example, one will have 17 tags related to Verbs and another 4: a
> simple mapping will not work. For a name extractor, one will provide 2
> fields, firstName and lastName, and another one will have a middle
> initial, a title and so on. So a lot of time you have to modify the
data
> themselves to move those from one typesystem to another one and this
> require simple or not so simple code.
FWIW, the annotation mapping problems I've run into are all of this
type - where a simple name-to-name mapping is insufficient. The
solution so far has simply been to write an appropriate AnalysisEngine
that does the translation. I like this option better than introducing
a scripting language or an XML file -- if I'm forced to write in Java
in the first place, I at least want to get the most out of its type
checking.
> A flexible mapping annotator will be very useful in the UIMA. This is
> one way which is needed and pragmatic. Another important and
> complementary way to tackle the issue is to have some recommendations
> for standards entity types like People names, dates, places and so on,
> like Dublin Core for Metadata. If we do this, people providing
> annotators will be able to add this type as output and will do the
> mapping themselves to be "UIMA people compliant" by example. This can
be
> a degraded mode for them in regard of their standard capabilities but
> this will be nice for fast prototyping.
Having some recommended type systems for common types would be
incredibly useful. Common things we run into: sentences, tokens,
stems, parts of speech, named entities, syntactic trees, semantic role
structures. If there were standard representations for these, we'd be
happy to use them instead of inventing our own.
Steve
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
Re: Annotation Mapping Annotator
Posted by Steven Bethard <st...@gmail.com>.
On Tue, May 13, 2008 at 11:36 AM, Pascal Coupet <pa...@temis.com> wrote:
> However a simple mapping solves only a part of the issue. In a lot of
> case, the mapping operation requires a lot of intelligence. For a tagger
> by example, one will have 17 tags related to Verbs and another 4: a
> simple mapping will not work. For a name extractor, one will provide 2
> fields, firstName and lastName, and another one will have a middle
> initial, a title and so on. So a lot of time you have to modify the data
> themselves to move those from one typesystem to another one and this
> require simple or not so simple code.
FWIW, the annotation mapping problems I've run into are all of this
type - where a simple name-to-name mapping is insufficient. The
solution so far has simply been to write an appropriate AnalysisEngine
that does the translation. I like this option better than introducing
a scripting language or an XML file -- if I'm forced to write in Java
in the first place, I at least want to get the most out of its type
checking.
> A flexible mapping annotator will be very useful in the UIMA. This is
> one way which is needed and pragmatic. Another important and
> complementary way to tackle the issue is to have some recommendations
> for standards entity types like People names, dates, places and so on,
> like Dublin Core for Metadata. If we do this, people providing
> annotators will be able to add this type as output and will do the
> mapping themselves to be "UIMA people compliant" by example. This can be
> a degraded mode for them in regard of their standard capabilities but
> this will be nice for fast prototyping.
Having some recommended type systems for common types would be
incredibly useful. Common things we run into: sentences, tokens,
stems, parts of speech, named entities, syntactic trees, semantic role
structures. If there were standard representations for these, we'd be
happy to use them instead of inventing our own.
Steve
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
Re: Annotation Mapping Annotator
Posted by Marshall Schor <ms...@schor.com>.
The simple name translation capability I think could be provided by an
extension to the base framework, using an "alias" notion. The concept
would be to allow multiple type and feature names to map to the same
internal type. This would allow the same internal CAS object to be
referred to by the aliased names, without doing any actual copying of
the object.
-Marshall
David Buttler wrote:
> I agree with Pascal that there are many use cases where simple name
> transformation (e.g. org.apache.uima.Person to com.company.PersonName)
> is insufficient. Incorporating a scripting framework that allows
> arbitrary computation is the easiest way to create a component that is
> usable for the task. However, I think the simple name translation
> service does provide value by itself, and it is conceptually much
> simpler to use.
> I would like to see both components. This would allow people to start
> with something that is simple and easy to use, and then graduate into
> a more complex mapping once they realize the need. Either that, or a
> component that does everything Pascal describes, but also allows a
> simple configuration for easy cases without a performance or
> configuration penalty for being able to extend a mapping to a
> scripting framework.
>
> Dave
>
> Pascal Coupet wrote:
>> This is indeed an important issue for an easy interoperability.
>>
>> However a simple mapping solves only a part of the issue. In a lot of
>> case, the mapping operation requires a lot of intelligence. For a tagger
>> by example, one will have 17 tags related to Verbs and another 4: a
>> simple mapping will not work. For a name extractor, one will provide 2
>> fields, firstName and lastName, and another one will have a middle
>> initial, a title and so on. So a lot of time you have to modify the data
>> themselves to move those from one typesystem to another one and this
>> require simple or not so simple code.
>> What we do usually is to use a java scripting language to do the mapping
>> like beanshell. This is flexible and simple but still powerful to use
>> Java libs you may have to do complex things. Maybe an idea could be to
>> develop a mapping component based on a java scripting language,
>> configurable using XML files as you suggest but also flexible to add
>> code in an easy way.
>> A flexible mapping annotator will be very useful in the UIMA. This is
>> one way which is needed and pragmatic. Another important and
>> complementary way to tackle the issue is to have some recommendations
>> for standards entity types like People names, dates, places and so on,
>> like Dublin Core for Metadata. If we do this, people providing
>> annotators will be able to add this type as output and will do the
>> mapping themselves to be "UIMA people compliant" by example. This can be
>> a degraded mode for them in regard of their standard capabilities but
>> this will be nice for fast prototyping.
>>
>>
>> Pascal
>>
>> -----Original Message-----
>> From: Michael Baessler [mailto:mbaessler@apache.org] Sent: Tuesday,
>> May 13, 2008 5:09 PM
>> To: uima-user@incubator.apache.org
>> Subject: Annotation Mapping Annotator
>>
>> Is there some interest/need in the UIMA community to have an annotation
>> mapping annotator?
>>
>> I think some of you might know the issue that different UIMA components
>> work on different
>> annotations and type systems. A mapping annotator component could be
>> used to translate the
>> annotations between these different requirements. E.g. we have a
>> tokenizer component at the
>> beginning of the analysis flow that produces example.Token annotations
>> with a POS feature set. Later
>> in the flow have a component that needs that information, but expects an
>> example.Noun annotation.
>> Unfortunately there is no way to configure both components to produce or
>> read different annotation
>> types, so in that case we need a mapping.
>>
>> Tokenizer creates:
>>
>> example.Token (2,8)
>> POS = NN
>>
>> Mapping annotator translates this to:
>>
>> example.Noun (2,8)
>> posTag = NN
>>
>>
>> If there is a need for such a component we can reuse some of the code
>> developed for the UIMA
>> SimpleServer. The SimpleServer has a mapping syntax with additional
>> filtering as shown below.
>>
>> The mapping for the example above looks like:
>>
>> <type name="example.Token" outputTag="example.Noun">
>> <filters>
>> <filter featurePath="POS" operator="=" value="NN" />
>> </filters>
>> <outputs>
>> <output featurePath="pos" outputAttribute="posTag"/>
>>
>> </outputs>
>> </type>
>>
>> Any feedback/comments for such a component?
>> Are there any implementations available?
>>
>> -- Michael
>>
>>
>
>
>
Re: Annotation Mapping Annotator
Posted by David Buttler <bu...@llnl.gov>.
I agree with Pascal that there are many use cases where simple name
transformation (e.g. org.apache.uima.Person to com.company.PersonName)
is insufficient. Incorporating a scripting framework that allows
arbitrary computation is the easiest way to create a component that is
usable for the task. However, I think the simple name translation
service does provide value by itself, and it is conceptually much
simpler to use.
I would like to see both components. This would allow people to start
with something that is simple and easy to use, and then graduate into a
more complex mapping once they realize the need. Either that, or a
component that does everything Pascal describes, but also allows a
simple configuration for easy cases without a performance or
configuration penalty for being able to extend a mapping to a scripting
framework.
Dave
Pascal Coupet wrote:
> This is indeed an important issue for an easy interoperability.
>
> However a simple mapping solves only a part of the issue. In a lot of
> case, the mapping operation requires a lot of intelligence. For a tagger
> by example, one will have 17 tags related to Verbs and another 4: a
> simple mapping will not work. For a name extractor, one will provide 2
> fields, firstName and lastName, and another one will have a middle
> initial, a title and so on. So a lot of time you have to modify the data
> themselves to move those from one typesystem to another one and this
> require simple or not so simple code.
>
> What we do usually is to use a java scripting language to do the mapping
> like beanshell. This is flexible and simple but still powerful to use
> Java libs you may have to do complex things. Maybe an idea could be to
> develop a mapping component based on a java scripting language,
> configurable using XML files as you suggest but also flexible to add
> code in an easy way.
>
> A flexible mapping annotator will be very useful in the UIMA. This is
> one way which is needed and pragmatic. Another important and
> complementary way to tackle the issue is to have some recommendations
> for standards entity types like People names, dates, places and so on,
> like Dublin Core for Metadata. If we do this, people providing
> annotators will be able to add this type as output and will do the
> mapping themselves to be "UIMA people compliant" by example. This can be
> a degraded mode for them in regard of their standard capabilities but
> this will be nice for fast prototyping.
>
>
>
> Pascal
>
> -----Original Message-----
> From: Michael Baessler [mailto:mbaessler@apache.org]
> Sent: Tuesday, May 13, 2008 5:09 PM
> To: uima-user@incubator.apache.org
> Subject: Annotation Mapping Annotator
>
> Is there some interest/need in the UIMA community to have an annotation
> mapping annotator?
>
> I think some of you might know the issue that different UIMA components
> work on different
> annotations and type systems. A mapping annotator component could be
> used to translate the
> annotations between these different requirements. E.g. we have a
> tokenizer component at the
> beginning of the analysis flow that produces example.Token annotations
> with a POS feature set. Later
> in the flow have a component that needs that information, but expects an
> example.Noun annotation.
> Unfortunately there is no way to configure both components to produce or
> read different annotation
> types, so in that case we need a mapping.
>
> Tokenizer creates:
>
> example.Token (2,8)
> POS = NN
>
> Mapping annotator translates this to:
>
> example.Noun (2,8)
> posTag = NN
>
>
> If there is a need for such a component we can reuse some of the code
> developed for the UIMA
> SimpleServer. The SimpleServer has a mapping syntax with additional
> filtering as shown below.
>
> The mapping for the example above looks like:
>
> <type name="example.Token" outputTag="example.Noun">
> <filters>
> <filter featurePath="POS" operator="=" value="NN" />
> </filters>
> <outputs>
> <output featurePath="pos" outputAttribute="posTag"/>
>
> </outputs>
> </type>
>
> Any feedback/comments for such a component?
> Are there any implementations available?
>
> -- Michael
>
>
RE: Annotation Mapping Annotator
Posted by Pascal Coupet <pa...@temis.com>.
This is indeed an important issue for an easy interoperability.
However a simple mapping solves only a part of the issue. In a lot of
case, the mapping operation requires a lot of intelligence. For a tagger
by example, one will have 17 tags related to Verbs and another 4: a
simple mapping will not work. For a name extractor, one will provide 2
fields, firstName and lastName, and another one will have a middle
initial, a title and so on. So a lot of time you have to modify the data
themselves to move those from one typesystem to another one and this
require simple or not so simple code.
What we do usually is to use a java scripting language to do the mapping
like beanshell. This is flexible and simple but still powerful to use
Java libs you may have to do complex things. Maybe an idea could be to
develop a mapping component based on a java scripting language,
configurable using XML files as you suggest but also flexible to add
code in an easy way.
A flexible mapping annotator will be very useful in the UIMA. This is
one way which is needed and pragmatic. Another important and
complementary way to tackle the issue is to have some recommendations
for standards entity types like People names, dates, places and so on,
like Dublin Core for Metadata. If we do this, people providing
annotators will be able to add this type as output and will do the
mapping themselves to be "UIMA people compliant" by example. This can be
a degraded mode for them in regard of their standard capabilities but
this will be nice for fast prototyping.
Pascal
-----Original Message-----
From: Michael Baessler [mailto:mbaessler@apache.org]
Sent: Tuesday, May 13, 2008 5:09 PM
To: uima-user@incubator.apache.org
Subject: Annotation Mapping Annotator
Is there some interest/need in the UIMA community to have an annotation
mapping annotator?
I think some of you might know the issue that different UIMA components
work on different
annotations and type systems. A mapping annotator component could be
used to translate the
annotations between these different requirements. E.g. we have a
tokenizer component at the
beginning of the analysis flow that produces example.Token annotations
with a POS feature set. Later
in the flow have a component that needs that information, but expects an
example.Noun annotation.
Unfortunately there is no way to configure both components to produce or
read different annotation
types, so in that case we need a mapping.
Tokenizer creates:
example.Token (2,8)
POS = NN
Mapping annotator translates this to:
example.Noun (2,8)
posTag = NN
If there is a need for such a component we can reuse some of the code
developed for the UIMA
SimpleServer. The SimpleServer has a mapping syntax with additional
filtering as shown below.
The mapping for the example above looks like:
<type name="example.Token" outputTag="example.Noun">
<filters>
<filter featurePath="POS" operator="=" value="NN" />
</filters>
<outputs>
<output featurePath="pos" outputAttribute="posTag"/>
</outputs>
</type>
Any feedback/comments for such a component?
Are there any implementations available?
-- Michael