Adam Lally wrote: > On 5/25/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: >> I would like to revive the discussion that started with >> http://www.mail-archive.com/uima-dev@incubator.apache.org/msg01299.html >> > > I still have the same concern about this that I posted to the previous > thread: > > I think Michael is onto the same point that concerns me. To use this > feature, components have to agree on what variable names they are > going to use. So we're creating another kind of dependency that I > believe should be documented in the capabilities. Sure, people could > build this themselves already, but if we make it built-in then we're > strongly encouraging its use and should consider all the implications. > If we had more expressive capability spec (so you could say I > create/require an instance of type FsVariable with name="Foo") then > that might be a way to go. > > Thilo replied: >> I guess we could do that in addition. How would you imagine this would >> work? > >> I'm mainly addressing a practical problem here, and want to give > people a viable >> alternative to modifying the DocumentAnnotation. I think this > approach is fairly >> forward-compatible as well, in the sense that it can later be > strengthened with >> descriptor-based integrity constraints. > > > Actually I'm not happy about making the capabilities more complicated > to handle this. I'm not sure the benefits of global variables > outweigh either (a) making the capabilities more complicated or (b) > adding/encouraging another set of implicit agreements between > annotators that aren't declared anywhere. > > Let's go back and think about the DocumentAnnotation use case. Users > can already declare their own document metadata type and add it to the > indexes. Now that we have default bag indexes this is easy to do even > if their document metadata type does not extend annotation. > > I think this is most of the way towards addressing the issue. What > remains are (a) providing convenient access to a single indexed > object, without going through an iterator, and (b) enforcing that > there is only ever a singleton instance of a particular type. > > Another suggestion for addressing these issues: > void CAS.indexSingleton(FeatureStructure aFS) throws CASException > FeatureStructure CAS.getSingleton(Type aType) throws CASException > > The former is defined to throw an exception if the index over > aFS.getType() is non-empty (for this view - we can have a separate > "singleton" for each index repository - I think that is what we want > for DocumentAnnotation), and otherwise to add aFS to the indexes. > > The latter is defined to throw an exception if there is not exactly > one instance of aType in the indexes for this view, and otherwise to > return the one instance. > > > > I like this better since it doesn't introduce yet another "name space" > that annotators have to agree on amongst each other.
That approach is too brittle for my taste. An annotator writer would declare a type that is meant to be a singleton, but there's no way to enforce this. One careless annotator that creates a second instance of such a type, and the whole analysis chain stops working. With my approach, at least the bar is a bit higher. --Thilo > > -Adam
