Transcription view and configuring which columns' names/types are displayed

Hi there,

Within the transcription view, when configuring which columns are displayed, we have to select them using their type’s name. The problem is that when we have multiple columns with the same type, it is a bit confusing and we only see one name for various different columns.

Reusing the same type for various tiers of the same type make sense for me as a programmer, but within ELAN’s interface, it is rather confusing.

Example:

In this example, you can see that only two names are displayed when configuring the columns. It is a bit confusing. One solution could be to display both type and tier’s name.

I guess the issue is not so common as most linguists will not have this kind of very parallel structures, but this is one of the very strong quality of ELAN, it’s annotation structure flexibility.

Hi,

It seems to me that many linguists could have similar structures as shown in your example. But, although it is possible and makes some sense to create only one tier type per “super type” (Stereotype) and use that for all tiers that are of that stereotype, I guess that many users would choose to define separate tier types (of the same stereotype) for tiers that are used for different phenomena.

I don’t see an easy solution here; in your example it would indeed be possible to show the tier name or the type and tier name in the column headers, but in other set-ups this would be very impractical. E.g. in multi-speaker transcriptions there could be tiers “A_Translation”, “B_Translation” and “C_Translation” in one and the same “Translation” column; all those names probably wouldn’t fit in the header.

In many situations, not only in transcription mode and not only in multiple participant situations, there are certain advantages to creating multiple types (of the same stereotype) for tiers used for different phenomena. E.g. as selection criterion for sorting, showing and hiding of tiers, creation of statistics, export etc.

Definitely, you’re right. As specifying fine grained tier types is required for many tasks/analysis, this point is really not an important issue.