On 12/22/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
If we had filtering predicates as part of an index specification, then we could create indexes over subsets of types quite arbitrarily. Could this more general mechanism serve this purpose better than views?
I'm not sure what you mean, "subets of types". Do you mean "subsets of objects (FeatureStructures)", as in a filter that checks arbitrary feature values to decide whether an object gets added to the index? Could be... this sounds like it's saying that an index is a way to optimize what could be implemented by an annotator using a filter over all FS in the CAS followed by a sort.
> Going back to my hypothetical annotator that created an annotation off > the base CAS by calling CAS.createAnnotation(begin, end, Sofa). In > our current implementation this isn't useful because the annotation > has to be indexed to be retrievable, and the only way to index it is > to add it to a view. Are there any other options we could consider This doesn't seem correct: an annotation doesn't have to be indexed to be retrievable - it could be referenced by some chain of FS, with the starting FS of course being indexed So I could have an FSArray for instance, of Annotations, and index the FSArray.
Yes, of course; I glossed over that detail. I don't think it really affects my point, though. The only way to index the FSArray containing my annotation would be to add it to a view, which I don't want to do. Is there a way to make my Annotation accessible from the base CAS without having to go through a view first?
Indexes are sometimes used as a performance optimization, but other times they're part of a component's logic - as when a component depends on a particular sorting order.
The annotator could do the sorting itself. But I'll correct my statement to say that indexes are both a performance optimization and a convenience. -Adam
