> On 14.11.2017, at 00:04, Marshall Schor <[email protected]> wrote: > > One thing to consider is where this functionality ought best to go.
I'm not even sure if the idea is a good one, but at least good enough to be discussed ;) Mind that the scenario I have in mind is not an application-level scenario, but rather a type-system-level scenario. Consider a component collection such as DKPro Core which comes with a type system and a large number of components. It requires quite a bit of effort to ensure that all components adhere to the same consistency rules. And it requires a lot of redundant code to always set the features in the same consistent way. So it is not only to "check" if consistency is maintained, but rather to "instill" consistency. To take the example of the Dependency type I made before, the "hook" could automatically set the offsets of the Dependency feature structure to the offsets of the Token annotation of referred to by the "Dependent" feature. That could help removing redundant code. Another option would be to factor that code out into some kind of factory class and have components call that factory instead of creating annotations directly. But DKPro Core would end up with lots of such factories. Hence I thought, maybe this kind of redundant consistency-keeping code is something that others might have as well and that might be something to be addressed by the framework. In order to "check" consistency, DKPro Core includes a modular consistency checking subsystem which is used during unit testing. So I was imagining some kind of registration mechanism where one could tell UIMA "if an annotation of type X is added to the indexes, please call this code" - and "this code" could then e.g. fill in some feature values automatically and/or check for consistency in the already filled values. Cheers, -- Richard
