David Schlangen : Home Page > minutes050607_zeitwort2 present: Titus, Timo, David
[ executive summary: need to make distinction between static tracks,
which always show what happened (= what was annotated) at a given
moment, and dynamic tracks, which represent one module's
hypothesis about what happened at given moments. Dynamic tracks
need to be updated completely (including the full past of the
track and maybe even the future) every time new information
becomes available, while static tracks can either be shown
completely (if viewing from annotated files) or are only being added
to towards the future (if used in live mode).
That is, in effect dynamic tracks create little movies, while
static tracks just move underneath the cursor.
]
In our planning so far, we didn't consider the "show current
hypothesis" use case, which requires showing the dynamics of
changing hypotheses which may be about timed events in the past (or
future). This is most important for ASR output, which includes
segmentations of previous material that can change, but may also
be relevant for other modules. E.g., some modules may make
predictions about the occurence of future events, where with more
information these predictions can change.
That is, the problem is that "current time" must be interpreted as
"the system's (or rather: the module's) view of the past, the
present, and the future" -- at least for those tracks that are
directly linked to one module.
Solution: have tracks that show current hypothesis state, together
with control track that records when hypotheses changed. E.g.
CT: <> <> <> <> <>
Hyp: I-----I--------I-----|
|
The <> are the events of a new hypothesis being posted (and hence it
is a static track), and the track Hyp shows the then current
hypothesis, either inline, for interval-type information like
segments or in an external viewer for things like parse trees.
(Inline may be more useful for modules that produce some form of
timed event recognition or predictions (like segmentations or
predictions of future events), because then the information can be
placed on the same timeline as the main window. An external viewer
may be more useful for modules that synthesise previous information,
without reference to the temporal placement of the components in
this; e.g., parse trees or views of current information state.)
If you click on previous <>s, either the tool jumps there and shows
the information state at that point in the inline view, or a viewer
window opens so that this previous hypothesis state can be compared
with the current hypothesis.
Other tracks may be static as before, e.g. one for the gold-standard
word recognition / segmentation.
Two types of scrolling then:
- moving "current time", which means that hypothesis tracks must
show the state which is appropriate at the given current
time. (This is just like "play", moving around the main cursor.)
- scrolling around in the given hypothesis state. E.g., the viewer
is stopped at 13'20, the left corner of the window is at 12'20,
and you want to see the information at 10'10 (which for static
tracks is what actually happened then and for dynamic tracks is
what that module thinks what happened).
One moves "red line / current time cursor" (or rather, moves scroll
along the static line), the other unlocks the current time cursor
from the middle of the window and moves whole scroll (as it
keeps showing the state at that, now fixed, current time).
Additional feature: would be nice to also represent links between
hypotheses on different tracks. E.g., a <> event (posting of
hypothesis) in one track may be linked to an earlier <> event in a
different track, meaning that the former was constructed using the
latter. (This information needs to be in the system anyways, so
could just as well be visualised.)
das, 06/05/07 04:11 (GMT)
Keyword: minutes, viewer, zeitwort