Adam Lally wrote:
On 1/5/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Solution 1:
How about always passing in a JCasView object? For unaware components,
this would be the view to use. For view aware components, this would be
some view (perhaps picked in a similar way), but the user code woul
FYI, more Wiki updates:
* Added FS-creation convenience methods to CasView, with a note
that this is still under debate. However this seems to be the majority
view so I thought it was appropriate to add it.
* Added a section on what to do with the JCasGen-erated cover
classes. This is also
On 1/5/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Solution 1:
How about always passing in a JCasView object? For unaware components,
this would be the view to use. For view aware components, this would be
some view (perhaps picked in a similar way), but the user code would be
expected to us
Adam Lally wrote:
On 1/4/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> So I think we need to deprecate addToIndexes().
Not sure about this - because the "current view" mechanism would
seem to make this work, even for multi-sofa. We could even put in
code that checked if the
On 1/4/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> So I think we need to deprecate addToIndexes().
Not sure about this - because the "current view" mechanism would
seem to make this work, even for multi-sofa. We could even put in
code that checked if the item being indexed
>> Single-sofa code could be made to work using the same "current view"
>> idea already discussed. But multi-sofa code will have a problem.
>>
>> So I think we need to deprecate addToIndexes().
> Not sure about this - because the "current view" mechanism would
> seem to make this work, even for mu
Adam Lally wrote:
There's another issue with JCas we haven't considered yet - the
addToIndexes() method on JCasGen-erated classes. When this is called,
it needs to know what index repository (what view) to index them in.
Same for removeFromIndexes() of course :-)
Currently, this uses whicheve
>
> However, are we sure that's such an important concept? What if we say
> that a CasView is a particular "window" on a CAS, a way of looking at
> it. That seems kind of consistent with the word "view". And it
> doesn't then seem so bad that you can make changes to the CAS through
> the view, s
There's another issue with JCas we haven't considered yet - the
addToIndexes() method on JCasGen-erated classes. When this is called,
it needs to know what index repository (what view) to index them in.
Currently, this uses whichever view (meaning a JCas instance) was
passed to the constructor w
On 1/4/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> FYI I made updates to the Wiki page - see my comments on the page for
> details.
>
> -Adam
>
>
I probably just missed it, but given a JCasView, how do get the
corresponding JCas?
Thanks for catching that omission. I have
Adam Lally wrote:
FYI I made updates to the Wiki page - see my comments on the page for
details.
-Adam
I probably just missed it, but given a JCasView, how do get the
corresponding JCas?
CasView has a method getCAS().
-Marshall
FYI I made updates to the Wiki page - see my comments on the page for details.
-Adam
Adam Lally wrote:
On 1/4/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
>> - On the JCas interface, can we remove some of the APIs and just make
>> them available on the impl object? I'm thinking of things like
>> putJfsFromCaddr(int, FeatureStructure) and getType(int).
>>
>
> I think these may
On 1/4/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
>> - On the JCas interface, can we remove some of the APIs and just make
>> them available on the impl object? I'm thinking of things like
>> putJfsFromCaddr(int, FeatureStructure) and getType(int).
>>
>
> I think these may be called from JCas
This note is really from Marshall. He's having email trouble so I
posted it on his behalf.
On 1/4/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I would propose the following changes:
- Leave createFeaturePath() and friends at the CAS. These methods
require/return CAS-specific data structures an
I sent this note about a 1/2 hour ago - but it never appeared. I'm
resending, and apologize if it appears twice
-Marshall
Adam Lally wrote:
On 1/4/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I would propose the following changes:
- Leave createFeaturePath() and friends at the CAS. These
Adam Lally wrote:
On 1/4/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> The process call would take a CAS. Inside the body of the process()
> method there would be no issue, but I'm thinking about other methods
> that the user has implemented that need access to the indexes and
Adam Lally wrote:
On 1/4/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I would propose the following changes:
- Leave createFeaturePath() and friends at the CAS. These methods
require/return CAS-specific data structures and don't need to be
accessible anywhere else.
Marshall had already moved
On 1/4/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> The process call would take a CAS. Inside the body of the process()
> method there would be no issue, but I'm thinking about other methods
> that the user has implemented that need access to the indexes and also
> need to crea
Adam Lally wrote:
The process call would take a CAS. Inside the body of the process()
method there would be no issue, but I'm thinking about other methods
that the user has implemented that need access to the indexes and also
need to create new FS. I'm sure there are tons of these. IMO having
On 1/4/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> On 1/4/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
...
> Another open issue is the createFS method and variants. I have left
> them off of the view API for now in deference to Thilo's "no
> convenience methods" suggestion, but
Adam Lally wrote:
On 1/4/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
...
Another open issue is the createFS method and variants. I have left
them off of the view API for now in deference to Thilo's "no
convenience methods" suggestion, but I'm still a little unsure.
Basically the situation now i
On 1/4/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I would propose the following changes:
- Leave createFeaturePath() and friends at the CAS. These methods
require/return CAS-specific data structures and don't need to be
accessible anywhere else.
Marshall had already moved these to CommonCas,
Adam Lally wrote:
I put up a Wiki page giving the suggested breakdown of methods between
the existing interfaces CommonCas, CAS, JCas and new interfaces
CommonCasView, CasView, and JCasView. Please take a look:
http://cwiki.apache.org/UIMA/casandcasviewinterfaceredesign.html.
-Adam
I would pr
I put up a Wiki page giving the suggested breakdown of methods between
the existing interfaces CommonCas, CAS, JCas and new interfaces
CommonCasView, CasView, and JCasView. Please take a look:
http://cwiki.apache.org/UIMA/casandcasviewinterfaceredesign.html.
-Adam
Thilo Goetz wrote:
Unfortunately, the low-level CAS is missing the base CAS
functionality. All the sofa/view stuff was implemented at the CAS
level only. This is something that should be fixed.
My understanding of the low-level interfaces is that they are there to
support the no-Java-object
Adam Lally wrote:
On 1/2/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
The CAS has a getLowLevelCAS() method; the low level CAS includes both
things for FSs and also for IndexRepositories.
The index repository things should be looked at carefully to see if they
should go with the "view" (with
Marshall Schor wrote:
Will the methods not really associated with a CAS object (they are or
could be
static methods) still be on the CAS or CommonCas:
createFilteredIterator, getConstraintFactory, createFeaturePath,
createFeatureValuePath, and fs2listIterator
I suggest that the methods
On 1/2/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
I think this proposal also has one set of index "definitions", and each view
gets its own private set of index-instances for these definitions.
Correct.
Will the methods not really associated with a CAS object (they are or
could be
static
Adam Lally wrote:
On 1/2/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I wouldn't mind doing this as a first step, but I'm concerned about the
future. If we need to support this approach going forward, I would
prefer if we could answer the questions about the relation between the
CAS and CasViews
On 1/2/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I wouldn't mind doing this as a first step, but I'm concerned about the
future. If we need to support this approach going forward, I would
prefer if we could answer the questions about the relation between the
CAS and CasViews first: how are inde
Adam Lally wrote:
On 12/30/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:
So your proposal is to leave things as they are, except that we call
some of the things that we used to call a CAS a CasView. We're not
going to touch how indexing works, at least conceptually. We could
implement this propos
On 12/30/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:
So your proposal is to leave things as they are, except that we call
some of the things that we used to call a CAS a CasView. We're not
going to touch how indexing works, at least conceptually. We could
implement this proposal by simply making
So your proposal is to leave things as they are, except that we call
some of the things that we used to call a CAS a CasView. We're not
going to touch how indexing works, at least conceptually. We could
implement this proposal by simply making the CASImpl class implement the
CasView interface
On 12/29/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
It seems to me you will need a CasViewImpl class - this is for the use
case where the user
wants to, e.g., run two iterators together, one iterating over one view,
while the other goes over
another view.
The actual objects that implement CA
More on hierarchies of implementation objects, and saving the user from
writing dereferencing chains:
Suppose we divide the CAS methods into those which would just not make sense
on the CasView API, and "others". In the same spirit of pleasing the
users by avoiding what they
could see as unnec
My Condensation (small is beautiful :-) ):
1) Add CasView interface - sounds good.
a) this interface is where the user APIs for Sofa and Index things
will live,
since a View is all about Index-sets, and (for now) also has a
Sofa (always, for now).
b) CAS has getView( ... ) same i
Well, the concrete may not have quite set yet... but here goes:
1. Goals
The following are confusing (or some might say, "broken")
(a) the interface "CAS" can be an interface to either the whole CAS or to a
view. Methods like this are poor:
CAS view = cas.getView(name);
(b) the logic determi
38 matches
Mail list logo
