Restricting scope of Multiple Layer Search to a single supra-annotation

jkw1 · 15 December 2022 17:40

I have a question about restricting a search using Multiple Layer Search in RegEx mode so that hits found when using search criteria for more than one annotation on a symbolic-subdivision-type subordinate tier must share the same superordinate parent tier annotation (actually, the same question would apply for Time Subdivision and Included In types, too).
In other words, is it possible to restrict the search to only search on subordinate tier annotations within and not across super-ordinate tier annotations. As far as I can tell, this is not possible, and I have spent a lot of time and testing with my ELAN files and looking in the forum, but maybe I’m missing something…

To illustrate the situation, here is a very minimal and abstracted version of the tier structure I use for each speaker in my ELAN files:
orth@speakerX (orthographic transcription; root tier)
morph@speakerX (for morphological categories; child tier of parent tier orth@speakerX using the symbolic subdivision type)

So I want to search my ELAN corpus for all instances of the sequence nom.sg followed by acc.pl, but only when these occur in the same sentence.
In other words, I want ELAN to find example (1) from above, but not example (2).

Here is what I would try to do for this in the Multiple Layer Search in RegEx:

(NB: as I understand it, variable match mode does not work because it looks for different annotations with the same value, and not the same single annotation.)

Conceptually, this is what the search interface would look like to do this kind of search:

Is this even possible? It’s complicated to describe this, and I hope my question and the examples with the manipulated screen shots make sense.

Joshua

hasloe · 19 December 2022 08:37

Hello Joshua,

Yes, your question and example make perfect sense, this is already on our wish list. Unfortunately we didn’t find much time recently to work on the multiple file search and implementation of the proposed improvement will require a fair amount of development time. Both for reworking the user interface part of it and for the query construction part of it.

Your second (mock up) screenshot illustrates the ideal layout of the user interface for that type of queries. Currently the query text fields and drop down boxes are in a relatively simple table-like grid. If text fields are to be able to span multiple columns, thorough changes are required. Since more columns and layers can be added, ideally it would also be possible to span more than two subordinate fields and there may be no reason why it wouldn’t be allowed to also have fields spanning multiple columns on other layers than the top layer. Several additional consistency check would be required too.
I have been thinking of a sub-optimal solution for the user interface, where the “Constraint” drop down box (between two fields on the same layer) would have an additional constraint, something like “Same annotation” which would disable the next text field, without changing the entire layout, but this is not really nice and clear from a user’s perspective.

And then there are the required changes in the query construction part and result visualisation part, I won’t even go into that now.

In other words; yes this would be useful and we would like to implement this, but I have no idea when we will be able to implement this.

-Han

jkw1 · 19 December 2022 12:25

Thanks for the thorough answer, Han!
To me, a constraint like “same annotation” actually seems like a good, clear solution. I think that users who use this complex interface should be able to understand what this implies. Maybe you could make the second box (the one sharing the annotation) automatically copy whatever is written in the first box, to highlight the fact that it’s the same.

In any case, I look forward to the day when this type of search is possible in ELAN.

Joshua