You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2015/06/18 16:41:17 UTC
Ideas for UIMA v3
I've put up another wiki page as a place to collect ideas for UIMA version 3.
It's a place to dream a bit. It goes with the earlier page,
https://cwiki.apache.org/confluence/display/UIMA/Modernizing+the+internals+of+UIMA .
Feel free to contribute, of course!
The page is linked from the above page, but here's the direct link:
https://cwiki.apache.org/confluence/display/UIMA/Ideas+for+UIMAJ+v3
-Marshall
Re: Ideas for UIMA v3
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 23.06.2015, at 15:03, Thilo Goetz <tw...@gmx.de> wrote:
> On 06/22/2015 06:23 PM, Marshall Schor wrote:
>> In reading this paper, it seems one of the key ideas is "dynamic typing". There
>> seems to be multiple aspects to this, including type "adapters" of various
>> kinds, to enable more-easily fitting together independently developed
>> components. I also get the sense that making things "easy" for developers is a
>> value that dynamic typing provides. Are you thinking here of the Javascript
>> style of typing values as "var" instead of specific static types?
>>
>> If dynamic typing means something beyond getting independently - developed
>> components' type systems to work together "easily", can you give a couple of use
>> cases of what the dream is here?
>
> That would be a good start. Beyond that, think about what we call generic annotators, i.e., annotators that take a spec as input (e.g., a bunch of regex rules) and produce annotations or other data as output. The data types that the generic annotator produces varies with the spec, and so it can't have a static, external type system. It might produce tokens with one spec, sentences with another, and person names with a third.
>
> Also, and I can't stress this enough, I want to be able to communicate with annotators just at the level of the data. I want to be able to read data from files, or from network streams. I want to read from Kafka or sequence files in HDFS. And I want to be able to do that without having to know the precise type system that the data was written with. And I want to be able to do this in Python or Go if I feel like it, so there must be no framework dependency. Think JSON.
>
> Of course I need to know a thing or two about the data format, otherwise the data is not very useful. However, if I just need the tokens, I don't want to have to know all the rest, and I'd like this to be a lot easier than it is now in UIMA.
We had a nice discussion about this at the COLING workshop ;)
E.g. right now it is quite annoying to change the type system in the CAS for such a generic annotator. It *is* in fact possible, e.g. setting up a component that does:
1) serialize the current CAS to a byte buffer A
2) create a new temporary CAS with the desired (extended) type system
3) serialize it to another byte buffer B
4) unserialize B into the current CAS (basically redefining the current type system)
5) unserializing A back into the current CAS using a lenient deserialization
This works in the serialization mechanism are smartly chosen, but it is not really convenient at all.
I think there was some discussion about removing the need to "lock" the type system after CAS initialization as well - in the workshop as well as here on the list, wasn't there?
Cheers,
-- Richard
Re: Ideas for UIMA v3
Posted by Thilo Goetz <tw...@gmx.de>.
On 06/23/2015 05:11 PM, Marshall Schor wrote:
> I added a wiki page to develop the ideas here.
>
> This is what I got from reading this:
>
> One idea is having an annotator not have a type system specification, but rather
> have it dynamically create types / features according to some configuration info
> or some dynamically-obtained information (perhaps the results of some previous
> analysis).
>
> Another idea is having an annotator be able to read Feature Structure data from
> a wide variety of sources, and have the data include the type/feature metadata
> (either externally - as we do now in UIMA with a type system external XML
> specification, or embedded - like JSON would naturally do). Such an annotator
> would have some notion of the type / feature information it was interested in
> processing, but could ignore the rest.
>
> Finally, a third idea is to have the componentization be such that no "UIMA
> Framework" was needed, or if present, it's hidden. I'm thinking that this
> means, for simpler analytics, the idea of a pipe line, and combining things,
> would not be present; it would be more like just a single annotator. For more
> complex things, the idea of a pipeline would be encapsulated (like UIMA's
> Aggregates), and the whole thing would look like something that could be
> embedded, in any of the other "big data" frameworks as an analysis piece. The
> implication is that this would enable using other frameworks' scaleout mechanisms.
>
> Does this capture the ideas? Please fill what I may have missed :-)
>
> -Marshall
>
That captures it pretty well.
--Thilo
Re: Ideas for UIMA v3
Posted by Joern Kottmann <ko...@gmail.com>.
I think it would be very valuable to collect and write down a couple of
user stories to see where people have problems using UIMA, and maybe also
stories about how they would like to use it. We can also use these stories
to make design decision for v3.
If people are just holding it wrong there is probably no reason to even
make v3.
Jörn
On Thu, Jul 23, 2015 at 3:33 PM, Marshall Schor <ms...@schor.com> wrote:
>
>
> On 7/23/2015 8:55 AM, Richard Eckart de Castilho wrote:
> > On 23.07.2015, at 14:43, Joern Kottmann <ko...@gmail.com> wrote:
> >
> >> One thing which must have been overlooked when UIMA was built is that
> >> people (like me) have to write code which wants to interact with the CAS
> >> but can't be an AE. In UIMA the CAS (either in memory, or serialized)
> >> is difficult to
> >> be used without implementing an AE.
> > I'm not sure why you feel like that. E.g. in WebAnno (an annotation
> editor
> > that uses the CAS as its internal data model), create operate with the
> CAS
> > basically without any AEs. All editing operations are done directly on
> the
> > CAS which is loaded/saved directly using the UIMA API calls for binary
> > serialization.
>
> One possible reason why people feel this way might be that we're missing
> some
> entertaining and compelling stories in multiple kinds of media that
> explain how
> to do the
> kinds of things, easily, that people say are hard. For example, there's
> little
> written on the
> new JSON serialization that gives lots of examples, including the
> super-simple
> varieties
> that are possible (i.e. omitting the context info). Volunteers
> wanted/needed to
> write this! :-)
>
> -Marshall
> >
> > Basically, we are using the same API that we would be using in an AE,
> but without
> > the AE/pipelining stuff. It doesn't get any more difficult without the
> AE - in fact
> > some things become easier without AEs, readers, and consumers.
> >
> > I'm sure you must have something similar in the CAS Editor plugin in
> Eclipse, no?
> >
> > -- Richard
>
>
Re: Ideas for UIMA v3
Posted by Marshall Schor <ms...@schor.com>.
On 7/23/2015 8:55 AM, Richard Eckart de Castilho wrote:
> On 23.07.2015, at 14:43, Joern Kottmann <ko...@gmail.com> wrote:
>
>> One thing which must have been overlooked when UIMA was built is that
>> people (like me) have to write code which wants to interact with the CAS
>> but can't be an AE. In UIMA the CAS (either in memory, or serialized)
>> is difficult to
>> be used without implementing an AE.
> I'm not sure why you feel like that. E.g. in WebAnno (an annotation editor
> that uses the CAS as its internal data model), create operate with the CAS
> basically without any AEs. All editing operations are done directly on the
> CAS which is loaded/saved directly using the UIMA API calls for binary
> serialization.
One possible reason why people feel this way might be that we're missing some
entertaining and compelling stories in multiple kinds of media that explain how
to do the
kinds of things, easily, that people say are hard. For example, there's little
written on the
new JSON serialization that gives lots of examples, including the super-simple
varieties
that are possible (i.e. omitting the context info). Volunteers wanted/needed to
write this! :-)
-Marshall
>
> Basically, we are using the same API that we would be using in an AE, but without
> the AE/pipelining stuff. It doesn't get any more difficult without the AE - in fact
> some things become easier without AEs, readers, and consumers.
>
> I'm sure you must have something similar in the CAS Editor plugin in Eclipse, no?
>
> -- Richard
Re: Ideas for UIMA v3
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 23.07.2015, at 19:17, Joern Kottmann <ko...@gmail.com> wrote:
> With my CAS-like thing I can just write cas.getIndex("index37",
> EmailAddressAnnotation.class) and it just returns them as Java objects
> of type EmailAddressAnnotation.
>
> In a different place in the system the code might only assume its an
> annotation and retrieves the same index as objects of type AnnotationFS.
> cas.getIndex("index37", AnnotationFS.class)
This sounds like the kind of API that uimaFIT supports on top of uimaj-core in JCasUtil:
for (EmailAddressAnnotation : select(jcas, EmailAddressAnnotation.class)) {
...
}
for (Annotation : select(jcas, Annotation.class)) {
...
}
The recent changes in uimaj-core allow almost the same now:
for (EmailAddressAnnotation t : jcas.getAnnotationIndex(EmailAddressAnnotation.class)) {
...
}
However, as far as I see it neither uimaFIT nor UIMA currently provide this kind of API for custom indexes - should be easy to add.
> UIMA doesn't make it easy with its static type system to write generic
> code working with CASes.
It is not possible (without hacks) to add features or types during pipeline execution. But since you appear to be working with pre-defined (Java) classes (similar to JCas wrappers), I don't see a problem. You have to know your Java classes at build time, so why is it not possible to know the typesystem at build time?
-- Richard
Re: Ideas for UIMA v3
Posted by Michael Tanenblatt <sl...@park-slope.net>.
> On Jul 24, 2015, at 8:08 AM, Joern Kottmann <ko...@gmail.com> wrote:
>
> On Fri, Jul 24, 2015 at 12:46 PM, Richard Eckart de Castilho <rec@apache.org <ma...@apache.org>
>> wrote:
>
>> On 23.07.2015, at 19:17, Joern Kottmann <ko...@gmail.com> wrote:
>>
>>>> If this is the scenario, another option would be to have the serialized
>> CASes
>>>> stored along with a reference to their type system, and have some new
>>>> deserialization capability be able to locate the referred-to type
>> system along
>>>> with the CAS to be read in. Would that "solve" this issue, or are
>> there other
>>>> aspects?
>>
>> https://issues.apache.org/jira/browse/UIMA-2127 ;)
>>
>> But having the TS stored alongside the CAS also is nice - see below.
>>
>>> It would probably solve it, but it is not a simple solution either. That
>>> would mean that the Type System get switched frequently and have be
>>> looked up all the time.
>>
>> For DKPro Core, I have implemented a BinaryCasWriter that stores the type
>> system in the same file as the binary serialized CAS. It is not always the
>> best solution because it adds a fixed overhead to every file, but it is
>> very convenient. Optionally, the type system can be stored externally in a
>> separate file to avoid this overhead. If and how this typesystem can be
>> used depends on which of the six kinds of binary serialization is being
>> used. See [1] for an overview over these formats and their properties.
>>
>>
> We have a few hundred million documents in the system, storing the ts with
> each document would be wasteful. It needs storage and it has to be parsed
> for each CAS.
>
>
>
>> In the BinaryCasReader, depending on the type of serialization, either:
>> - there is a failure if the pipeline CAS typesystem is not compatible with
>> the persisted CAS;
>> - the type system in the pipeline CAS is reinitialized from the persisted
>> CAS;
>> - the data from the persisted CAS is loaded leniently, dropping all FSes
>> that are not defined in the pipeline CAS typesystem
>>
>> Furthermore, the BinaryCasReader auto-detects the binary format and loads
>> it, be it the Java serialization-based format or one of the binary formats
>> that Marschall recently created, or our extended format that also embeds
>> the typesystem in the file.
>>
>> Mind that depending on the use-case a different kind of serialization may
>> be appropriate.
>>
>> For me, this covers in particular the following use-cases:
>>
>> - fast (de)serialization of the entire CAS
>> - compact binary format (some more some less)
>> - stable FS addresses (in some formats)
>> - restoring the pipeline CAS type system from file (i.e. CAS can be
>> initialized with an empty type system on creation and TS is set by reader -
>> in some formats)
>> - lenient loading of data allowing for different TSes on disk and in
>> pipeline (in some formats)
>>
>> Would such an approach cover (some of your) use-cases?
>>
>
>
> With the current design the best option is probably to store a type system
> id with the document.
Agreed with this—where the type system ID is a URI
> It would be nice to avoid that additional complexity.
>
> I think I have mainly two cases I can't really deal with:
> - A CAS contains FSes of many types. I know a few of those types and would
> like to only work with them. Not interested at all in the FSes with other
> types.
> - A CAS contains FSes of many types. I just want to deal with them as if
> they have a certain super-type. That could be FeatureStructure or
> AnnotationFS.
>
> The CASes above have been produced by many different AAEs with similar, but
> slightly different type systems.
Right, those are typical issues that people will commonly need to surmount, particularly the second, where the super-type is some relatively generic type (e.g., Token).
..m
Re: Ideas for UIMA v3
Posted by Joern Kottmann <ko...@gmail.com>.
On Fri, Jul 24, 2015 at 12:46 PM, Richard Eckart de Castilho <rec@apache.org
> wrote:
> On 23.07.2015, at 19:17, Joern Kottmann <ko...@gmail.com> wrote:
>
> >> If this is the scenario, another option would be to have the serialized
> CASes
> >> stored along with a reference to their type system, and have some new
> >> deserialization capability be able to locate the referred-to type
> system along
> >> with the CAS to be read in. Would that "solve" this issue, or are
> there other
> >> aspects?
>
> https://issues.apache.org/jira/browse/UIMA-2127 ;)
>
> But having the TS stored alongside the CAS also is nice - see below.
>
> > It would probably solve it, but it is not a simple solution either. That
> > would mean that the Type System get switched frequently and have be
> > looked up all the time.
>
> For DKPro Core, I have implemented a BinaryCasWriter that stores the type
> system in the same file as the binary serialized CAS. It is not always the
> best solution because it adds a fixed overhead to every file, but it is
> very convenient. Optionally, the type system can be stored externally in a
> separate file to avoid this overhead. If and how this typesystem can be
> used depends on which of the six kinds of binary serialization is being
> used. See [1] for an overview over these formats and their properties.
>
>
We have a few hundred million documents in the system, storing the ts with
each document would be wasteful. It needs storage and it has to be parsed
for each CAS.
> In the BinaryCasReader, depending on the type of serialization, either:
> - there is a failure if the pipeline CAS typesystem is not compatible with
> the persisted CAS;
> - the type system in the pipeline CAS is reinitialized from the persisted
> CAS;
> - the data from the persisted CAS is loaded leniently, dropping all FSes
> that are not defined in the pipeline CAS typesystem
>
> Furthermore, the BinaryCasReader auto-detects the binary format and loads
> it, be it the Java serialization-based format or one of the binary formats
> that Marschall recently created, or our extended format that also embeds
> the typesystem in the file.
>
> Mind that depending on the use-case a different kind of serialization may
> be appropriate.
>
> For me, this covers in particular the following use-cases:
>
> - fast (de)serialization of the entire CAS
> - compact binary format (some more some less)
> - stable FS addresses (in some formats)
> - restoring the pipeline CAS type system from file (i.e. CAS can be
> initialized with an empty type system on creation and TS is set by reader -
> in some formats)
> - lenient loading of data allowing for different TSes on disk and in
> pipeline (in some formats)
>
> Would such an approach cover (some of your) use-cases?
>
With the current design the best option is probably to store a type system
id with the document.
It would be nice to avoid that additional complexity.
I think I have mainly two cases I can't really deal with:
- A CAS contains FSes of many types. I know a few of those types and would
like to only work with them. Not interested at all in the FSes with other
types.
- A CAS contains FSes of many types. I just want to deal with them as if
they have a certain super-type. That could be FeatureStructure or
AnnotationFS.
The CASes above have been produced by many different AAEs with similar, but
slightly different type systems.
Jörn
Re: Ideas for UIMA v3
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 23.07.2015, at 19:17, Joern Kottmann <ko...@gmail.com> wrote:
>> If this is the scenario, another option would be to have the serialized CASes
>> stored along with a reference to their type system, and have some new
>> deserialization capability be able to locate the referred-to type system along
>> with the CAS to be read in. Would that "solve" this issue, or are there other
>> aspects?
https://issues.apache.org/jira/browse/UIMA-2127 ;)
But having the TS stored alongside the CAS also is nice - see below.
> It would probably solve it, but it is not a simple solution either. That
> would mean that the Type System get switched frequently and have be
> looked up all the time.
For DKPro Core, I have implemented a BinaryCasWriter that stores the type system in the same file as the binary serialized CAS. It is not always the best solution because it adds a fixed overhead to every file, but it is very convenient. Optionally, the type system can be stored externally in a separate file to avoid this overhead. If and how this typesystem can be used depends on which of the six kinds of binary serialization is being used. See [1] for an overview over these formats and their properties.
In the BinaryCasReader, depending on the type of serialization, either:
- there is a failure if the pipeline CAS typesystem is not compatible with the persisted CAS;
- the type system in the pipeline CAS is reinitialized from the persisted CAS;
- the data from the persisted CAS is loaded leniently, dropping all FSes that are not defined in the pipeline CAS typesystem
Furthermore, the BinaryCasReader auto-detects the binary format and loads it, be it the Java serialization-based format or one of the binary formats that Marschall recently created, or our extended format that also embeds the typesystem in the file.
Mind that depending on the use-case a different kind of serialization may be appropriate.
For me, this covers in particular the following use-cases:
- fast (de)serialization of the entire CAS
- compact binary format (some more some less)
- stable FS addresses (in some formats)
- restoring the pipeline CAS type system from file (i.e. CAS can be initialized with an empty type system on creation and TS is set by reader - in some formats)
- lenient loading of data allowing for different TSes on disk and in pipeline (in some formats)
Would such an approach cover (some of your) use-cases?
Cheers,
-- Richard
[1] http://www.dkpro.org/dkpro-core/releases/1.7.0/apidocs/index.html?de/tudarmstadt/ukp/dkpro/core/io/bincas/BinaryCasWriter.html
Re: Ideas for UIMA v3
Posted by Joern Kottmann <ko...@gmail.com>.
On Thu, 2015-07-23 at 11:01 -0400, Marshall Schor wrote:
> Hi Jörn,
>
> Thank you for your comments; I hope you can expand a bit (see below).
>
> On 7/23/2015 9:45 AM, Joern Kottmann wrote:
> > Well, I thought about something which can be done in 3, 4 or 5 lines of
> > code.
> >
> > To use a CAS, its first creating the TypeSystemDescriptor, creating an
> > empty CAS and then loading something into it.
> > Placing content in it is often done using an AE. If I want to reuse an
> > existing deserializer/serializer I always end up with an AE,
> > maybe there are some rare exceptions.
> >
> > In a bigger system there will be a couple of components dealing with CASes,
> > if there is a small change to the type system they all have to be updated,
> > even when they are not affected by the change, e.g. type addition or a
> > change to a type they don't use.
> I'd like to understand this better. Since the pipeline's final type system is
> created at pipeline-startup-time, from the "merge" of all the component's type
> systems, it seems to me that you would not need to update the type systems in
> other components not affected by the change?
I was not referring to UIMA components here.
Imagine a system that uses multiple AAEs to analyze some documents. The
documents might have really different types. The AAEs do a great job
adapting to the document types by using the right AEs to deal with the
content. An AE added to an AAE can also introduce new types. These new
types are merged into the type system of that particular AAE. The FS
added to the CAS having those types might be interesting later when
viewing that document, or for things that are specific to that
particular document, but not be important across the entire document
collection.
All the CASes outputted by these different AAEs have to be further
processed. And that is where things get tricky. The component dealing
with them is probably again very specific and might only want to look at
a few FeatureStructure types or maybe at all.
How can we write a mapreduce job that processes all CASes (with slightly
different but not incompatible type systems) in a database. Maybe
something as simple as the count of all Email Address Annotations in all
those CASes.
To be able to load that content into a CAS we either have to swap the
type system per cas type (not nice) or just merge all existing type
systems together.
If this type system in one of my AAEs now changes, e.g. type addition,
the mapred job also has to be updated with the new type system, even
tough it might never deal with that type.
Ok, that we can maybe somehow solve by stripping the unkown types from
the CASes.
> If the concern is the need to have a JCas cover class generated for the merged
> type system, version 3 is hoping to make that "automatic".
> > In our system we have many different
> > import pipelines, sometimes those pipelines have specific types which are
> > only used in an early stage, if a generic component has to deal with one of
> > those CASes the only good option is to merge all type systems together.
> Since UIMA pipelines do this type merge, I'm guessing you might be thinking
> about this outside of UIMA pipelines, such as a scenario where you have one step
> (using those many different import pipelines), and perhaps having those write
> out some CASs, and then wanting to read in those CASes in another step to be
> processed by your generic component, and therefore needing that 2nd step to have
> the merge of all the type systems together, to enable deserializing. Is this
> the scenario, or is there another use case you're thinking of?
Yes, but that generic component might have different requirements, maybe
it just deals with a few types it knows very well, or it can deal with
all types.
> If this is the scenario, another option would be to have the serialized CASes
> stored along with a reference to their type system, and have some new
> deserialization capability be able to locate the referred-to type system along
> with the CAS to be read in. Would that "solve" this issue, or are there other
> aspects?
It would probably solve it, but it is not a simple solution either. That
would mean that the Type System get switched frequently and have be
looked up all the time.
There is a CAS. It maybe contain, or doesn't contain FSes of a certain
type. The type is always known by the code dealing with the CAS.
Why do I first have to load the right type system to retrieve those
FSes?
With my CAS-like thing I can just write cas.getIndex("index37",
EmailAddressAnnotation.class) and it just returns them as Java objects
of type EmailAddressAnnotation.
There is no type system, and it doesn't work well with types I don't
know anything about, but at that place I am also not interested in
those.
In a different place in the system the code might only assume its an
annotation and retrieves the same index as objects of type AnnotationFS.
cas.getIndex("index37", AnnotationFS.class)
UIMA doesn't make it easy with its static type system to write generic
code working with CASes.
> >
> > The way we use UIMA is that we let it process our content with different
> > custom pipelines, and at the end of each pipeline the results are converted
> > into POJOs and those are written into a database, all code which follows
> > just uses the POJOs to process the data. My point is: If the CAS would be
> > in a better state we could just use it through out the entire application
> > instead of our CAS-like layer.
>
> In version 3, we're planning on storing the Feature Structures as just instances
> of their JCas Java Cover Objects, pretty close to POJOs. So maybe there's a good
> chance...
Do we just use POJOs or are they again generated from a type system?
Jörn
Re: Ideas for UIMA v3
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 23.07.2015, at 17:01, Marshall Schor <ms...@schor.com> wrote:
>> The way we use UIMA is that we let it process our content with different
>> custom pipelines, and at the end of each pipeline the results are converted
>> into POJOs and those are written into a database, all code which follows
>> just uses the POJOs to process the data. My point is: If the CAS would be
>> in a better state we could just use it through out the entire application
>> instead of our CAS-like layer.
>
> In version 3, we're planning on storing the Feature Structures as just instances
> of their JCas Java Cover Objects, pretty close to POJOs. So maybe there's a good
> chance...
You mean as "instances of Java Cover Objects" without "JCas", right?
I mean there should still be the possibility to work with the CAS without JCas objects, basically via the CAS interface, no? We shouldn't have to use some Java reflection and bean utils to work with JCas - and there was also one wish for a more schemaless CAS which contradicts only having a strongly typed JCas API.
Cheers,
-- Richard
Re: Ideas for UIMA v3
Posted by Marshall Schor <ms...@schor.com>.
Hi Jörn,
Thank you for your comments; I hope you can expand a bit (see below).
On 7/23/2015 9:45 AM, Joern Kottmann wrote:
> Well, I thought about something which can be done in 3, 4 or 5 lines of
> code.
>
> To use a CAS, its first creating the TypeSystemDescriptor, creating an
> empty CAS and then loading something into it.
> Placing content in it is often done using an AE. If I want to reuse an
> existing deserializer/serializer I always end up with an AE,
> maybe there are some rare exceptions.
>
> In a bigger system there will be a couple of components dealing with CASes,
> if there is a small change to the type system they all have to be updated,
> even when they are not affected by the change, e.g. type addition or a
> change to a type they don't use.
I'd like to understand this better. Since the pipeline's final type system is
created at pipeline-startup-time, from the "merge" of all the component's type
systems, it seems to me that you would not need to update the type systems in
other components not affected by the change?
If the concern is the need to have a JCas cover class generated for the merged
type system, version 3 is hoping to make that "automatic".
> In our system we have many different
> import pipelines, sometimes those pipelines have specific types which are
> only used in an early stage, if a generic component has to deal with one of
> those CASes the only good option is to merge all type systems together.
Since UIMA pipelines do this type merge, I'm guessing you might be thinking
about this outside of UIMA pipelines, such as a scenario where you have one step
(using those many different import pipelines), and perhaps having those write
out some CASs, and then wanting to read in those CASes in another step to be
processed by your generic component, and therefore needing that 2nd step to have
the merge of all the type systems together, to enable deserializing. Is this
the scenario, or is there another use case you're thinking of?
If this is the scenario, another option would be to have the serialized CASes
stored along with a reference to their type system, and have some new
deserialization capability be able to locate the referred-to type system along
with the CAS to be read in. Would that "solve" this issue, or are there other
aspects?
>
> The way we use UIMA is that we let it process our content with different
> custom pipelines, and at the end of each pipeline the results are converted
> into POJOs and those are written into a database, all code which follows
> just uses the POJOs to process the data. My point is: If the CAS would be
> in a better state we could just use it through out the entire application
> instead of our CAS-like layer.
In version 3, we're planning on storing the Feature Structures as just instances
of their JCas Java Cover Objects, pretty close to POJOs. So maybe there's a good
chance...
-Marshall
>
> Jörn
>
> On Thu, Jul 23, 2015 at 2:55 PM, Richard Eckart de Castilho <re...@apache.org>
> wrote:
>
>> On 23.07.2015, at 14:43, Joern Kottmann <ko...@gmail.com> wrote:
>>
>>> One thing which must have been overlooked when UIMA was built is that
>>> people (like me) have to write code which wants to interact with the CAS
>>> but can't be an AE. In UIMA the CAS (either in memory, or serialized)
>>> is difficult to
>>> be used without implementing an AE.
>> I'm not sure why you feel like that. E.g. in WebAnno (an annotation editor
>> that uses the CAS as its internal data model), create operate with the CAS
>> basically without any AEs. All editing operations are done directly on the
>> CAS which is loaded/saved directly using the UIMA API calls for binary
>> serialization.
>>
>> Basically, we are using the same API that we would be using in an AE, but
>> without
>> the AE/pipelining stuff. It doesn't get any more difficult without the AE
>> - in fact
>> some things become easier without AEs, readers, and consumers.
>>
>> I'm sure you must have something similar in the CAS Editor plugin in
>> Eclipse, no?
>>
>> -- Richard
Re: Ideas for UIMA v3
Posted by Joern Kottmann <ko...@gmail.com>.
Well, I thought about something which can be done in 3, 4 or 5 lines of
code.
To use a CAS, its first creating the TypeSystemDescriptor, creating an
empty CAS and then loading something into it.
Placing content in it is often done using an AE. If I want to reuse an
existing deserializer/serializer I always end up with an AE,
maybe there are some rare exceptions.
In a bigger system there will be a couple of components dealing with CASes,
if there is a small change to the type system they all have to be updated,
even when they are not affected by the change, e.g. type addition or a
change to a type they don't use. In our system we have many different
import pipelines, sometimes those pipelines have specific types which are
only used in an early stage, if a generic component has to deal with one of
those CASes the only good option is to merge all type systems together.
The way we use UIMA is that we let it process our content with different
custom pipelines, and at the end of each pipeline the results are converted
into POJOs and those are written into a database, all code which follows
just uses the POJOs to process the data. My point is: If the CAS would be
in a better state we could just use it through out the entire application
instead of our CAS-like layer.
Jörn
On Thu, Jul 23, 2015 at 2:55 PM, Richard Eckart de Castilho <re...@apache.org>
wrote:
> On 23.07.2015, at 14:43, Joern Kottmann <ko...@gmail.com> wrote:
>
> > One thing which must have been overlooked when UIMA was built is that
> > people (like me) have to write code which wants to interact with the CAS
> > but can't be an AE. In UIMA the CAS (either in memory, or serialized)
> > is difficult to
> > be used without implementing an AE.
>
> I'm not sure why you feel like that. E.g. in WebAnno (an annotation editor
> that uses the CAS as its internal data model), create operate with the CAS
> basically without any AEs. All editing operations are done directly on the
> CAS which is loaded/saved directly using the UIMA API calls for binary
> serialization.
>
> Basically, we are using the same API that we would be using in an AE, but
> without
> the AE/pipelining stuff. It doesn't get any more difficult without the AE
> - in fact
> some things become easier without AEs, readers, and consumers.
>
> I'm sure you must have something similar in the CAS Editor plugin in
> Eclipse, no?
>
> -- Richard
Re: Ideas for UIMA v3
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 23.07.2015, at 14:43, Joern Kottmann <ko...@gmail.com> wrote:
> One thing which must have been overlooked when UIMA was built is that
> people (like me) have to write code which wants to interact with the CAS
> but can't be an AE. In UIMA the CAS (either in memory, or serialized)
> is difficult to
> be used without implementing an AE.
I'm not sure why you feel like that. E.g. in WebAnno (an annotation editor
that uses the CAS as its internal data model), create operate with the CAS
basically without any AEs. All editing operations are done directly on the
CAS which is loaded/saved directly using the UIMA API calls for binary
serialization.
Basically, we are using the same API that we would be using in an AE, but without
the AE/pipelining stuff. It doesn't get any more difficult without the AE - in fact
some things become easier without AEs, readers, and consumers.
I'm sure you must have something similar in the CAS Editor plugin in Eclipse, no?
-- Richard
Re: Ideas for UIMA v3
Posted by Joern Kottmann <ko...@gmail.com>.
On Wed, 2015-06-24 at 14:31 +0200, Thilo Goetz wrote:
> > Marshall already did some nice work on JSON serialization, so I
> think there is movement into that direction.
>
> Just to be very clear: that is not good enough. I want a JSON format
> that I can read and write without the help of the framework. From my
> datastructures, into my datastructures. In some programming language
> that hasn't been invented yet. Simple enough that I don't need to
> absorb
> and reimplement the whole UIMA philosophy.
>
> >
> > But what I don't understand is how a data format resolves to "less
> framework". The data format is basically addressing ingestion and
> export, but not processing or pipelines. Even if you have a simple
> data format like JSON, there's still the need to run analysis, right?
> Is the analysis in your scenario just a black box? And in order to
> apply the analysis, you'll need some kind API - how do you imagine it?
>
> The analysis is a black box, yes. What else could it be? I don't care
> how the POS tagger does what it does. All I'm interested in is what
> it
> needs as input, and how it gives me the output. I can parse JSON into
> Java pojos with jackson for example, that's super simple. Writing
> them
> out is even easier. What APIs do I need other than being able to tell
> some piece of analysis to do its stuff on a bunch of data?
One thing which must have been overlooked when UIMA was built is that
people (like me) have to write code which wants to interact with the CAS
but can't be an AE. In UIMA the CAS (either in memory, or serialized)
is difficult to
be used without implementing an AE. In those scenarios you usually
have to deal with some kind
of serialized CAS anyway. Today, it is really easy to serialize a CAS
into XMI, but that format
is not trivial to deal with at all.
And if you would like to interact with it in a different programming
language the entry barrier is
so high that I have never seen it anywhere (except our C++ layer). It
is probably easier to build
something similar for that particular use case.
Here, JSON would really help to be more compatible with different environments.
Reading, modifying and adding objects to a JSON structure can be done
in most programming languages without much overhead (if the structure
is not too complex).
Sometimes there is even direct support for JSON, e.g. in ElasticSearch
or browsers.
And soon also in Java.
It should be much easier to serialize/deserialize a CAS.
The best practice today is to implement an AE to achieve that, but
that again is not
nice, when I don't want to deal with AEs.
An AE is great to add structure to a document. After that is done there
is often code which work on that structured data. That cold be a mapreduce
job that is counting the number of tokens in a document collection.
In those cases it would be really really nice to just create/deserialize a CAS
and program against the CAS instead of rebuilding the parts of it that
are needed, e.g. iterating Person annotations in the order in which
they occur in the text, only iterating tokens inside a sentence, etc.
The CAS is also not flexible enough when it gets to the really simple cases,
maybe I just want to process only one FeatureStructure per CAS with an
AE I already built.
Some of my AEs only work on higher level FSes, like a Person Entity.
Why is there so much overhead in creating a CAS with just one FS?
And today it is cumbersome to work with it in Java. The CAS interface
doesn't allow
me to use POJOs and JCas is too complex (e.g. code generation).
For UIMA v3 I really hope that we can rebuild the CAS so it is
something that was build today and
not 15 years ago.
Jörn
Re: Ideas for UIMA v3
Posted by Michael Tanenblatt <sl...@park-slope.net>.
I agree with Thilo here; if possible, this would be ideal, simplifying reuse and enabling a component/pipeline to be easily incorporated into systems that are not UIMA-based, e.g., a REST-based web server.
> On Jun 24, 2015, at 8:31 AM, Thilo Goetz <tw...@gmx.de> wrote:
>
> On 06/24/2015 12:30 PM, Richard Eckart de Castilho wrote:
>> On 24.06.2015, at 11:56, Thilo Goetz <tw...@gmx.de> wrote:
>>
>>>> Or would the issue be solvable by integrating uimaFIT into the core (e.g. to
>>>> avoid re-approval of libraries by company legal departments)?
>>>
>>> I am just speaking for myself here, but I don't want more framework, I want less. I don't want to have to use uimaFIT to help me deal with UIMA if I could have something that doesn't require that help. Give me a simple JSON based data format and I'll be happy.
>>>
>>> I know this is selfish, but unless the discussion is seriously moving in that direction, I'm simply not interested :)
>>
>> Fair enough.
>>
>> Marshall already did some nice work on JSON serialization, so I think there is movement into that direction.
>
> Just to be very clear: that is not good enough. I want a JSON format that I can read and write without the help of the framework. From my datastructures, into my datastructures. In some programming language that hasn't been invented yet. Simple enough that I don't need to absorb and reimplement the whole UIMA philosophy.
>
>>
>> But what I don't understand is how a data format resolves to "less framework". The data format is basically addressing ingestion and export, but not processing or pipelines. Even if you have a simple data format like JSON, there's still the need to run analysis, right? Is the analysis in your scenario just a black box? And in order to apply the analysis, you'll need some kind API - how do you imagine it?
>
> The analysis is a black box, yes. What else could it be? I don't care how the POS tagger does what it does. All I'm interested in is what it needs as input, and how it gives me the output. I can parse JSON into Java pojos with jackson for example, that's super simple. Writing them out is even easier. What APIs do I need other than being able to tell some piece of analysis to do its stuff on a bunch of data?
>
> I am painting things black and white here. I certainly see that some convenience APIs can be useful. The import thing for me though is that they are just that: a convenience. If the basic definition is the data format, than other things like APIs can be stacked on top of that. But if I want to work with the data directly, then I can do that without having to jump through hoops.
>
> --Thilo
>
>>
>> Cheers,
>>
>> -- Richard
>>
>
Re: Ideas for UIMA v3
Posted by Thilo Goetz <tw...@gmx.de>.
On 06/24/2015 12:30 PM, Richard Eckart de Castilho wrote:
> On 24.06.2015, at 11:56, Thilo Goetz <tw...@gmx.de> wrote:
>
>>> Or would the issue be solvable by integrating uimaFIT into the core (e.g. to
>>> avoid re-approval of libraries by company legal departments)?
>>
>> I am just speaking for myself here, but I don't want more framework, I want less. I don't want to have to use uimaFIT to help me deal with UIMA if I could have something that doesn't require that help. Give me a simple JSON based data format and I'll be happy.
>>
>> I know this is selfish, but unless the discussion is seriously moving in that direction, I'm simply not interested :)
>
> Fair enough.
>
> Marshall already did some nice work on JSON serialization, so I think there is movement into that direction.
Just to be very clear: that is not good enough. I want a JSON format
that I can read and write without the help of the framework. From my
datastructures, into my datastructures. In some programming language
that hasn't been invented yet. Simple enough that I don't need to absorb
and reimplement the whole UIMA philosophy.
>
> But what I don't understand is how a data format resolves to "less framework". The data format is basically addressing ingestion and export, but not processing or pipelines. Even if you have a simple data format like JSON, there's still the need to run analysis, right? Is the analysis in your scenario just a black box? And in order to apply the analysis, you'll need some kind API - how do you imagine it?
The analysis is a black box, yes. What else could it be? I don't care
how the POS tagger does what it does. All I'm interested in is what it
needs as input, and how it gives me the output. I can parse JSON into
Java pojos with jackson for example, that's super simple. Writing them
out is even easier. What APIs do I need other than being able to tell
some piece of analysis to do its stuff on a bunch of data?
I am painting things black and white here. I certainly see that some
convenience APIs can be useful. The import thing for me though is that
they are just that: a convenience. If the basic definition is the data
format, than other things like APIs can be stacked on top of that. But
if I want to work with the data directly, then I can do that without
having to jump through hoops.
--Thilo
>
> Cheers,
>
> -- Richard
>
Re: Ideas for UIMA v3
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 24.06.2015, at 11:56, Thilo Goetz <tw...@gmx.de> wrote:
>> Or would the issue be solvable by integrating uimaFIT into the core (e.g. to
>> avoid re-approval of libraries by company legal departments)?
>
> I am just speaking for myself here, but I don't want more framework, I want less. I don't want to have to use uimaFIT to help me deal with UIMA if I could have something that doesn't require that help. Give me a simple JSON based data format and I'll be happy.
>
> I know this is selfish, but unless the discussion is seriously moving in that direction, I'm simply not interested :)
Fair enough.
Marshall already did some nice work on JSON serialization, so I think there is movement into that direction.
But what I don't understand is how a data format resolves to "less framework". The data format is basically addressing ingestion and export, but not processing or pipelines. Even if you have a simple data format like JSON, there's still the need to run analysis, right? Is the analysis in your scenario just a black box? And in order to apply the analysis, you'll need some kind API - how do you imagine it?
Cheers,
-- Richard
Re: Ideas for UIMA v3
Posted by Thilo Goetz <tw...@gmx.de>.
On 06/24/2015 09:12 AM, Richard Eckart de Castilho wrote:
[...]
> Just for the sake of knowing where this is going, assuming the UIMA core API
> as a baseline and the uimaFIT API as an improvement, how would this further
> improvement look like?
>
> Or would the issue be solvable by integrating uimaFIT into the core (e.g. to
> avoid re-approval of libraries by company legal departments)?
I am just speaking for myself here, but I don't want more framework, I
want less. I don't want to have to use uimaFIT to help me deal with UIMA
if I could have something that doesn't require that help. Give me a
simple JSON based data format and I'll be happy.
I know this is selfish, but unless the discussion is seriously moving in
that direction, I'm simply not interested :)
--Thilo
>
> Cheers,
>
> -- Richard
>
Re: Ideas for UIMA v3
Posted by Scott Cyphers <sr...@gmail.com>.
Hi,
I have been skimming this thread while on vacation. Before vacation, I started writing up a statically typed approach I developed that could deal with large vectors, and multi-sofa analysis, like DkPro’s features, and no need for a separate type system. I was going to finish next week and get some feedback from a couple UIMA users I know, but it looks like it could be relevant to this discussion so here it is in raw and unfinished form:
http://people.csail.mit.edu/cyphers/uima/xcas.pdf <http://people.csail.mit.edu/cyphers/uima/xcas.pdf>
The implementation is quite simple and I can release it as BSD. I am in the keeping frameworks minimal and interoperable with other frameworks camp. Unfortunately, this is about the limit of my participation until next week.
Scott
> On Jun 24, 2015, at 9:46 AM, Marshall Schor <ms...@schor.com> wrote:
>
> On 6/24/2015 3:12 AM, Richard Eckart de Castilho wrote:
>> On 23.06.2015, at 17:11, Marshall Schor <ms...@schor.com> wrote:
>>
>>> I added a wiki page to develop the ideas here.
>>>
>>> This is what I got from reading this:
>>>
>>> One idea is having an annotator not have a type system specification, but rather
>>> have it dynamically create types / features according to some configuration info
>>> or some dynamically-obtained information (perhaps the results of some previous
>>> analysis).
>> I think that right now, an annotator doesn't need to have a type system specification.
> This seems true, especially for "generic" kinds of annotators that aren't tied
> to particular types/features.
> Those annotators have the ability to query the TypeSystem and we have APIs that
> use indirection in specifying both types and features.
> That is, instead of saying
> instance_of_annotation.setBegin(123), where instance_of_annotation is
> statically typed to be a (subtype of) annotation, and the begin feature is
> hard-coded directly into the code via "setBegin", you could write
> someFS.setIntFeature(someIndirectionToAfeature, 123), where someFS could be
> typed as a generic FeatureStructure, and someIndirectToAfeature could be of the
> generic type Feature, and set to the particular feature elsewhere.
>
> This indirection has pros and cons; the pros: enables generic annotators where
> the types and features are not explicit in the code. cons: when the types and
> features are known, then the annotator code can be easier to read, as it has
> less indirection. Also there can be performance / space issues with indirection.
>
>> The specification is necessary to create a CAS, but not to create an annotator.
>> With uimaFIT, it is common to first create a CAS (based on types automatically
>> detected in the classpath), then fill that CAS with some initial information
>> (avoiding a reader for easy embedding into an application), and then to pass
>> that CAS through an aggregate. While uimaFIT also adds the automatically detected
>> types to every analysis engine description in the aggregate, I believe this
>> is not really necessary because the CAS has already been initialized.
>>
>> Independent from that is the problem that the type system is locked after the
>> CAS has been created. Engines such as Ruta would profit if the type system would
>> at least allow compatible changes such as adding new types or adding new features
>> to existing types. The types may not be known at the time the CAS is initialized,
>> but only when the CAS is actually being processed.
> Some languages (Ruby, Javascript) allow dynamic modification of classes. So new
> types can be defined, and new features can be added to classes.
> In fact, I found this web article which lists a very long list of languages
> (Java not among them) where fields can be added to a class at runtime:
> http://rosettacode.org/wiki/Add_a_variable_to_a_class_instance_at_runtime <http://rosettacode.org/wiki/Add_a_variable_to_a_class_instance_at_runtime>
>
> In Java, you can add classes at runtime; but modifying existing classes (to add
> additional fields) is not supported.
> UIMA's current design (where Java is optional) might be able to be extended to
> support new types and additional fields, at some cost in performance/space.
> The recently proposed cas-object design could also partially support this I
> think. (It couldn't support 1) create a FS with 3 types, 2) add feature # 4, 3)
> set feature # 4 in the already created FS). More dynamic data structures of
> course do support this idea of dynamically extensible Types.
>
> Other alternative JCas approaches which generate a full JCas cover class
> automatically from the merged type systems, would also have problems with adding
> features to existing Types, but could define dynamic new types.
>
> Finally, we could modify the Java cover class design to support a hybrid - those
> things known ahead could be statically typed, and those things added dynamically
> could be handled with more flexible augmentations embedded into the generated
> class; maybe this allows the best of both worlds.
>
> The usual pros/cons apply.
>>> Another idea is having an annotator be able to read Feature Structure data from
>>> a wide variety of sources, and have the data include the type/feature metadata
>>> (either externally - as we do now in UIMA with a type system external XML
>>> specification, or embedded - like JSON would naturally do). Such an annotator
>>> would have some notion of the type / feature information it was interested in
>>> processing, but could ignore the rest.
>> Let's see...
>>
>> a) easier ingestion of data into feature structures, optimally by automatically
>> creating FSes based on a (typed) external data description. E.g. a JSON object
>> like
>>
>> { "fs1": {"feature1": "value1", "feature2": 10 }
>>
>> would be converted to a FS with a string feature1 and a numeric feature2.
>> However, the type of the FS would basically be underspecified in the type
>> system as the next feature structure read could have the same features
>> using different value ranges and in fact the type of the FS itself is
>> unknown. Sounds as if heading towards some kind of duck-typing e.g. for
>> annotations (if it has a begin/end, then it is an annotation).
> An interesting thing to observe is that in this direction of "simplicity", the
> ideas of Views and Sofas and Indexes might be optional?
> A thought experiment: is there a decomposition for UIMA facilities that can omit
> these kinds of things if not "needed", yet gradually include this functionality
> for more complex implementations?
>
>>
>> b) the part about the type/feature information that an annotator is interested
>> in but being able to ignore the rest I didn't get.
> This is the concept (already present in the way UIMA deserializers operate for
> remote annotators) that when reading an external representation, you don't have
> to be able to handle all the types and features. You can "ignore" those you
> don't recognize, and just work with those you're interested in.
>>
>>> Finally, a third idea is to have the componentization be such that no "UIMA
>>> Framework" was needed, or if present, it's hidden. I'm thinking that this
>>> means, for simpler analytics, the idea of a pipe line, and combining things,
>>> would not be present; it would be more like just a single annotator. For more
>>> complex things, the idea of a pipeline would be encapsulated (like UIMA's
>>> Aggregates), and the whole thing would look like something that could be
>>> embedded, in any of the other "big data" frameworks as an analysis piece. The
>>> implication is that this would enable using other frameworks' scaleout mechanisms.
>> uimaFIT goes a long way in "hiding" the bulk of the UIMA framework and
>> providing a rather sane Java API for pipelines. It makes the creation of a POJO
>> wrapper around them a breeze. People do use this to embed UIMA in alternative
>> scale-out frameworks such as Hadoop.
>>
>> Just for the sake of knowing where this is going, assuming the UIMA core API
>> as a baseline and the uimaFIT API as an improvement, how would this further
>> improvement look like?
> It might look like some kind of layering, stripping out complexity (until
> needed). (See thought experiment, above).
>>
>>
>> Or would the issue be solvable by integrating uimaFIT into the core (e.g. to
>> avoid re-approval of libraries by company legal departments)?
> I don't this integration solves this issue, but integrating uimaFIT into the
> core seems like a good thing to work on (it's an item in the v3 wiki page).
>
> -Marshall
Re: Ideas for UIMA v3
Posted by Marshall Schor <ms...@schor.com>.
On 6/24/2015 3:12 AM, Richard Eckart de Castilho wrote:
> On 23.06.2015, at 17:11, Marshall Schor <ms...@schor.com> wrote:
>
>> I added a wiki page to develop the ideas here.
>>
>> This is what I got from reading this:
>>
>> One idea is having an annotator not have a type system specification, but rather
>> have it dynamically create types / features according to some configuration info
>> or some dynamically-obtained information (perhaps the results of some previous
>> analysis).
> I think that right now, an annotator doesn't need to have a type system specification.
This seems true, especially for "generic" kinds of annotators that aren't tied
to particular types/features.
Those annotators have the ability to query the TypeSystem and we have APIs that
use indirection in specifying both types and features.
That is, instead of saying
instance_of_annotation.setBegin(123), where instance_of_annotation is
statically typed to be a (subtype of) annotation, and the begin feature is
hard-coded directly into the code via "setBegin", you could write
someFS.setIntFeature(someIndirectionToAfeature, 123), where someFS could be
typed as a generic FeatureStructure, and someIndirectToAfeature could be of the
generic type Feature, and set to the particular feature elsewhere.
This indirection has pros and cons; the pros: enables generic annotators where
the types and features are not explicit in the code. cons: when the types and
features are known, then the annotator code can be easier to read, as it has
less indirection. Also there can be performance / space issues with indirection.
> The specification is necessary to create a CAS, but not to create an annotator.
> With uimaFIT, it is common to first create a CAS (based on types automatically
> detected in the classpath), then fill that CAS with some initial information
> (avoiding a reader for easy embedding into an application), and then to pass
> that CAS through an aggregate. While uimaFIT also adds the automatically detected
> types to every analysis engine description in the aggregate, I believe this
> is not really necessary because the CAS has already been initialized.
>
> Independent from that is the problem that the type system is locked after the
> CAS has been created. Engines such as Ruta would profit if the type system would
> at least allow compatible changes such as adding new types or adding new features
> to existing types. The types may not be known at the time the CAS is initialized,
> but only when the CAS is actually being processed.
Some languages (Ruby, Javascript) allow dynamic modification of classes. So new
types can be defined, and new features can be added to classes.
In fact, I found this web article which lists a very long list of languages
(Java not among them) where fields can be added to a class at runtime:
http://rosettacode.org/wiki/Add_a_variable_to_a_class_instance_at_runtime
In Java, you can add classes at runtime; but modifying existing classes (to add
additional fields) is not supported.
UIMA's current design (where Java is optional) might be able to be extended to
support new types and additional fields, at some cost in performance/space.
The recently proposed cas-object design could also partially support this I
think. (It couldn't support 1) create a FS with 3 types, 2) add feature # 4, 3)
set feature # 4 in the already created FS). More dynamic data structures of
course do support this idea of dynamically extensible Types.
Other alternative JCas approaches which generate a full JCas cover class
automatically from the merged type systems, would also have problems with adding
features to existing Types, but could define dynamic new types.
Finally, we could modify the Java cover class design to support a hybrid - those
things known ahead could be statically typed, and those things added dynamically
could be handled with more flexible augmentations embedded into the generated
class; maybe this allows the best of both worlds.
The usual pros/cons apply.
>> Another idea is having an annotator be able to read Feature Structure data from
>> a wide variety of sources, and have the data include the type/feature metadata
>> (either externally - as we do now in UIMA with a type system external XML
>> specification, or embedded - like JSON would naturally do). Such an annotator
>> would have some notion of the type / feature information it was interested in
>> processing, but could ignore the rest.
> Let's see...
>
> a) easier ingestion of data into feature structures, optimally by automatically
> creating FSes based on a (typed) external data description. E.g. a JSON object
> like
>
> { "fs1": {"feature1": "value1", "feature2": 10 }
>
> would be converted to a FS with a string feature1 and a numeric feature2.
> However, the type of the FS would basically be underspecified in the type
> system as the next feature structure read could have the same features
> using different value ranges and in fact the type of the FS itself is
> unknown. Sounds as if heading towards some kind of duck-typing e.g. for
> annotations (if it has a begin/end, then it is an annotation).
An interesting thing to observe is that in this direction of "simplicity", the
ideas of Views and Sofas and Indexes might be optional?
A thought experiment: is there a decomposition for UIMA facilities that can omit
these kinds of things if not "needed", yet gradually include this functionality
for more complex implementations?
>
> b) the part about the type/feature information that an annotator is interested
> in but being able to ignore the rest I didn't get.
This is the concept (already present in the way UIMA deserializers operate for
remote annotators) that when reading an external representation, you don't have
to be able to handle all the types and features. You can "ignore" those you
don't recognize, and just work with those you're interested in.
>
>> Finally, a third idea is to have the componentization be such that no "UIMA
>> Framework" was needed, or if present, it's hidden. I'm thinking that this
>> means, for simpler analytics, the idea of a pipe line, and combining things,
>> would not be present; it would be more like just a single annotator. For more
>> complex things, the idea of a pipeline would be encapsulated (like UIMA's
>> Aggregates), and the whole thing would look like something that could be
>> embedded, in any of the other "big data" frameworks as an analysis piece. The
>> implication is that this would enable using other frameworks' scaleout mechanisms.
> uimaFIT goes a long way in "hiding" the bulk of the UIMA framework and
> providing a rather sane Java API for pipelines. It makes the creation of a POJO
> wrapper around them a breeze. People do use this to embed UIMA in alternative
> scale-out frameworks such as Hadoop.
>
> Just for the sake of knowing where this is going, assuming the UIMA core API
> as a baseline and the uimaFIT API as an improvement, how would this further
> improvement look like?
It might look like some kind of layering, stripping out complexity (until
needed). (See thought experiment, above).
>
>
> Or would the issue be solvable by integrating uimaFIT into the core (e.g. to
> avoid re-approval of libraries by company legal departments)?
I don't this integration solves this issue, but integrating uimaFIT into the
core seems like a good thing to work on (it's an item in the v3 wiki page).
-Marshall
Re: Ideas for UIMA v3
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 23.06.2015, at 17:11, Marshall Schor <ms...@schor.com> wrote:
> I added a wiki page to develop the ideas here.
>
> This is what I got from reading this:
>
> One idea is having an annotator not have a type system specification, but rather
> have it dynamically create types / features according to some configuration info
> or some dynamically-obtained information (perhaps the results of some previous
> analysis).
I think that right now, an annotator doesn't need to have a type system specification.
The specification is necessary to create a CAS, but not to create an annotator.
With uimaFIT, it is common to first create a CAS (based on types automatically
detected in the classpath), then fill that CAS with some initial information
(avoiding a reader for easy embedding into an application), and then to pass
that CAS through an aggregate. While uimaFIT also adds the automatically detected
types to every analysis engine description in the aggregate, I believe this
is not really necessary because the CAS has already been initialized.
Independent from that is the problem that the type system is locked after the
CAS has been created. Engines such as Ruta would profit if the type system would
at least allow compatible changes such as adding new types or adding new features
to existing types. The types may not be known at the time the CAS is initialized,
but only when the CAS is actually being processed.
> Another idea is having an annotator be able to read Feature Structure data from
> a wide variety of sources, and have the data include the type/feature metadata
> (either externally - as we do now in UIMA with a type system external XML
> specification, or embedded - like JSON would naturally do). Such an annotator
> would have some notion of the type / feature information it was interested in
> processing, but could ignore the rest.
Let's see...
a) easier ingestion of data into feature structures, optimally by automatically
creating FSes based on a (typed) external data description. E.g. a JSON object
like
{ "fs1": {"feature1": "value1", "feature2": 10 }
would be converted to a FS with a string feature1 and a numeric feature2.
However, the type of the FS would basically be underspecified in the type
system as the next feature structure read could have the same features
using different value ranges and in fact the type of the FS itself is
unknown. Sounds as if heading towards some kind of duck-typing e.g. for
annotations (if it has a begin/end, then it is an annotation).
b) the part about the type/feature information that an annotator is interested
in but being able to ignore the rest I didn't get.
> Finally, a third idea is to have the componentization be such that no "UIMA
> Framework" was needed, or if present, it's hidden. I'm thinking that this
> means, for simpler analytics, the idea of a pipe line, and combining things,
> would not be present; it would be more like just a single annotator. For more
> complex things, the idea of a pipeline would be encapsulated (like UIMA's
> Aggregates), and the whole thing would look like something that could be
> embedded, in any of the other "big data" frameworks as an analysis piece. The
> implication is that this would enable using other frameworks' scaleout mechanisms.
uimaFIT goes a long way in "hiding" the bulk of the UIMA framework and
providing a rather sane Java API for pipelines. It makes the creation of a POJO
wrapper around them a breeze. People do use this to embed UIMA in alternative
scale-out frameworks such as Hadoop.
Just for the sake of knowing where this is going, assuming the UIMA core API
as a baseline and the uimaFIT API as an improvement, how would this further
improvement look like?
Or would the issue be solvable by integrating uimaFIT into the core (e.g. to
avoid re-approval of libraries by company legal departments)?
Cheers,
-- Richard
Re: Ideas for UIMA v3
Posted by Marshall Schor <ms...@schor.com>.
I added a wiki page to develop the ideas here.
This is what I got from reading this:
One idea is having an annotator not have a type system specification, but rather
have it dynamically create types / features according to some configuration info
or some dynamically-obtained information (perhaps the results of some previous
analysis).
Another idea is having an annotator be able to read Feature Structure data from
a wide variety of sources, and have the data include the type/feature metadata
(either externally - as we do now in UIMA with a type system external XML
specification, or embedded - like JSON would naturally do). Such an annotator
would have some notion of the type / feature information it was interested in
processing, but could ignore the rest.
Finally, a third idea is to have the componentization be such that no "UIMA
Framework" was needed, or if present, it's hidden. I'm thinking that this
means, for simpler analytics, the idea of a pipe line, and combining things,
would not be present; it would be more like just a single annotator. For more
complex things, the idea of a pipeline would be encapsulated (like UIMA's
Aggregates), and the whole thing would look like something that could be
embedded, in any of the other "big data" frameworks as an analysis piece. The
implication is that this would enable using other frameworks' scaleout mechanisms.
Does this capture the ideas? Please fill what I may have missed :-)
-Marshall
On 6/23/2015 9:03 AM, Thilo Goetz wrote:
> On 06/22/2015 06:23 PM, Marshall Schor wrote:
>> In reading this paper, it seems one of the key ideas is "dynamic typing". There
>> seems to be multiple aspects to this, including type "adapters" of various
>> kinds, to enable more-easily fitting together independently developed
>> components. I also get the sense that making things "easy" for developers is a
>> value that dynamic typing provides. Are you thinking here of the Javascript
>> style of typing values as "var" instead of specific static types?
>>
>> If dynamic typing means something beyond getting independently - developed
>> components' type systems to work together "easily", can you give a couple of use
>> cases of what the dream is here?
>
> That would be a good start. Beyond that, think about what we call generic
> annotators, i.e., annotators that take a spec as input (e.g., a bunch of regex
> rules) and produce annotations or other data as output. The data types that
> the generic annotator produces varies with the spec, and so it can't have a
> static, external type system. It might produce tokens with one spec, sentences
> with another, and person names with a third.
>
> Also, and I can't stress this enough, I want to be able to communicate with
> annotators just at the level of the data. I want to be able to read data from
> files, or from network streams. I want to read from Kafka or sequence files in
> HDFS. And I want to be able to do that without having to know the precise type
> system that the data was written with. And I want to be able to do this in
> Python or Go if I feel like it, so there must be no framework dependency.
> Think JSON.
>
> Of course I need to know a thing or two about the data format, otherwise the
> data is not very useful. However, if I just need the tokens, I don't want to
> have to know all the rest, and I'd like this to be a lot easier than it is now
> in UIMA.
>
>>
>> I put some concepts into the wiki-page; feel free to correct/augment etc.
>>
>> Thanks! -Marshall
>>
>> On 6/22/2015 5:30 AM, Thilo Goetz wrote:
>>> Let me throw last year's dream into the ring then:
>>> http://aclweb.org/anthology/W14-5209
>>>
>>> --Thilo
>>>
>>> On 06/18/2015 04:41 PM, Marshall Schor wrote:
>>>> I've put up another wiki page as a place to collect ideas for UIMA version 3.
>>>>
>>>> It's a place to dream a bit. It goes with the earlier page,
>>>> https://cwiki.apache.org/confluence/display/UIMA/Modernizing+the+internals+of+UIMA
>>>>
>>>> .
>>>>
>>>> Feel free to contribute, of course!
>>>>
>>>> The page is linked from the above page, but here's the direct link:
>>>> https://cwiki.apache.org/confluence/display/UIMA/Ideas+for+UIMAJ+v3
>>>>
>>>> -Marshall
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Re: Ideas for UIMA v3
Posted by Thilo Goetz <tw...@gmx.de>.
On 06/22/2015 06:23 PM, Marshall Schor wrote:
> In reading this paper, it seems one of the key ideas is "dynamic typing". There
> seems to be multiple aspects to this, including type "adapters" of various
> kinds, to enable more-easily fitting together independently developed
> components. I also get the sense that making things "easy" for developers is a
> value that dynamic typing provides. Are you thinking here of the Javascript
> style of typing values as "var" instead of specific static types?
>
> If dynamic typing means something beyond getting independently - developed
> components' type systems to work together "easily", can you give a couple of use
> cases of what the dream is here?
That would be a good start. Beyond that, think about what we call
generic annotators, i.e., annotators that take a spec as input (e.g., a
bunch of regex rules) and produce annotations or other data as output.
The data types that the generic annotator produces varies with the spec,
and so it can't have a static, external type system. It might produce
tokens with one spec, sentences with another, and person names with a third.
Also, and I can't stress this enough, I want to be able to communicate
with annotators just at the level of the data. I want to be able to read
data from files, or from network streams. I want to read from Kafka or
sequence files in HDFS. And I want to be able to do that without having
to know the precise type system that the data was written with. And I
want to be able to do this in Python or Go if I feel like it, so there
must be no framework dependency. Think JSON.
Of course I need to know a thing or two about the data format, otherwise
the data is not very useful. However, if I just need the tokens, I don't
want to have to know all the rest, and I'd like this to be a lot easier
than it is now in UIMA.
>
> I put some concepts into the wiki-page; feel free to correct/augment etc.
>
> Thanks! -Marshall
>
> On 6/22/2015 5:30 AM, Thilo Goetz wrote:
>> Let me throw last year's dream into the ring then:
>> http://aclweb.org/anthology/W14-5209
>>
>> --Thilo
>>
>> On 06/18/2015 04:41 PM, Marshall Schor wrote:
>>> I've put up another wiki page as a place to collect ideas for UIMA version 3.
>>>
>>> It's a place to dream a bit. It goes with the earlier page,
>>> https://cwiki.apache.org/confluence/display/UIMA/Modernizing+the+internals+of+UIMA
>>> .
>>>
>>> Feel free to contribute, of course!
>>>
>>> The page is linked from the above page, but here's the direct link:
>>> https://cwiki.apache.org/confluence/display/UIMA/Ideas+for+UIMAJ+v3
>>>
>>> -Marshall
>>>
>>>
>>>
>>>
>>
>>
>
Re: Ideas for UIMA v3
Posted by Marshall Schor <ms...@schor.com>.
In reading this paper, it seems one of the key ideas is "dynamic typing". There
seems to be multiple aspects to this, including type "adapters" of various
kinds, to enable more-easily fitting together independently developed
components. I also get the sense that making things "easy" for developers is a
value that dynamic typing provides. Are you thinking here of the Javascript
style of typing values as "var" instead of specific static types?
If dynamic typing means something beyond getting independently - developed
components' type systems to work together "easily", can you give a couple of use
cases of what the dream is here?
I put some concepts into the wiki-page; feel free to correct/augment etc.
Thanks! -Marshall
On 6/22/2015 5:30 AM, Thilo Goetz wrote:
> Let me throw last year's dream into the ring then:
> http://aclweb.org/anthology/W14-5209
>
> --Thilo
>
> On 06/18/2015 04:41 PM, Marshall Schor wrote:
>> I've put up another wiki page as a place to collect ideas for UIMA version 3.
>>
>> It's a place to dream a bit. It goes with the earlier page,
>> https://cwiki.apache.org/confluence/display/UIMA/Modernizing+the+internals+of+UIMA
>> .
>>
>> Feel free to contribute, of course!
>>
>> The page is linked from the above page, but here's the direct link:
>> https://cwiki.apache.org/confluence/display/UIMA/Ideas+for+UIMAJ+v3
>>
>> -Marshall
>>
>>
>>
>>
>
>
Re: Ideas for UIMA v3
Posted by Marshall Schor <ms...@schor.com>.
Thanks! - giving it a good read :-)
-Marshall
On 6/22/2015 5:30 AM, Thilo Goetz wrote:
> Let me throw last year's dream into the ring then:
> http://aclweb.org/anthology/W14-5209
>
> --Thilo
>
> On 06/18/2015 04:41 PM, Marshall Schor wrote:
>> I've put up another wiki page as a place to collect ideas for UIMA version 3.
>>
>> It's a place to dream a bit. It goes with the earlier page,
>> https://cwiki.apache.org/confluence/display/UIMA/Modernizing+the+internals+of+UIMA
>> .
>>
>> Feel free to contribute, of course!
>>
>> The page is linked from the above page, but here's the direct link:
>> https://cwiki.apache.org/confluence/display/UIMA/Ideas+for+UIMAJ+v3
>>
>> -Marshall
>>
>>
>>
>>
>
>
Re: Ideas for UIMA v3
Posted by Thilo Goetz <tw...@gmx.de>.
Let me throw last year's dream into the ring then:
http://aclweb.org/anthology/W14-5209
--Thilo
On 06/18/2015 04:41 PM, Marshall Schor wrote:
> I've put up another wiki page as a place to collect ideas for UIMA version 3.
>
> It's a place to dream a bit. It goes with the earlier page,
> https://cwiki.apache.org/confluence/display/UIMA/Modernizing+the+internals+of+UIMA .
>
> Feel free to contribute, of course!
>
> The page is linked from the above page, but here's the direct link:
> https://cwiki.apache.org/confluence/display/UIMA/Ideas+for+UIMAJ+v3
>
> -Marshall
>
>
>
>
Re: Ideas for UIMA v3
Posted by Richard Eckart de Castilho <re...@apache.org>.
For creating issues for a dreamy UIMA v3, we might use this Jira version for now:
https://issues.apache.org/jira/browse/UIMA/fixforversion/12324876
We could also rename it to "3.0.0SDK" and instead turn the incompatibility "flag"
into a label.
-- Richard
On 18.06.2015, at 17:41, Marshall Schor <ms...@schor.com> wrote:
> I've put up another wiki page as a place to collect ideas for UIMA version 3.
>
> It's a place to dream a bit. It goes with the earlier page,
> https://cwiki.apache.org/confluence/display/UIMA/Modernizing+the+internals+of+UIMA .
>
> Feel free to contribute, of course!
>
> The page is linked from the above page, but here's the direct link:
> https://cwiki.apache.org/confluence/display/UIMA/Ideas+for+UIMAJ+v3
>
> -Marshall
Re: Ideas for UIMA v3
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 24.07.2015, at 15:24, Joern Kottmann <ko...@gmail.com> wrote:
> Maybe like this:
> cas.setField("confidence", 0.78f);
> Float confidence = cas.getField("confidence", Float.class);
That is a great idea - although I'd personally like to see it at the level of FSes ;)
https://issues.apache.org/jira/browse/UIMA-4536
That should greatly simplify interacting with the CAS through the CAS (not JCas) API!
Some examples:
// Different ways of setting a value
setFeature(fs, "BooleanArrayValue", true);
setFeature(fs, "BooleanArrayValue", true, false);
setFeature(fs, "BooleanArrayValue", new boolean[] { true, false });
setFeature(fs, "BooleanArrayValue", asList(true, false));
// Different ways of getting a value
assertEquals(true, getFeature(fs, "BooleanArrayValue", List.class).get(0));
assertEquals(false, getFeature(fs, "BooleanArrayValue", List.class).get(1));
assertEquals(true, getFeature(fs, "BooleanArrayValue", boolean[].class)[0]);
assertEquals(false, getFeature(fs, "BooleanArrayValue", boolean[].class)[1]);
I've had some of this in WebAnno already, but having this in uimaFIT (and eventually in uimaj-core) in a more comprehensive way makes much more sense.
Cheers,
-- Richard
Re: Ideas for UIMA v3
Posted by Joern Kottmann <ko...@gmail.com>.
Quite a while back there was some work done towards variables/fields on the
CAS level.
Does it make sense to put that directly into the CAS interface?
It would be nice to have support for primitive and FS fields.
I know that it is possible with the current design by creating a FS type
for each field, but that results in a couple of lines of code to write and
access a field. Maybe we can come up with something that takes only one
line of code to set or access a field.
Maybe like this:
cas.setField("confidence", 0.78f);
Float confidence = cas.getField("confidence", Float.class);
Jörn
On Thu, Jun 18, 2015 at 4:41 PM, Marshall Schor <ms...@schor.com> wrote:
> I've put up another wiki page as a place to collect ideas for UIMA version
> 3.
>
> It's a place to dream a bit. It goes with the earlier page,
>
> https://cwiki.apache.org/confluence/display/UIMA/Modernizing+the+internals+of+UIMA
> .
>
> Feel free to contribute, of course!
>
> The page is linked from the above page, but here's the direct link:
> https://cwiki.apache.org/confluence/display/UIMA/Ideas+for+UIMAJ+v3
>
> -Marshall
>
>
>
>
>