You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Adam Lally <al...@alum.rpi.edu> on 2006/12/28 22:45:08 UTC
CAS and CasView redesign - taking a step back
This chain of emails has a lot of tangled threads and this is an
attempt to disentangle them and reevaluate what it we're trying to
acheive.
I think there were basically two motivations for the whole ball of yarn:
(1) We're unhappy with some of our APIs, in particular (a) the
interface "CAS" can be an interface to either the whole CAS or to a
view, and (b) the logic determining which "CAS" gets passed to an
annotator's process method is confusing. We have a rare opportunity to
clean some of this up in v2.1.
(2) We want to come up with a clean, consistent design for the CAS
that is consistent with the current OASIS UIMA Specification proposal.
Primarily I'm the one who has been pushing (2), but I think I've been
getting a little ahead of myself on that front. I'm getting myself
into the position of trying to be the advocate of what's in the UIMA
spec and convincing the other committers (well mostly Thilo, as he is
the one giving this the most attention) that they make sense. But
that does not seem like the right way to go about this.
Taking a step back, the way this process ought to work is that the
interested parties should work with the OASIS UIMA TC to produce an
architecture spec that's agreeable, and then we'll figure out how to
implement it. We can have discussions amongst the implementers here,
but in the end we can't really decide any architecture issues on our
own. It would not make sense for us to implement any major new
designs unless we're sure they're going to be consistent with the
forthcoming UIMA specification.
So, in the coming months we need to make a significant effort to work
with the OASIS UIMA TC on devising a CAS model that we can agree to.
In the mean time, I think we should take off the table for 2.1 any
significant realignment of the implementation with the spec.
That being said, we still have this opportunty to do address some of
our API issues (1) in v2.1, and I don't want to waste it. I think we
should look at our most serious API issues and see if anything can be
done about them. If there are things that we would otherwise want to
do, and those things happen to be consistent with the current spec
proposal, then great, we can do them now. But unless both of those
conditions are met I think we may want to sit on our hands for now.
Does that make sense?
-Adam
Re: CAS and CasView redesign - taking a step back
Posted by Adam Lally <al...@alum.rpi.edu>.
On 1/2/07, Thilo Goetz <tw...@gmx.de> wrote:
> Adam Lally wrote:
> > On 1/2/07, Thilo Goetz <tw...@gmx.de> wrote:
> >> <snip/>
> >> I'm not sure there's a contradiction between what I'm proposing,
> >> and what's in the spec proposal. When I run an Apache UIMA application,
> >> I make the decision what I want to see in my CAS. Any other application
> >> deserializing XMI files may do the same. In Apache UIMA, we can just
> >> call addToIndex() on each FS we deserialize.
> >
> > Hmmm... well, that last sentence is a key new idea I didn't get.
> > Maybe that could be OK, but it does seem to have some strange effects.
>
> As we don't seem to have indexing info in XMI, what else can we do?
>
> > Say in Apache UIMA I create an FS of a type that has an index defined
> > for it, but I never call addToIndexes for that FS. The FS will not be
> > in the index. Now say I create a reference to that FS so it's
> > reachable from something that's indexed, then do a XMI serialization
> > and deserialization. Now my FS will be in the index? Did I get that
> > right?
>
> Right. As long as we don't have indexing info in the XMI format,
> there's no way we can get that distinction right. Don't we have an
> "indexed" attribute in XCAS? Did that get lost in the transition to XMI?
>
> > Also this seems to imply that we must allow the user to define some
> > kind of "global" indexes where such FS will go - right now we have no
> > such thing.
>
> I believe you said that views are entirely optional in the spec
> proposal, so we'll need global (non-view) indexes, anyway.
>
OK, I think we've come to an understanding of the issues here, and the
impact that the XMI serialization format has on what we implement in
this area.
XCAS had an attribute _indexed=n, where n is a number indicating which
view the FS is indexed in. In XMI this changed to a View element that
lists the members. Partly that's due to the XMI specification itself,
but also it's because "indexed" isn't a concept in the OASIS UIMA spec
proposal.
I'll think on this some more.
-Adam
Re: CAS and CasView redesign - taking a step back
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
> On 1/2/07, Thilo Goetz <tw...@gmx.de> wrote:
>> <snip/>
>> I'm not sure there's a contradiction between what I'm proposing,
>> and what's in the spec proposal. When I run an Apache UIMA application,
>> I make the decision what I want to see in my CAS. Any other application
>> deserializing XMI files may do the same. In Apache UIMA, we can just
>> call addToIndex() on each FS we deserialize.
>
> Hmmm... well, that last sentence is a key new idea I didn't get.
> Maybe that could be OK, but it does seem to have some strange effects.
As we don't seem to have indexing info in XMI, what else can we do?
> Say in Apache UIMA I create an FS of a type that has an index defined
> for it, but I never call addToIndexes for that FS. The FS will not be
> in the index. Now say I create a reference to that FS so it's
> reachable from something that's indexed, then do a XMI serialization
> and deserialization. Now my FS will be in the index? Did I get that
> right?
Right. As long as we don't have indexing info in the XMI format,
there's no way we can get that distinction right. Don't we have an
"indexed" attribute in XCAS? Did that get lost in the transition to XMI?
> Also this seems to imply that we must allow the user to define some
> kind of "global" indexes where such FS will go - right now we have no
> such thing.
I believe you said that views are entirely optional in the spec
proposal, so we'll need global (non-view) indexes, anyway.
--Thilo
Re: CAS and CasView redesign - taking a step back
Posted by Adam Lally <al...@alum.rpi.edu>.
On 1/2/07, Thilo Goetz <tw...@gmx.de> wrote:
> <snip/>
> I'm not sure there's a contradiction between what I'm proposing,
> and what's in the spec proposal. When I run an Apache UIMA application,
> I make the decision what I want to see in my CAS. Any other application
> deserializing XMI files may do the same. In Apache UIMA, we can just
> call addToIndex() on each FS we deserialize.
Hmmm... well, that last sentence is a key new idea I didn't get.
Maybe that could be OK, but it does seem to have some strange effects.
Say in Apache UIMA I create an FS of a type that has an index defined
for it, but I never call addToIndexes for that FS. The FS will not be
in the index. Now say I create a reference to that FS so it's
reachable from something that's indexed, then do a XMI serialization
and deserialization. Now my FS will be in the index? Did I get that
right?
Also this seems to imply that we must allow the user to define some
kind of "global" indexes where such FS will go - right now we have no
such thing.
> It's the user's decision
> what they want to see, and what they're not interested in. Indexes are
> a basic concept in Apache UIMA, and just like we require FSs to be
> indexed to be visible to the next annotator, we can expect FSs to be
> indexed to visible to (de)serialization.
>
> Surely all the spec requires is that all FSs _can_ be deserialized.
>
Yes, that's what I was concerned about -- FS that appear in the XMI
but aren't in any view not being accessible. If we handle them by
calling addToIndexes() on everything in the XMI this would not longer
be a concern, but that raised other concerns as noted above.
> >> > (2) If we decided to add some kind of global indexes to our
> >> > implementation (as was being recently discussed), that has no
> >> > representation in the XMI serialization. This seems like a problem to
> >> > me. How can we add things to our implementaiton that are supposed to
> >> > be persistent across CAS serialization without opening up a discussion
> >> > of what the serialization format looks like?
> >>
> >> I didn't look at the details of the XMI proposal because frankly, I'm
> >> not very interested in XML serialization. The conceptual part of the
> >> report does not contradict that approach, at least the way I read it. I
> >> probably missed something. Where does it say you can't have global
> >> indexes (or the OASIS equivalent thereof)?
> >
> > The OASIS spec proposal only defines views. In our implementation we
> > define indexes and say that we have an index repository per view and
> > that the members of the view are indexed in that index repository. If
> > a "global index" means an index containing objects that are in no
> > view, then this approach no longer works.
>
> What approach no longer works? The spec proposal or our implementation?
> The spec proposal says that a view is a set of FSs. It doesn't say
> (to my knowledge) that each FS must be contained in at least one view;
> nor does it say that it can be contained in only one view.
>
Sorry, miscommunication there - FS can be in more than one view. To
me "global index" means something different than that the FS belongs
to all views.
> > I really think the XMI serialization is a key intersection point
> > between what we're doing in our CAS implementation and what OASIS is
> > charged with doing. Each group looks at the XMI serialization in a
> > different way - for us developers, we may just want to throw in new
> > attributes or whatever to make our latest, greatest implementation
> > idea work. The people in the OASIS group (at least some of them) look
> > at it as a realization of basic UIMA concepts. That may sometimes
> > become an annoyance for us, since we might like to shape the XMI
> > serialization however we want, but I think ultimately it's a good
> > thing for UIMA.
>
> Sure, but it leaves us with a lot of liberties. In the implementation,
> we can choose what kind of interfaces to the XMI form we offer to our
> users, and what extensions and conveniences we offer on top.
>
Yes, agreed.
> Or, we could change the spec proposal.
>
Yes, I don't mean to rule that out. That would be done by proposing
something over at OASIS, which I'm all for if we figure out what it is
we want to change.
-Adam
Re: CAS and CasView redesign - taking a step back
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
> On 12/30/06, Thilo Goetz <tw...@gmx.de> wrote:
<snip>
>> > (1) The XMI serialization could contain objects that are not in any
>> > view, nor referenced from anywhere. Our implementation doesn't
>> > support that. We'd lose such objects on a deserialization followed by
>> > serialization, and even if we didn't lose them, not providing any APIs
>> > to access them seems poor.
>>
>> I don't see that we would loose such objects. You just define an index
>> over all objects and there you are. That also gives you an API to
>> access them. And no, we should not provide such an index by default.
>> Many, if not most, applications won't need it.
>>
>
> Are you using "define an index" in the same sense as we currently do,
> where someone has to call addToIndexes for something to be indexed?
Yes.
> Or is this a new kind of index that contains everything no matter
> what? I think it would have to be the latter in order to support this
> using the current XMI serialization format (which has no concept of
> index membership separate from view membership). Is that what you
> intended?
No. I'm not sure there's a contradiction between what I'm proposing,
and what's in the spec proposal. When I run an Apache UIMA application,
I make the decision what I want to see in my CAS. Any other application
deserializing XMI files may do the same. In Apache UIMA, we can just
call addToIndex() on each FS we deserialize. It's the user's decision
what they want to see, and what they're not interested in. Indexes are
a basic concept in Apache UIMA, and just like we require FSs to be
indexed to be visible to the next annotator, we can expect FSs to be
indexed to visible to (de)serialization.
Surely all the spec requires is that all FSs _can_ be deserialized.
>> > (2) If we decided to add some kind of global indexes to our
>> > implementation (as was being recently discussed), that has no
>> > representation in the XMI serialization. This seems like a problem to
>> > me. How can we add things to our implementaiton that are supposed to
>> > be persistent across CAS serialization without opening up a discussion
>> > of what the serialization format looks like?
>>
>> I didn't look at the details of the XMI proposal because frankly, I'm
>> not very interested in XML serialization. The conceptual part of the
>> report does not contradict that approach, at least the way I read it. I
>> probably missed something. Where does it say you can't have global
>> indexes (or the OASIS equivalent thereof)?
>
> The OASIS spec proposal only defines views. In our implementation we
> define indexes and say that we have an index repository per view and
> that the members of the view are indexed in that index repository. If
> a "global index" means an index containing objects that are in no
> view, then this approach no longer works.
What approach no longer works? The spec proposal or our implementation?
The spec proposal says that a view is a set of FSs. It doesn't say
(to my knowledge) that each FS must be contained in at least one view;
nor does it say that it can be contained in only one view.
If the XMI part of the spec requires that the views partition the space
of FSs (i.e., each FSs is contained in one and only one view), then
that's a constraint I would like to discuss and propose to change.
> I really think the XMI serialization is a key intersection point
> between what we're doing in our CAS implementation and what OASIS is
> charged with doing. Each group looks at the XMI serialization in a
> different way - for us developers, we may just want to throw in new
> attributes or whatever to make our latest, greatest implementation
> idea work. The people in the OASIS group (at least some of them) look
> at it as a realization of basic UIMA concepts. That may sometimes
> become an annoyance for us, since we might like to shape the XMI
> serialization however we want, but I think ultimately it's a good
> thing for UIMA.
Sure, but it leaves us with a lot of liberties. In the implementation,
we can choose what kind of interfaces to the XMI form we offer to our
users, and what extensions and conveniences we offer on top.
>
> In the case of global indexes the issue with XMI serialization is that
> there's no way to mark an object as being indexed without marking it
> as being a member of a view. Now, I suppose we could just define a
> special view named "global" and be done with it. But then, our APIs
> would (should) be different than if we have special global indexes
> that "belong to no view".
>
> -Adam
Or, we could change the spec proposal.
--Thilo
Re: CAS and CasView redesign - taking a step back
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/30/06, Thilo Goetz <tw...@gmx.de> wrote:
> > Why use the bandwidth to design it here, rather than initiate it at
> > OASIS?
> <snip>
>
> Because things are happening here, and not at OASIS. If and when that
> changes, we can take our discussion there. If you would like to start
> some discussion at OASIS, feel free.
>
I already did, by writing the meat of the spec proposal whitepaper.
I'm waiting for another party so it won't be a discussion of one.
You're right, here we have fully twice as many people participating in
the dicussion! :) Anyway I still think discussing the right things in
the right places will be important to do. I guess it will fall on me
to make that happen.
> > (1) The XMI serialization could contain objects that are not in any
> > view, nor referenced from anywhere. Our implementation doesn't
> > support that. We'd lose such objects on a deserialization followed by
> > serialization, and even if we didn't lose them, not providing any APIs
> > to access them seems poor.
>
> I don't see that we would loose such objects. You just define an index
> over all objects and there you are. That also gives you an API to
> access them. And no, we should not provide such an index by default.
> Many, if not most, applications won't need it.
>
Are you using "define an index" in the same sense as we currently do,
where someone has to call addToIndexes for something to be indexed?
Or is this a new kind of index that contains everything no matter
what? I think it would have to be the latter in order to support this
using the current XMI serialization format (which has no concept of
index membership separate from view membership). Is that what you
intended?
> > (2) If we decided to add some kind of global indexes to our
> > implementation (as was being recently discussed), that has no
> > representation in the XMI serialization. This seems like a problem to
> > me. How can we add things to our implementaiton that are supposed to
> > be persistent across CAS serialization without opening up a discussion
> > of what the serialization format looks like?
>
> I didn't look at the details of the XMI proposal because frankly, I'm
> not very interested in XML serialization. The conceptual part of the
> report does not contradict that approach, at least the way I read it. I
> probably missed something. Where does it say you can't have global
> indexes (or the OASIS equivalent thereof)?
The OASIS spec proposal only defines views. In our implementation we
define indexes and say that we have an index repository per view and
that the members of the view are indexed in that index repository. If
a "global index" means an index containing objects that are in no
view, then this approach no longer works.
I really think the XMI serialization is a key intersection point
between what we're doing in our CAS implementation and what OASIS is
charged with doing. Each group looks at the XMI serialization in a
different way - for us developers, we may just want to throw in new
attributes or whatever to make our latest, greatest implementation
idea work. The people in the OASIS group (at least some of them) look
at it as a realization of basic UIMA concepts. That may sometimes
become an annoyance for us, since we might like to shape the XMI
serialization however we want, but I think ultimately it's a good
thing for UIMA.
In the case of global indexes the issue with XMI serialization is that
there's no way to mark an object as being indexed without marking it
as being a member of a view. Now, I suppose we could just define a
special view named "global" and be done with it. But then, our APIs
would (should) be different than if we have special global indexes
that "belong to no view".
-Adam
Re: CAS and CasView redesign - taking a step back
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
> On 12/29/06, Thilo Goetz <tw...@gmx.de> wrote:
>> I didn't mean ignore; there isn't much to ignore right now ;-) I'm
>> waiting to jump on any technical discussion that might develop there,
>> but there is nothing. I don't have the bandwidth to initiate anything
>> myself. However, I'm certainly prepared to sell anything to the OASIS
>> TC that we develop here.
>>
>
> Why use the bandwidth to design it here, rather than initiate it at
> OASIS?
<snip>
Because things are happening here, and not at OASIS. If and when that
changes, we can take our discussion there. If you would like to start
some discussion at OASIS, feel free.
> The genesis of views was to be consistent with what we're doing with
> indexes. So adding objects to our indexes is supposed to be
> interpreted that the objects were "directly asserted to be in the
> view". But consider the following things which aren't quite in sync:
>
> (1) The XMI serialization could contain objects that are not in any
> view, nor referenced from anywhere. Our implementation doesn't
> support that. We'd lose such objects on a deserialization followed by
> serialization, and even if we didn't lose them, not providing any APIs
> to access them seems poor.
I don't see that we would loose such objects. You just define an index
over all objects and there you are. That also gives you an API to
access them. And no, we should not provide such an index by default.
Many, if not most, applications won't need it.
>
> (2) If we decided to add some kind of global indexes to our
> implementation (as was being recently discussed), that has no
> representation in the XMI serialization. This seems like a problem to
> me. How can we add things to our implementaiton that are supposed to
> be persistent across CAS serialization without opening up a discussion
> of what the serialization format looks like?
I didn't look at the details of the XMI proposal because frankly, I'm
not very interested in XML serialization. The conceptual part of the
report does not contradict that approach, at least the way I read it. I
probably missed something. Where does it say you can't have global
indexes (or the OASIS equivalent thereof)?
--Thilo
Re: CAS and CasView redesign - taking a step back
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/29/06, Thilo Goetz <tw...@gmx.de> wrote:
> I didn't mean ignore; there isn't much to ignore right now ;-) I'm
> waiting to jump on any technical discussion that might develop there,
> but there is nothing. I don't have the bandwidth to initiate anything
> myself. However, I'm certainly prepared to sell anything to the OASIS
> TC that we develop here.
>
Why use the bandwidth to design it here, rather than initiate it at
OASIS? For things that don't overlap with OASIS, that's OK. But for
things that do overlap, we have a choice as to how to proceed.
Figuring out how to do that is what I'm trying to explore. We need to
form some kind of working relationship that makes sense here. Merely
trying to sell what we've implemented doesn't seem like a strategy
that will be effective in all cases. (When I said that originally, I
said we should be confident that we *can* successfully sell it, not
just that we would try. And that probably only can be the case for
fairly obvious things.)
> The Research report talks mostly about XMI serialization. If that is
> all the standard will amount to, we have a pretty free hand with our
> APIs, as long as we can produce and digest the XMI format.
Yes, that's right. The spec is concerned with the basic structure of
the CAS, which is visible when you look at its XMI serialization. So
yes, any APIs should be fine as long as we support the basic structure
that's embodied in the XMI.
> I've been
> rereading what the report says about views. Basically all it says is
> that a view is a set of FSs. Or to be more precise: "By members we mean
> as defined above, those Objects directed asserted to be in the View not
> necessarily Objects that may be in the Views reference closure and not
> in the View" (p. 39, footnote 5; had to type as content of report is not
> copyable). I won't pretend I understand what that means, but under most
> reasonable interpretations, we are not very much constrained as to how
> we structure our APIs to be consistent with this.
>
The genesis of views was to be consistent with what we're doing with
indexes. So adding objects to our indexes is supposed to be
interpreted that the objects were "directly asserted to be in the
view". But consider the following things which aren't quite in sync:
(1) The XMI serialization could contain objects that are not in any
view, nor referenced from anywhere. Our implementation doesn't
support that. We'd lose such objects on a deserialization followed by
serialization, and even if we didn't lose them, not providing any APIs
to access them seems poor.
(2) If we decided to add some kind of global indexes to our
implementation (as was being recently discussed), that has no
representation in the XMI serialization. This seems like a problem to
me. How can we add things to our implementaiton that are supposed to
be persistent across CAS serialization without opening up a discussion
of what the serialization format looks like?
> So again, I'm not advocating we ignore the OASIS TC. All I'm saying is
> that next to no work has happened on OASIS yet. The Research report was
> written pre-OASIS, as we all know. We shouldn't go off in a direction
> that totally contradicts the report, but I see no danger of that.
>
> I think we can straighten out some of our APIs surrounding views and sofas
> without being too much concerned with OASIS at this point.
>
I see the two things I said above as being dangers/concerns that are
related to OASIS.
-Adam
Re: CAS and CasView redesign - taking a step back
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
> I think it would be unwise to ignore the OASIS TC. If we want to do
> something different than what the OASIS TC is currently thinking (as
> embodied by the research report at this point), and we're confident
> it's the right thing, OK -- but then we need to be prepared to sell it
> to the OASIS TC and be confident that we can sell it successfully.
I didn't mean ignore; there isn't much to ignore right now ;-) I'm
waiting to jump on any technical discussion that might develop there,
but there is nothing. I don't have the bandwidth to initiate anything
myself. However, I'm certainly prepared to sell anything to the OASIS
TC that we develop here.
The Research report talks mostly about XMI serialization. If that is
all the standard will amount to, we have a pretty free hand with our
APIs, as long as we can produce and digest the XMI format. I've been
rereading what the report says about views. Basically all it says is
that a view is a set of FSs. Or to be more precise: "By members we mean
as defined above, those Objects directed asserted to be in the View not
necessarily Objects that may be in the Views reference closure and not
in the View" (p. 39, footnote 5; had to type as content of report is not
copyable). I won't pretend I understand what that means, but under most
reasonable interpretations, we are not very much constrained as to how
we structure our APIs to be consistent with this.
So again, I'm not advocating we ignore the OASIS TC. All I'm saying is
that next to no work has happened on OASIS yet. The Research report was
written pre-OASIS, as we all know. We shouldn't go off in a direction
that totally contradicts the report, but I see no danger of that. I
think we can straighten out some of our APIs surrounding views and sofas
without being too much concerned with OASIS at this point.
I had expected the UIMA standard would define interfaces like, for
example, the CORBA or the XML DOM standards do. There's nothing like
that in the report, and I'm beginning to think there won't be anything
like that in the standard; it would be a huge amount of work. So even
in the future, I see ourselves relatively free in how we design our APIs.
--Thilo
Re: CAS and CasView redesign - taking a step back
Posted by Adam Lally <al...@alum.rpi.edu>.
On 12/29/06, Thilo Goetz <tw...@gmx.de> wrote:
> Also, I don't feel like second-guessing the OASIS TC at this point. We
> have nothing but the Research report to on right now, and every reason
> to believe that it will change significantly before morphing into a
> standard.
>
I'm not sure I get what you mean by "second-guessing" in this context...
I think it would be unwise to ignore the OASIS TC. If we want to do
something different than what the OASIS TC is currently thinking (as
embodied by the research report at this point), and we're confident
it's the right thing, OK -- but then we need to be prepared to sell it
to the OASIS TC and be confident that we can sell it successfully.
That's my main point here. Personally, I don't want to hammer out
complex fundamental architecture issues here between just the three of
us, implement them, and then go try to convince the others on the
OASIS TC that we did the right thing.
Besides, we've got more than enough to worry about in the short term
without getting into "fundamental architecture issues".
> UIMA 2.0 ;-) Seriously, if you have any concrete proposals, let's hear
> them.
>
? Did you mean 3.0? or 2.2? Anyway, concrete proposal will be in the
next email.
-Adam
Re: CAS and CasView redesign - taking a step back
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
> Adam Lally wrote:
>> This chain of emails has a lot of tangled threads and this is an
>> attempt to disentangle them and reevaluate what it we're trying to
>> acheive.
>>
>> I think there were basically two motivations for the whole ball of yarn:
>> (1) We're unhappy with some of our APIs, in particular (a) the
>> interface "CAS" can be an interface to either the whole CAS or to a
>> view, and (b) the logic determining which "CAS" gets passed to an
>> annotator's process method is confusing. We have a rare opportunity to
>> clean some of this up in v2.1.
> Part of the unhappiness for me is that what we've done is complex, hard
> to describe
> and document. +1 to the "rare opportunity" to clean some of this up.
>>
>>
>> (2) We want to come up with a clean, consistent design for the CAS
>> that is consistent with the current OASIS UIMA Specification proposal.
>>
>>
>> Primarily I'm the one who has been pushing (2), but I think I've been
>> getting a little ahead of myself on that front. I'm getting myself
>> into the position of trying to be the advocate of what's in the UIMA
>> spec and convincing the other committers (well mostly Thilo, as he is
>> the one giving this the most attention) that they make sense. But
>> that does not seem like the right way to go about this.
>>
>> Taking a step back, the way this process ought to work is that the
>> interested parties should work with the OASIS UIMA TC to produce an
>> architecture spec that's agreeable, and then we'll figure out how to
>> implement it. We can have discussions amongst the implementers here,
>> but in the end we can't really decide any architecture issues on our
>> own. It would not make sense for us to implement any major new
>> designs unless we're sure they're going to be consistent with the
>> forthcoming UIMA specification.
I think we need to be a bit more forward-thinking than that. The OASIS
work is and will be informed by the Apache UIMA implementation, to a
significant degree. If we come up with new and better ideas, and those
ideas are validated in practice, they will find their way into the OASIS
spec. If what we do is not accepted by our users, it won't go in the
standard and we'll have to change it as well.
> My worry with this line of thinking is that it may take a very long time
> for the OASIS process to converge. But I would like what we come up
> with to be in line with what we think the TC would eventually get to.
I'm a bit worried by the complete lack of anything going on over on
OASIS. This could be due to the holiday season, but it could also be an
indication of how quickly things are going to move in the future.
Also, I don't feel like second-guessing the OASIS TC at this point. We
have nothing but the Research report to on right now, and every reason
to believe that it will change significantly before morphing into a
standard.
>>
>>
>> So, in the coming months we need to make a significant effort to work
>> with the OASIS UIMA TC on devising a CAS model that we can agree to.
>> In the mean time, I think we should take off the table for 2.1 any
>> significant realignment of the implementation with the spec.
+1
> I think I agree here - the focus should be on making the APIs sensible,
> easily understandable, and well architected (whatever that means :-) )
>
>>
>>
>> That being said, we still have this opportunty to do address some of
>> our API issues (1) in v2.1, and I don't want to waste it. I think we
>> should look at our most serious API issues and see if anything can be
>> done about them. If there are things that we would otherwise want to
>> do, and those things happen to be consistent with the current spec
>> proposal, then great, we can do them now. But unless both of those
>> conditions are met I think we may want to sit on our hands for now.
>>
>> Does that make sense?
> Yes. Next step is to actually take a crack at stating the "most serious
> API issues".
>
> -Marshall
UIMA 2.0 ;-) Seriously, if you have any concrete proposals, let's hear
them.
--Thilo
Re: CAS and CasView redesign - taking a step back
Posted by Marshall Schor <ms...@schor.com>.
Adam Lally wrote:
> This chain of emails has a lot of tangled threads and this is an
> attempt to disentangle them and reevaluate what it we're trying to
> acheive.
>
> I think there were basically two motivations for the whole ball of yarn:
> (1) We're unhappy with some of our APIs, in particular (a) the
> interface "CAS" can be an interface to either the whole CAS or to a
> view, and (b) the logic determining which "CAS" gets passed to an
> annotator's process method is confusing. We have a rare opportunity to
> clean some of this up in v2.1.
Part of the unhappiness for me is that what we've done is complex, hard
to describe
and document. +1 to the "rare opportunity" to clean some of this up.
>
>
> (2) We want to come up with a clean, consistent design for the CAS
> that is consistent with the current OASIS UIMA Specification proposal.
>
>
> Primarily I'm the one who has been pushing (2), but I think I've been
> getting a little ahead of myself on that front. I'm getting myself
> into the position of trying to be the advocate of what's in the UIMA
> spec and convincing the other committers (well mostly Thilo, as he is
> the one giving this the most attention) that they make sense. But
> that does not seem like the right way to go about this.
>
> Taking a step back, the way this process ought to work is that the
> interested parties should work with the OASIS UIMA TC to produce an
> architecture spec that's agreeable, and then we'll figure out how to
> implement it. We can have discussions amongst the implementers here,
> but in the end we can't really decide any architecture issues on our
> own. It would not make sense for us to implement any major new
> designs unless we're sure they're going to be consistent with the
> forthcoming UIMA specification.
My worry with this line of thinking is that it may take a very long time
for the OASIS process to converge. But I would like what we come up
with to be in line with what we think the TC would eventually get to.
>
>
> So, in the coming months we need to make a significant effort to work
> with the OASIS UIMA TC on devising a CAS model that we can agree to.
> In the mean time, I think we should take off the table for 2.1 any
> significant realignment of the implementation with the spec.
I think I agree here - the focus should be on making the APIs sensible,
easily understandable, and well architected (whatever that means :-) )
>
>
> That being said, we still have this opportunty to do address some of
> our API issues (1) in v2.1, and I don't want to waste it. I think we
> should look at our most serious API issues and see if anything can be
> done about them. If there are things that we would otherwise want to
> do, and those things happen to be consistent with the current spec
> proposal, then great, we can do them now. But unless both of those
> conditions are met I think we may want to sit on our hands for now.
>
> Does that make sense?
Yes. Next step is to actually take a crack at stating the "most serious
API issues".
-Marshall