On 12/14/06, Thilo Goetz <[EMAIL PROTECTED]> 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
Adam Lally wrote:
On 12/13/06, Thilo Goetz <[EMAIL PROTECTED]> 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
anythin
On 12/13/06, Thilo Goetz <[EMAIL PROTECTED]> 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
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 d
On 12/13/06, Thilo Goetz <[EMAIL PROTECTED]> 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 c
Adam Lally wrote:
On 12/13/06, Thilo Goetz <[EMAIL PROTECTED]> 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 p
On 12/13/06, Thilo Goetz <[EMAIL PROTECTED]> 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
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, concept
On 12/12/06, Eddie Epstein <[EMAIL PROTECTED]> 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 in
> On 12/12/06, Adam Lally <[EMAIL PROTECTED]> 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
On 12/12/06, Adam Lally <[EMAIL PROTECTED]> 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
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.
Mos
On 12/12/06, Eddie Epstein <[EMAIL PROTECTED]> 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, inclu
On 12/11/06, Thilo Goetz <[EMAIL PROTECTED]> 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 wh
>
> 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
> vi
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 int
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 wa
Adam Lally wrote:
On 12/11/06, Thilo Goetz <[EMAIL PROTECTED]> 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 crea
On 12/11/06, Thilo Goetz <[EMAIL PROTECTED]> 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 TypeS
Adam Lally wrote:
On 12/11/06, Thilo Goetz <[EMAIL PROTECTED]> 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 CA
On 12/11/06, Thilo Goetz <[EMAIL PROTECTED]> 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
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
>
> 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 fo
On 12/11/06, Thilo Goetz <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] 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
> 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. Us
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
On 12/8/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> 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 CA
>
> 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 inte
On 12/8/06, Eddie Epstein (JIRA) 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
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 Framew
31 matches
Mail list logo
