You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org> on 2006/12/08 16:29:22 UTC
[jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Always deliver the base CAS to the process method
-------------------------------------------------
Key: UIMA-116
URL: http://issues.apache.org/jira/browse/UIMA-116
Project: UIMA
Issue Type: Improvement
Components: Core Java Framework
Affects Versions: 2.1
Environment: UIMA components
Reporter: Eddie Epstein
Fix For: 2.1
Currently there is a distinction made for "single view" and "multiple view" components. The UIMA architecture standard proposes that all components are multiple view components and be delivered a handle to the base CAS, and the component retrieves views as required. The change to existing "single view" component would be to add one line of code in the process method: cas = passInCas.getView(), which would return the View currently given to these components as determined by Sofa mapping.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/9/06, Marshall Schor <ms...@schor.com> wrote:
> If we go with a model of delivering a "base-CAS" to annotators, what
> methods besides "getView()" are available on this object?
>
> If only getView() is, perhaps we should define this object to be a
> "view-getter", not a base-CAS, since it doesn't share very much
> with the CAS APIs.
>
A CAS is defined as the structure that contains the analysis results,
and which contains one or more views. So I believe this is the
appropriate name for what's passed to the annotator.
I think if we did have two separate interfaces, they should be called
CAS and CasView. The CAS interface might have all the methods that
are currently defined on CAS, except getIndexRepository(). But I
don't know if we're going to contain that split at this time, anyway.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Marshall Schor <ms...@schor.com>.
If we go with a model of delivering a "base-CAS" to annotators, what
methods besides "getView()" are available on this object?
If only getView() is, perhaps we should define this object to be a
"view-getter", not a base-CAS, since it doesn't share very much
with the CAS APIs.
-Marshall
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/12/06, Eddie Epstein <ed...@aewatercolors.com> wrote:
> This should work, very nice, but do we really want users to insert
> getView() in front of many things, like
> cas.getView().getFSIndexRepository() and
> cas.getView().createAnnotation(..), etc?
>
> How about using deprecation text advising just the insertion of
> cas=cas.getView() at the begining of the process method?
>
Yes, I agree that would be a better suggestion to give.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/14/06, Thilo Goetz <tw...@gmx.de> wrote:
> Sure, those would be on the view as well. Would we then have
> text-specific views, like TCasView? I'm not proposing this, mind you,
> just asking.
>
My sense is we want to stay away from modality-specific views.
Perhaps I might change my mind if there were a compelling argument. I
think we'll need to have a JCasView, though.
>> CasView viewOfMySofa = inCas.getView() ?
> +1 to that.
I'm OK with this being the way that new code does things, but still
think it's important to have a deprecation strategy for older code.
> inCas.getDocumentText() would not work, +1 to that. However, I was
> thinking that you would be able to access *all* indexes (and their
> contents of course) from the CAS, not just the sofa-neutral ones.
> Perhaps you wouldn't know how to interpret the sofa information, but the
> annotations would still be accessible. I think this is consistent with
> your idea/proposal that the CAS is the container of all data. Was this
> also what you were thinking?
>
Let me see if I can summarize where we are now:
* Index definitions are shared across the entire CAS.
* Each defined index will have one instance in the CAS as well as an
instance for each view (or sofa? right now sofas and views are 1-1 so
it doesn't matter but I wonder what the right terminology is)
* You can add FS to the indexes in a view (or multiple views). You
can also add FS to the indexes on the CAS, which is a place to store
indexed FS that don't belong to any view.
* If you get an iterator over an index from the CAS, this iterator
will return you FS that were indexed in the CAS well as FS that were
indexed in any view.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
> On 12/13/06, Thilo Goetz <tw...@gmx.de> wrote:
>
>> I couldn't agree more (except for the default bag indexes). It makes no
>> sense at all that global indexes must be accessed via a particular view.
>>
>
> I can't tell what exactly you're agreeing to. Are you thinking that
> anything indexed in a view would also be by definition indexed in the
> "global" view? Do we need different index definitions for the global
> view (so we don't have a global index over annotations sorted by
> begin, end but containing annotations from multiple Sofas)?
I was agreeing to your statement that non-sofa (i.e., non-annotation)
indexes make sense in a global view.
I would think that annotations for different sofas would be in different
indexes. Not sure what we currently do though. All those indexes might
be accessible from the global view.
>> In that case, a view could be seen as just a set of indexes, with
>> possibly just two methods: getIndexes() (and variations) and
>> addToIndexes(FS). The base CAS would be a view on everything. A view
>> might be what we now call index repository. In fact, if we just rename
>> the index repository to "view", we're done ;-). Just a little
>> implementation to make more than one index repository possible.
>>
>
> We haven't addressed Sofas yet.
>
> The base CAS does not have a single subject of anlaysis, so methods
> like getDocumentText() and its relatives are a problem. These methods
> should belong to a view. (According to the spec, not all views
> necessarily have a Sofa, but it is a common use case supported by the
> particular kind of view called an Anchored View.)
Sure, those would be on the view as well. Would we then have
text-specific views, like TCasView? I'm not proposing this, mind you,
just asking.
>> So no CAS cas = inCas.getView()?
>>
>
> Certainly, I never liked that idea but are we back to essentially
> requiring:
> CasView viewOfMySofa = inCas.getView() ?
+1 to that.
>
> Since inCas.getDocumentText() would not work, and inCas cannot be used
> to iterate over or index annotations belonging to a particular Sofa.
inCas.getDocumentText() would not work, +1 to that. However, I was
thinking that you would be able to access *all* indexes (and their
contents of course) from the CAS, not just the sofa-neutral ones.
Perhaps you wouldn't know how to interpret the sofa information, but the
annotations would still be accessible. I think this is consistent with
your idea/proposal that the CAS is the container of all data. Was this
also what you were thinking?
--Thilo
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/13/06, Thilo Goetz <tw...@gmx.de> wrote:
> I couldn't agree more (except for the default bag indexes). It makes no
> sense at all that global indexes must be accessed via a particular view.
>
I can't tell what exactly you're agreeing to. Are you thinking that
anything indexed in a view would also be by definition indexed in the
"global" view? Do we need different index definitions for the global
view (so we don't have a global index over annotations sorted by
begin, end but containing annotations from multiple Sofas)?
> In that case, a view could be seen as just a set of indexes, with
> possibly just two methods: getIndexes() (and variations) and
> addToIndexes(FS). The base CAS would be a view on everything. A view
> might be what we now call index repository. In fact, if we just rename
> the index repository to "view", we're done ;-). Just a little
> implementation to make more than one index repository possible.
>
We haven't addressed Sofas yet.
The base CAS does not have a single subject of anlaysis, so methods
like getDocumentText() and its relatives are a problem. These methods
should belong to a view. (According to the spec, not all views
necessarily have a Sofa, but it is a common use case supported by the
particular kind of view called an Anchored View.)
> So no CAS cas = inCas.getView()?
>
Certainly, I never liked that idea but are we back to essentially requiring:
CasView viewOfMySofa = inCas.getView() ?
Since inCas.getDocumentText() would not work, and inCas cannot be used
to iterate over or index annotations belonging to a particular Sofa.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
...
> Possible conclusion for the Java API: We should provide a way to get
> all of the FS from the CAS and add new FS to the CAS, as part of the
> Base CAS API. Note that we currently jump through hoops in XMI/XCAS
> serialization because we don't have such access.
That's a basic design question. The CAS was not designed to deliver
that information. If the standard requires it, we'll need to change the
CAS. It's a completely orthogonal issue, though.
...
> Thilo advocates addressing this issue by eliminating the capability to
> create objects off the base CAS. But there is an alternative
> solution, which is to add the ability to retrieve objects from the
> base CAS. The latter may be more in-sync with the proposed UIMA spec.
Since that's the way it used to be, I have no problem with that. All I
want is consistency and conceptual clarity ;-)
In that case, a view could be seen as just a set of indexes, with
possibly just two methods: getIndexes() (and variations) and
addToIndexes(FS). The base CAS would be a view on everything. A view
might be what we now call index repository. In fact, if we just rename
the index repository to "view", we're done ;-). Just a little
implementation to make more than one index repository possible.
> I think the reason we don't have a way to retrieve objects from the
> base CAS is that our built-in annotation index, sorted by location
> within the Sofa, doesn't make sense if not segregated by Sofa. But
> other kinds of indexes may very well be useful for the entire CAS.
> Perhaps even bag indexes separated by type are useful. (Note we have
> suggested in the past that we might implement such bag indexes by
> default in a future version.)
I couldn't agree more (except for the default bag indexes). It makes no
sense at all that global indexes must be accessed via a particular view.
> Sorry for the length of this post, I hope it is helpful. I think the
> summary from my point of view is that in light of the UIMA spec, views
> ought to be an optional way to interact with a CAS. If we want to
> make them required, we should take that up with the OASIS TC and see
> if we can get buy-in there, before we try to implement anything.
So no CAS cas = inCas.getView()?
--Thilo
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/13/06, Thilo Goetz <tw...@gmx.de> wrote:
> Let's disregard the question of backward compatibility for a moment. In
> an ideal world, where we could design the APIs the way we wanted, what
> would we do?
>
Let's consider what the proposed UIMA spec has to say. First note
that the spec is centered around the XMI representation of the CAS.
Java APIs are considered a way to get at that information.
When the spec first introduces the CAS it says that a CAS is just a
collection of objects (i.e., FeatureStructures). Views are not
introduced until much later, as a way to organize that collection of
objects.
Thinking about this from an XMI point of view, what you send to an
annotator (e.g., web service) is an XMI document with a list of
objects in it. Ignoring the Java API for a moment, it's perfectly
valid for an annotator service to read and write these objects
directly. No notion of a view is necessary. This is considered a
critical enabler of interoperability with simple XML-based
implementations such as WebFountain.
Possible conclusion for the Java API: We should provide a way to get
all of the FS from the CAS and add new FS to the CAS, as part of the
Base CAS API. Note that we currently jump through hoops in XMI/XCAS
serialization because we don't have such access.
Now as for Views, a View is a subset of objects from the CAS. A
special kind of view called an "Anchored View" is associated with a
Sofa, and has the constraint that all annoations in the Anchored View
refer to that Sofa. This feature is important for multi-Sofa
applications that need to keep their annotations organized. Here is
example XMI from the spec (pp.40-41):
<ex:Quotation xmi:id="1"
text="If we begin in certainties, we shall end with doubts; but if
we begin with doubts and are patient with them, we shall end in
certainties."
author="Francis Bacon"/>
<cas:SofaReference xmi:id="2" sofaObject="1" sofaFeature="text"/>
<ex:Pronoun xmi:id="4" sofa="2" begin="3" end="5" lemma="6"/>
<ex:Pronoun xmi:id="5" sofa="2" begin="29" end="31" lemma="6"/>
<ex:Lemma xmi:id="6" base="I" person="1" number="p"/>
<uima:AnchoredView sofa="2" members="3 4 5"/>
<ex:Quotation xmi:id="7"
text="The only limit to our realization of tomorrow will be our
doubts of today."
author="Franklin D. Roosevelt"/>
<cas:SofaReference xmi:id="8" sofaObject="7" sofaFeature="text"/>
<ex:Pronoun xmi:id="9" sofa="8" begin="18" end="21" lemma="11"/>
<ex:Pronoun xmi:id="10" sofa="8" begin="54" end="57" lemma="11"/>
<ex:Lemma xmi:id="11" base="my" person="1" number="p"/>
<cas:AnchoredView sofa="7" members="9 10 11"/>
Note that although this example doesn't show it, a FeatureStructure
that was not an annotation (did not link to a Sofa), could be shared
between the views. Views are not disjoint subsets of the set of
objects in the CAS.
In our implementation, we have indexes. These aren't part of the spec
at all. They're considered an implementation feature, albeit an
important one. We currently have indexes only over specific views.
There's are no indexes over the entire CAS.
This is part of the confusion. I'm trying to say that objects live in
the CAS, not views; but since you can only access them through indexes
and indexes are only on views, it seems useless to create an object
off the base CAS.
Thilo advocates addressing this issue by eliminating the capability to
create objects off the base CAS. But there is an alternative
solution, which is to add the ability to retrieve objects from the
base CAS. The latter may be more in-sync with the proposed UIMA spec.
I think the reason we don't have a way to retrieve objects from the
base CAS is that our built-in annotation index, sorted by location
within the Sofa, doesn't make sense if not segregated by Sofa. But
other kinds of indexes may very well be useful for the entire CAS.
Perhaps even bag indexes separated by type are useful. (Note we have
suggested in the past that we might implement such bag indexes by
default in a future version.)
Sorry for the length of this post, I hope it is helpful. I think the
summary from my point of view is that in light of the UIMA spec, views
ought to be an optional way to interact with a CAS. If we want to
make them required, we should take that up with the OASIS TC and see
if we can get buy-in there, before we try to implement anything.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
> On 12/13/06, Thilo Goetz <tw...@gmx.de> wrote:
...
>> I can only restate what I said earlier: to my
>> mind, conceptual clarity of the APIs is more important than backward
>> compatility.
>>
>
> Well we probably have to answer this question of philosophy before we
> can make technical progress. I'm unwilling to make such an
> unconditional statement. I think backward compatibility is very
> important, and that we should seriously consider the option of
> deprecating things rather than removing them.
Let's disregard the question of backward compatibility for a moment. In
an ideal world, where we could design the APIs the way we wanted, what
would we do?
My suggestion would be to completely separate the base CAS and CASView
APIs, as Marshall also suggested in an earlier note. I see no reason to
have the FS creation APIs on the base CAS. From a user's perspective,
FSs are always particular to a view since they can only be index wrt a
view, and retrieved wrt to a view. So why should they be created on a
base CAS? The only thing the base CAS should be concerned with then is
the administration of views.
--Thilo
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/13/06, Thilo Goetz <tw...@gmx.de> wrote:
> Correct me if I'm wrong, but I think we've come full circle. I don't
> like this approach since it tries to hide a fundamental change in the
> way we think about CASes (from single-artifact to multi-artifact etc.)
> under the current APIs.
I don't agree that this is full circle. It provides a clean new API
for new users to adopt. It does leave a few messy deprecated methods,
but they are clearly marked, so new users can easily steer clear of
them and existing users will be encouraged to migrate to the new API.
> I can only restate what I said earlier: to my
> mind, conceptual clarity of the APIs is more important than backward
> compatility.
>
Well we probably have to answer this question of philosophy before we
can make technical progress. I'm unwilling to make such an
unconditional statement. I think backward compatibility is very
important, and that we should seriously consider the option of
deprecating things rather than removing them.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Thilo Goetz <tw...@gmx.de>.
Correct me if I'm wrong, but I think we've come full circle. I don't
like this approach since it tries to hide a fundamental change in the
way we think about CASes (from single-artifact to multi-artifact etc.)
under the current APIs. I can only restate what I said earlier: to my
mind, conceptual clarity of the APIs is more important than backward
compatility.
I'm still digesting the OASIS proposal, maybe it will shed additional
light...
Eddie Epstein wrote:
>> On 12/12/06, Adam Lally <al...@alum.rpi.edu> wrote:
...
>> Here's a shot at a brilliant idea. Or it may be a stupid idea...
>> often it's a fine line between the two. :)
>>
>> Create a separate CasView interface which has the index-related and
>> sofa-related methods. However, do not remove these methods from CAS.
>> Instead, only deprecate them. If someone calls one of these methods
>> on the CAS, we redirect this to the default view, e.g., in CASImpl we
>> would have:
>>
>> /**
>> * @deprecated use getView().getFSIndexRepository() instead
>> */
>> public FSIndexRepository getFSIndexRepository() {
>> return getView().getFSIndexRepository();
>> }
>>
>> I think the effect of this should be that single-view annotators would
>> continue to work without code change, but would get deprecating
>> warnings encouraging them to change their code to call getView().
>>
>> Multiple-Sofa annotators would still break because CAS.getView(String
>> name) would now return type CasView rather than CAS. But, at least
>> that's far fewer annotators that would have to be manually ported.
>>
>> -Adam
>>
>
> This should work, very nice, but do we really want users to insert
> getView() in front of many things, like
> cas.getView().getFSIndexRepository() and
> cas.getView().createAnnotation(..), etc?
>
> How about using deprecation text advising just the insertion of
> cas=cas.getView() at the begining of the process method?
>
> Eddie
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Eddie Epstein <ed...@aewatercolors.com>.
> On 12/12/06, Adam Lally <al...@alum.rpi.edu> wrote:
>> Maybe someone can come up
>> with a brilliant idea about how we can fix this and still support
>> migration? That would be nice.
>>
>
> Here's a shot at a brilliant idea. Or it may be a stupid idea...
> often it's a fine line between the two. :)
>
> Create a separate CasView interface which has the index-related and
> sofa-related methods. However, do not remove these methods from CAS.
> Instead, only deprecate them. If someone calls one of these methods
> on the CAS, we redirect this to the default view, e.g., in CASImpl we
> would have:
>
> /**
> * @deprecated use getView().getFSIndexRepository() instead
> */
> public FSIndexRepository getFSIndexRepository() {
> return getView().getFSIndexRepository();
> }
>
> I think the effect of this should be that single-view annotators would
> continue to work without code change, but would get deprecating
> warnings encouraging them to change their code to call getView().
>
> Multiple-Sofa annotators would still break because CAS.getView(String
> name) would now return type CasView rather than CAS. But, at least
> that's far fewer annotators that would have to be manually ported.
>
> -Adam
>
This should work, very nice, but do we really want users to insert
getView() in front of many things, like
cas.getView().getFSIndexRepository() and
cas.getView().createAnnotation(..), etc?
How about using deprecation text advising just the insertion of
cas=cas.getView() at the begining of the process method?
Eddie
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/12/06, Adam Lally <al...@alum.rpi.edu> wrote:
> Maybe someone can come up
> with a brilliant idea about how we can fix this and still support
> migration? That would be nice.
>
Here's a shot at a brilliant idea. Or it may be a stupid idea...
often it's a fine line between the two. :)
Create a separate CasView interface which has the index-related and
sofa-related methods. However, do not remove these methods from CAS.
Instead, only deprecate them. If someone calls one of these methods
on the CAS, we redirect this to the default view, e.g., in CASImpl we
would have:
/**
* @deprecated use getView().getFSIndexRepository() instead
*/
public FSIndexRepository getFSIndexRepository() {
return getView().getFSIndexRepository();
}
I think the effect of this should be that single-view annotators would
continue to work without code change, but would get deprecating
warnings encouraging them to change their code to call getView().
Multiple-Sofa annotators would still break because CAS.getView(String
name) would now return type CasView rather than CAS. But, at least
that's far fewer annotators that would have to be manually ported.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
...
> (2) It is confusing that an object of type "CAS" could be either a
> base CAS or a view. A base CAS has several unsupported operations,
> which throw exceptions if you call them. I cannot think of a rational
> justification for this design other than backwards compatibility.
> Most of the recent discussions have been about how to fix this,
> however as I said in my previous note any attempt to fix this
> seriously complicates the migration story. Maybe someone can come up
> with a brilliant idea about how we can fix this and still support
> migration? That would be nice.
>
> -Adam
I agree, but would put it even more strongly: the current design is
broken and needs to be fixed. We can't expect to move to the CAS view
design without breaking some backward compatibility. I'd personally
much rather manually port a score of annotators and know what I'm doing
and why I'm doing it, than have an automatic migration tool insert some
code snippets that I don't understand.
--Thilo
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/12/06, Eddie Epstein <ed...@aewatercolors.com> wrote:
> Currently the base CAS and views have the same API set, the only
> differences between the base CAS and all other views are:
> - the base CAS has no index repository
> - the base CAS has no Sofa
>
> Given a base CAS it is possible to create FS, including Sofas, but not
> annotation FS because they require a Sofa to point at.
>
> To me the important thing is to give all process methods the same CAS
> handle, and the current base CAS is perfectly suitable.
>
There are two related issues here:
(1) The "CAS" passed to the process method currently might be a view
or might be the "base CAS". We can simplify by always passing a base
CAS. I estimate I'm about +0.5 on this right now.
(2) It is confusing that an object of type "CAS" could be either a
base CAS or a view. A base CAS has several unsupported operations,
which throw exceptions if you call them. I cannot think of a rational
justification for this design other than backwards compatibility.
Most of the recent discussions have been about how to fix this,
however as I said in my previous note any attempt to fix this
seriously complicates the migration story. Maybe someone can come up
with a brilliant idea about how we can fix this and still support
migration? That would be nice.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Eddie Epstein <ed...@aewatercolors.com>.
>
> Let me see if I understand the proposal that's on the table. There is a
> core set of APIs that both the view and the container will have, such as
> createFS() and that whole family of methods. Then there's a bunch of
> sofa-related stuff and getIndexRepository() which is only defined on
> views. Finally, there's some view management stuff (such as
> createView()) that will only be defined on the container.
>
Currently the base CAS and views have the same API set, the only
differences between the base CAS and all other views are:
- the base CAS has no index repository
- the base CAS has no Sofa
Given a base CAS it is possible to create FS, including Sofas, but not
annotation FS because they require a Sofa to point at.
To me the important thing is to give all process methods the same CAS
handle, and the current base CAS is perfectly suitable.
Eddie
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/11/06, Thilo Goetz <tw...@gmx.de> wrote:
> What about addFsToIndexes()? I would assume that should live where
> getIndexRepository() lives.
>
Yes, I forgot we added that. It would also be only on the view.
> It would be nice to change that so they're not actually there (I think
> that's what you're suggesting).
>
Right.
> Let me see if I understand the proposal that's on the table. There is a
> core set of APIs that both the view and the container will have, such as
> createFS() and that whole family of methods. Then there's a bunch of
> sofa-related stuff and getIndexRepository() which is only defined on
> views. Finally, there's some view management stuff (such as
> createView()) that will only be defined on the container.
>
> Please let me know if I've misunderstood.
>
That's the proposal. However, I'm not 100% sure if I think we should
really do this, since it seems like it will be disruptive to users.
There's a lot to be said for having a simple search-and-replace script
that can do the IBM UIMA -> Apache UIMA migration, that works at least
for common cases. If we split the CAS interface apart, this would be
hard to do.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
>> From an interface point of view, does it matter? As I understand it,
>> you can neither create nor access FSs in the CasContainer (I'm just
>> calling it that to avoid confusion, not because I think that's a good
>> name). Or can you? What is the division of labor here?
>>
>
> What I intended to propose was that the "CasContainer" as you call it
> would basically have all of the CAS APIs except getIndexRepository()
> and the ones related to Sofas (including getDocumentText()).
What about addFsToIndexes()? I would assume that should live where
getIndexRepository() lives.
> Essentially, this is what we already have implemented... except that
> instead of not defining the methods on the CasConsumer (the "Base
> CAS"), they are there but throw exceptions if you call them.
It would be nice to change that so they're not actually there (I think
that's what you're suggesting).
Let me see if I understand the proposal that's on the table. There is a
core set of APIs that both the view and the container will have, such as
createFS() and that whole family of methods. Then there's a bunch of
sofa-related stuff and getIndexRepository() which is only defined on
views. Finally, there's some view management stuff (such as
createView()) that will only be defined on the container.
Please let me know if I've misunderstood.
--Thilo
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
> From an interface point of view, does it matter? As I understand it,
> you can neither create nor access FSs in the CasContainer (I'm just
> calling it that to avoid confusion, not because I think that's a good
> name). Or can you? What is the division of labor here?
>
What I intended to propose was that the "CasContainer" as you call it
would basically have all of the CAS APIs except getIndexRepository()
and the ones related to Sofas (including getDocumentText()).
Essentially, this is what we already have implemented... except that
instead of not defining the methods on the CasConsumer (the "Base
CAS"), they are there but throw exceptions if you call them.
> You're probably right, but I'm not there yet. I'd like to get the
> concepts sorted out in my head before I get to implementation details
> like where the heap lives and how we do serialization.
>
I don't want to get into *how* we do serialization either, just what
the user can see. And the fact that one CAS maps to one serialized
document is important.
> I don't know about that. I certainly wouldn't want to keep calling what
> I call the CasContainer the CAS. That may make sense from a 10.000ft
> view, but if you look at the API/interface level, there is very little
> the old CAS interface and the new CasContainer interface have in common.
> For somebody who hasn't been using views, a CasView is just like a
> CAS, while the CasContainer is a new animal. The fact that FSs can be
> cross-reference doesn't bother me. Do we keep all those FSs on a single
> heap, or do we have one for each view? That's an implementation detail
> that may change tomorrow, and it should not affect our users at all.
>
This may be 10,000-foot, but I think of the CAS as being what's passed
between annotators as a basic UIMA concept that's worth preserving.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
> On 12/11/06, Thilo Goetz <tw...@gmx.de> wrote:
>> The heap? How does that come into the picture?
>>
>
> I just meant that the CAS is where the actual data (the
> FeatureStructures) live.
From an interface point of view, does it matter? As I understand it,
you can neither create nor access FSs in the CasContainer (I'm just
calling it that to avoid confusion, not because I think that's a good
name). Or can you? What is the division of labor here?
>
>> What about the type system? Is that accessible from the CasView, or
>> just from the CAS?
>>
>
> Logically, the TypeSystem belongs to the CAS (all views share the same
> type system). But the CasView could certainly have a convenience
> method for accessing it as well.
Ok, so then you only need the CasContainer to create and access views,
right? So from an API point of view, the old CAS API has a lot more in
common with the CasView than with the CasContainer.
>
>
>> So the we have a meta-CAS that holds the type system info and all the
>> concrete CASes with the actual data.
>
> I see there as being only one concrete CAS that contains all the data.
> The CasViews just have different indexes over that data. A single FS
> could belong (i.e. be indexed in) more than one CasView.
>
> Also if we serialize the analysis results I see that as serializing a
> single CAS, even though there may be multiple views. Single views
> aren't easily serializable since references between FSs in different
> views are allowed.
You're probably right, but I'm not there yet. I'd like to get the
concepts sorted out in my head before I get to implementation details
like where the heap lives and how we do serialization.
>
>> So really, what we call the
>> CasView I would call the CAS, and that other thing is a CAS container.
>> All CASes in the same container share the type system and can also share
>> FSs.
>> <snip/>
>> Or we could give up on the word CAS completely and introduce two new
>> ones. That might be the least confusing.
>>
>
> Since we've already been using the term "view" in UIMA for a while (in
> method names and documentation, even if not in the actual interface
> name), I think it would be nice to try to make that terminology
> continue to work.
>
> -Adam
I don't know about that. I certainly wouldn't want to keep calling what
I call the CasContainer the CAS. That may make sense from a 10.000ft
view, but if you look at the API/interface level, there is very little
the old CAS interface and the new CasContainer interface have in common.
For somebody who hasn't been using views, a CasView is just like a
CAS, while the CasContainer is a new animal. The fact that FSs can be
cross-reference doesn't bother me. Do we keep all those FSs on a single
heap, or do we have one for each view? That's an implementation detail
that may change tomorrow, and it should not affect our users at all.
--Thilo
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/11/06, Thilo Goetz <tw...@gmx.de> wrote:
> The heap? How does that come into the picture?
>
I just meant that the CAS is where the actual data (the FeatureStructures) live.
> What about the type system? Is that accessible from the CasView, or
> just from the CAS?
>
Logically, the TypeSystem belongs to the CAS (all views share the same
type system). But the CasView could certainly have a convenience
method for accessing it as well.
> So the we have a meta-CAS that holds the type system info and all the
> concrete CASes with the actual data.
I see there as being only one concrete CAS that contains all the data.
The CasViews just have different indexes over that data. A single FS
could belong (i.e. be indexed in) more than one CasView.
Also if we serialize the analysis results I see that as serializing a
single CAS, even though there may be multiple views. Single views
aren't easily serializable since references between FSs in different
views are allowed.
> So really, what we call the
> CasView I would call the CAS, and that other thing is a CAS container.
> All CASes in the same container share the type system and can also share
> FSs.
> <snip/>
> Or we could give up on the word CAS completely and introduce two new
> ones. That might be the least confusing.
>
Since we've already been using the term "view" in UIMA for a while (in
method names and documentation, even if not in the actual interface
name), I think it would be nice to try to make that terminology
continue to work.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
> On 12/11/06, Thilo Goetz <tw...@gmx.de> wrote:
>> So what about Adam's suggestion to separate a CAS from a view? What
>> *is* the difference, conceptually?
>>
>
> A View has an index repository and a Sofa. (The Sofa may become
> optional, but in the current impl. it is not.)
>
> A CAS holds the analysis metadata (i.e., it has the heap) and contains
> one or more views. It does not itself have a Sofa or an index
> repository.
The heap? How does that come into the picture?
>
> So basically, if we split the interfaces then CAS interface would lose
> the Sofa-access methods and the getIndexRepository() methods. The
> CasView interface would not have getView() methods, but otherwise
> would look pretty much like the CAS interface does today.
What about the type system? Is that accessible from the CasView, or
just from the CAS?
So the we have a meta-CAS that holds the type system info and all the
concrete CASes with the actual data. So really, what we call the
CasView I would call the CAS, and that other thing is a CAS container.
All CASes in the same container share the type system and can also share
FSs.
If we want to go that route, and it sound like we do, then let's bite
the bullet and call that new construct something different. Then our
interfaces change and the whole thing will make more sense to users. It
seems intuitive to me to say
process(CasContainer casContainer) {
TypeSystem ts = casContainer.getTypeSystem();
CAS cas = casContainer.getDefaultCas();
...
Or we could give up on the word CAS completely and introduce two new
ones. That might be the least confusing.
--Thilo
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/11/06, Thilo Goetz <tw...@gmx.de> wrote:
> So what about Adam's suggestion to separate a CAS from a view? What
> *is* the difference, conceptually?
>
A View has an index repository and a Sofa. (The Sofa may become
optional, but in the current impl. it is not.)
A CAS holds the analysis metadata (i.e., it has the heap) and contains
one or more views. It does not itself have a Sofa or an index
repository.
So basically, if we split the interfaces then CAS interface would lose
the Sofa-access methods and the getIndexRepository() methods. The
CasView interface would not have getView() methods, but otherwise
would look pretty much like the CAS interface does today.
> If we did separate the interfaces, could we provide a process method
> that gets the default view as input?
>
This is basically where we were when we were using the TCAS interface
as the equivalent of a CasView interface, but this ran into lots of
problems. We had different annotator interfaces, some of which took
TCAS as an argument and some of which took CAS as an argument. Yet
others took JCas as an argument, and it was not clear whether the JCas
was an interface to the whole CAS or just a view (i.e., did it wrap a
CAS or wrap a TCAS). Then there were the CollectionReader and
CasConsumer interfaces, which always took only CAS as an argument.
Basically, there are too many different variants of the process call
in this scenario. It was simpler to have only a single set of
annotator interfaces that vary based on the type of CAS implementation
they take -- CAS, JCas, or whatever we think of next. This is where
our current implementation stands.
The unfortunate confusion that remains is that for an annotator with
e.g. a process(CAS) signature, that CAS could be either the base CAS
("whole CAS"?) or a view. This is determined by the annotator's
descriptor.
I do like that Eddie's suggestion makes things more uniform.
process(CAS) always gets the base CAS. But I think it is still very
confusing that getView() returns an object of type CAS.
I can see the user conceptualization now:
void process(CAS casObjectThatDoesntWork) {
//why does this method throw an exception?
//casObjectThatDoesntWork.getDocumentText();
CAS theCasICanActuallyUse =
casObjectThatDoesntWork.someMethodIDontUnderstand();
//ok now it works?
theCasICanActuallyUse.getDocumentText();
}
:/
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Thilo Goetz <tw...@gmx.de>.
So what about Adam's suggestion to separate a CAS from a view? What
*is* the difference, conceptually?
If we did separate the interfaces, could we provide a process method
that gets the default view as input?
--Thilo
Eddie Epstein wrote:
>> Please help me here, I'm not really up-to-date with the whole view/Sofa
>> concept. Can't we provide a process method that is fully backward
>> compatible, without having to call this? I think that would be the
>> preferable solution.
>>
>> Also, I think it's premature to look to the OASIS work for guidance.
>> Let's follow our own good sense until the standard is at a stage where
>> we feel confident it won't change much.
>>
>> --Thilo
>>
>
> Thilo, all the work on view/Sofas to-date has kept the old process method
> signatures, as you suggest. Unfortunately this backward compatibility
> causes substantial complexity in the documentation and conceptualization
> for many users. The desire to make the proposed simplification predates
> the OASIS work.
>
> The simplest view of CAS data is as a flat list of feature structures.
> Many annotators need only work with subsets of this list, hence the
> mechanism of creating a "view" whose indexes are restricted to a subset.
>
> In essence, the OASIS perspective is that asking all annotator writers to
> understand the concept of a view as CAS subset is better than trying to
> hide this fact for "single-view" annotator writers and complicating the
> world for everyone else.
>
> Eddie
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Eddie Epstein <ed...@aewatercolors.com>.
>
> Please help me here, I'm not really up-to-date with the whole view/Sofa
> concept. Can't we provide a process method that is fully backward
> compatible, without having to call this? I think that would be the
> preferable solution.
>
> Also, I think it's premature to look to the OASIS work for guidance.
> Let's follow our own good sense until the standard is at a stage where
> we feel confident it won't change much.
>
> --Thilo
>
Thilo, all the work on view/Sofas to-date has kept the old process method
signatures, as you suggest. Unfortunately this backward compatibility
causes substantial complexity in the documentation and conceptualization
for many users. The desire to make the proposed simplification predates
the OASIS work.
The simplest view of CAS data is as a flat list of feature structures.
Many annotators need only work with subsets of this list, hence the
mechanism of creating a "view" whose indexes are restricted to a subset.
In essence, the OASIS perspective is that asking all annotator writers to
understand the concept of a view as CAS subset is better than trying to
hide this fact for "single-view" annotator writers and complicating the
world for everyone else.
Eddie
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/11/06, Thilo Goetz <tw...@gmx.de> wrote:
> Also, I think it's premature to look to the OASIS work for guidance.
> Let's follow our own good sense until the standard is at a stage where
> we feel confident it won't change much.
>
I think that depends on the situation. Certainly, I would not
recommend complying to the letter of any XML schema or WSDL in the
current white paper available from the OASIS TC. But when it comes to
renaming things that already have names in the whitepaper, I would
rather not go off inventing new names. If we felt really strongly
about a name, it would be wise for those of us who are also on the TC
to raise the issue there before implementing it.
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Thilo Goetz <tw...@gmx.de>.
eddie_epstein@aewatercolors.com wrote:
>> Also, I'm still not sure how I feel about the zero-arg getView() -
>> what view does it get? What would the Javadoc for this method say?
>>
>> -Adam
>>
>
> getView() returns either 1: a view specifically selected for this
> component by Sofa mapping, or if no Sofa mapping 2: the built-in
> _InitialView. Using this call at the top of process() would provide all
> existing Sofa-unaware annotators with the same CAS view they got in
> previous versions of UIMA.
>
> Eddie
Please help me here, I'm not really up-to-date with the whole view/Sofa
concept. Can't we provide a process method that is fully backward
compatible, without having to call this? I think that would be the
preferable solution.
Also, I think it's premature to look to the OASIS work for guidance.
Let's follow our own good sense until the standard is at a stage where
we feel confident it won't change much.
--Thilo
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by ed...@aewatercolors.com.
> Also, I'm still not sure how I feel about the zero-arg getView() -
> what view does it get? What would the Javadoc for this method say?
>
> -Adam
>
getView() returns either 1: a view specifically selected for this
component by Sofa mapping, or if no Sofa mapping 2: the built-in
_InitialView. Using this call at the top of process() would provide all
existing Sofa-unaware annotators with the same CAS view they got in
previous versions of UIMA.
Eddie
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/8/06, eddie_epstein@aewatercolors.com
<ed...@aewatercolors.com> wrote:
> >
> Yes, a single line inserted after process(inCas,...):
> inCas = inCas.getView(); // automatically added by migration
>
I suppose that should work. It might be a bit ugly for multi-Sofa
annotators who expect inCas to refer to the Base CAS. But, as long as
further inCas.getView(name) calls still work, it shouldn't actually
cause any error.
> Or one can say that the base CAS is a view without a Sofa. At any rate,
> eliminating the confustion of which view is delivered to the process
> method would be a useful simplication, as well as consistent with the
> preliminary architecture specification.
>
Which reminds me, since there's now a very early draft specification
available for UIMA (as of this Wednesday), we probably ought to link
to it from our podling website.
The draft spec does say that annotators are passed a CAS, but it also
says that a CAS is not the same as a View and notes that our
implementation should probably not treat them as the same thing. But
I guess we may not be ready to make that change.
Also, I'm still not sure how I feel about the zero-arg getView() -
what view does it get? What would the Javadoc for this method say?
-Adam
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the
process method
Posted by ed...@aewatercolors.com.
>
> Will this change to user code be able to be done automatically by a
> script? It seems like it might be a little ugly to do.
Yes, a single line inserted after process(inCas,...):
inCas = inCas.getView(); // automatically added by migration
>
> Also it still very confusing that the CAS interface can refer to
> either the base CAS or a view. If we make your proposed change I
> think we might also want to create a separate CasView interface. But
> that causes even more trouble for a migration script; it may not even
> be possible to do non-interactively. :(
Or one can say that the base CAS is a view without a Sofa. At any rate,
eliminating the confustion of which view is delivered to the process
method would be a useful simplication, as well as consistent with the
preliminary architecture specification.
Eddie
Re: [jira] Created: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/8/06, Eddie Epstein (JIRA) <ui...@incubator.apache.org> wrote:
> Currently there is a distinction made for "single view" and "multiple view" components. The UIMA architecture standard proposes that all components are multiple view components and be delivered a handle to the base CAS, and the component retrieves views as required. The change to existing "single view" component would be to add one line of code in the process method: cas = passInCas.getView(), which would return the View currently given to these components as determined by Sofa mapping.
>
Will this change to user code be able to be done automatically by a
script? It seems like it might be a little ugly to do.
Also it still very confusing that the CAS interface can refer to
either the base CAS or a view. If we make your proposed change I
think we might also want to create a separate CasView interface. But
that causes even more trouble for a migration script; it may not even
be possible to do non-interactively. :(
-Adam
[jira] Resolved: (UIMA-116) Always deliver the base CAS to the
process method
Posted by "Adam Lally (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Lally resolved UIMA-116.
-----------------------------
Resolution: Won't Fix
Fix Version/s: (was: 2.1)
No consensus that this should be done. It should be addressed as part of a larger CAS/CasView redesign in a future version.
> Always deliver the base CAS to the process method
> -------------------------------------------------
>
> Key: UIMA-116
> URL: https://issues.apache.org/jira/browse/UIMA-116
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Affects Versions: 2.1
> Environment: UIMA components
> Reporter: Eddie Epstein
> Assigned To: Adam Lally
>
> Currently there is a distinction made for "single view" and "multiple view" components. The UIMA architecture standard proposes that all components are multiple view components and be delivered a handle to the base CAS, and the component retrieves views as required. The change to existing "single view" component would be to add one line of code in the process method: cas = passInCas.getView(), which would return the View currently given to these components as determined by Sofa mapping.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Assigned: (UIMA-116) Always deliver the base CAS to the process method
Posted by Adam Lally <al...@alum.rpi.edu>.
On 1/4/07, Marshall Schor <ms...@schor.com> wrote:
> Adam Lally (JIRA) wrote:
> > <snip> Currently there is a distinction made for "single view" and "multiple view" components. The UIMA architecture standard proposes that all components are multiple view components and be delivered a handle to the base CAS, and the component retrieves views as required. The change to existing "single view" component would be to add one line of code in the process method: cas = passInCas.getView(), which would return the View currently given to these components as determined by Sofa mapping.
> >
> At one point we were discussing having the framework set the "current
> view" into the CAS before calling the process method - as a way of
> easing the transition.
>
> How will that work with the API re-factorings? Or did we decide to give
> up on that idea?
>
This issue is a month old, so take it with a grain of salt.
I'll add a comment to it to clarify. I just hadn't gotten to it yet.
-Adam
Re: [jira] Assigned: (UIMA-116) Always deliver the base CAS to the
process method
Posted by Marshall Schor <ms...@schor.com>.
Adam Lally (JIRA) wrote:
> <snip> Currently there is a distinction made for "single view" and "multiple view" components. The UIMA architecture standard proposes that all components are multiple view components and be delivered a handle to the base CAS, and the component retrieves views as required. The change to existing "single view" component would be to add one line of code in the process method: cas = passInCas.getView(), which would return the View currently given to these components as determined by Sofa mapping.
>
At one point we were discussing having the framework set the "current
view" into the CAS before calling the process method - as a way of
easing the transition.
How will that work with the API re-factorings? Or did we decide to give
up on that idea?
-Marshall
[jira] Assigned: (UIMA-116) Always deliver the base CAS to the
process method
Posted by "Adam Lally (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Lally reassigned UIMA-116:
-------------------------------
Assignee: Adam Lally
> Always deliver the base CAS to the process method
> -------------------------------------------------
>
> Key: UIMA-116
> URL: https://issues.apache.org/jira/browse/UIMA-116
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Affects Versions: 2.1
> Environment: UIMA components
> Reporter: Eddie Epstein
> Assigned To: Adam Lally
> Fix For: 2.1
>
>
> Currently there is a distinction made for "single view" and "multiple view" components. The UIMA architecture standard proposes that all components are multiple view components and be delivered a handle to the base CAS, and the component retrieves views as required. The change to existing "single view" component would be to add one line of code in the process method: cas = passInCas.getView(), which would return the View currently given to these components as determined by Sofa mapping.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (UIMA-116) Always deliver the base CAS to the
process method
Posted by "Adam Lally (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462335 ]
Adam Lally commented on UIMA-116:
---------------------------------
Update:
There is related discussion currently onging about refactoring the CAS interface and in the process creating a new CasView interface.
Also, the plan is to support single-view components without requiring any code change. This would be done by deprecating but not removing the view-related (sofa and index access) methods on the CAS interface, and having them auotmatically forward to the "current" view.
> Always deliver the base CAS to the process method
> -------------------------------------------------
>
> Key: UIMA-116
> URL: https://issues.apache.org/jira/browse/UIMA-116
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Affects Versions: 2.1
> Environment: UIMA components
> Reporter: Eddie Epstein
> Assigned To: Adam Lally
> Fix For: 2.1
>
>
> Currently there is a distinction made for "single view" and "multiple view" components. The UIMA architecture standard proposes that all components are multiple view components and be delivered a handle to the base CAS, and the component retrieves views as required. The change to existing "single view" component would be to add one line of code in the process method: cas = passInCas.getView(), which would return the View currently given to these components as determined by Sofa mapping.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (UIMA-116) Always deliver the base CAS to the
process method
Posted by "Adam Lally (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Lally closed UIMA-116.
---------------------------
won't fix, at least not in this form
> Always deliver the base CAS to the process method
> -------------------------------------------------
>
> Key: UIMA-116
> URL: https://issues.apache.org/jira/browse/UIMA-116
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Affects Versions: 2.1
> Environment: UIMA components
> Reporter: Eddie Epstein
> Assigned To: Adam Lally
>
> Currently there is a distinction made for "single view" and "multiple view" components. The UIMA architecture standard proposes that all components are multiple view components and be delivered a handle to the base CAS, and the component retrieves views as required. The change to existing "single view" component would be to add one line of code in the process method: cas = passInCas.getView(), which would return the View currently given to these components as determined by Sofa mapping.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira