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 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
