On 1/2/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> On 1/2/07, Thilo Goetz <[EMAIL PROTECTED]> 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
