Hit marking in HTML visualizations

[amir-zeldes]

There should be a special way to configure hit marking in the HTML visualizations. Regions of tokens overlapping any hit node (#1, #2 etc.) should be either unmarked, marked in one color (default red) or marked in the standard ANNIS hit colors with the standard color overlap behavior (red, purple, green, etc.). If the last possibility is difficult, an implementation of the uniform coloring (one color) might be preferred as a first step.

A syntax suggestion for the config file:

tok span; style="tok"
annis:hit none
...

Or

annis:hit red #(if an unknown color is used, default is "red")

Or

annis:hit multicolor #(usual behavior with red, purple, green)

Within the HTML visualizations we should allow the marking strategy to use token-wise elements (so a separate coloring element for each red token etc.) as suggested in issue #104 for tokenwise HTML spans. This could look like this:

annis:hit red; tokenwise

This generates (never mind what element is realized with):

bla bla my hit bla bla

Instead of:

bla bla my hit bla bla

Both options should be available, as some visualizations might work better with the first options and some with the second.

[amir-zeldes]

Updated specification:

We should plan for two scenarios, at least for an initial prototype:

1. Hit marking should be colored by ANNIS colors by default in HTML vis. To do this, add the standard ANNIS hit marking CSS classes (just like v-table-cell-content-match_1 in the grid/kwic visualizer) and the colors are inherited from the ANNIS stylesheet. It should be possible to turn off this behavior in resolver_vis_map using a mapping, so it could say: config:dipl;hitmarking:false
2. In the second scenario, the user wants to add special formatting to their HTML visualizer's hits. As a simple example, let's say they want the hits to be bold. This is orthogonal to the hit marking colors, so they can still receive colors based on default hitmarking, unless it's been configured to false in resolver_vis_map. The syntax for hit formatting rules could look like this in the visualizer's .config file:

annis:HIT   span; style="my_hit_style"

As usual, leaving the third column of the config file empty just means that the hit area is wrapped in the declared element (in this case ) and no text is outputted inside the span (that is taken care of by some instruction starting with "tok" presumably).

Another important point is that hit marking can easily conflict with other annotation spans, leading to HTML hierarchy conflicts. Because of this, it's important to give an option to produce hit spans token-wise. We could use the third column, which is redundant for hit marking: the user can either write nothing in column 3, or use the reserved "tokenwise".

annis:HIT   span; style="my_hit_style"  tokenwise

If "tokenwise" is declared, then a hit-generated element is placed at every token position, e.g.:

This is a sentence and the hit is in these <span class="my_hit">two</span><span class="my_hit">words</span> only.

In cases like these, it's assumed that another instruction is outputting tokens. If not and a longer span contains the words (because of units smaller than words acting as tokens), then this strategy is benign, since you'll get:

The hit covers two token positions <span class="my_hit">here</span><span class="my_hit"></span> because the letter 'h' in 'here' was annotated as red.

In this case the second token generates and empty, harmless span.