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 would
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 multi-sofa.
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 was
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
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:
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 is
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:
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
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
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 also
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 and
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
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 added
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
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
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
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
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
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
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
Marshall Schor wrote:
snip
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
Adam Lally wrote:
On 1/2/07, Marshall Schor [EMAIL PROTECTED] wrote:
snip
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
Thilo Goetz wrote:
snipUnfortunately, 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
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
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
On 12/29/06, Marshall Schor [EMAIL PROTECTED] wrote:
snip/
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
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
27 matches
Mail list logo
