I appreciate the work that has been done to align the timeline
and alignment. The fact is, however, that the timeline and
alignment remain distinct. What was alignment is now
'corresp.grp' and the timeline is renamed 'align'. In spite of
this, the concept of the timeline is fundamentally the same. I
will have nothing to say about 'corresp.grp' and will focus on
The most fundamental aspect of speech, as compared with
writing, is that it evolves in time. If we need three tags
(timeline, pointer, point) to cope with this specifically, it
should be well worth it. It is possible that the concept could
be generalized to handle 'any one-dimensional structure'. I
would, however, prefer to hang on to the timeline idea. If it
can be successfully applied to the representation of speech
(which I am not yet convinced of), perhaps we can see later
whether the notion can be generalised to cover other one-
dimensional structures that text encoders might wish to
The timeline formalizes the representation of simultaneous
events in a nice manner. Each event is related to a common
scale outside the text. In existing schemes we find many ways
of representing simultaneous events (by vertical alignment,
devices like asterisks and parentheses, etc). The lack of
agreement on coding is one problem - another is the frequent
ambiguity and lack of explicitness.
The timeline concept is attractive because it can be used
flexibly. Some encoders may only wish to use the timeline to
handle the specific problem of overlapping speech. Others may
want to extend it to handle the duration of utterances,
pauses, and events in general. The amount of specification
with respect to time may vary, ranging from relative ordering
to indications of absolute time.
The main problems, as I see it, are (1) how we encode the text
in the first place, with references by pointers and 'start'
and 'end' attributes of elements to the points in the timeline
and (2) how we actually make use of the encoded text and its
associated timeline (for displaying simultaneous events,
printing out the text, etc).
I realize that the new alignment mechanism can do what the
timeline did. I still prefer 'timeline' to 'align
type=temporal'. The difference between the names 'point' and
'loc' is trivial. If 'timeline' is kept, so should 'point'.
(But if there is a general feeling that we should go for
'align' and 'loc', I will not insist on the original names.)
One major difference between the timeline proposal and the new
alignment proposal is that 'xref' (an already existing tag) is
used for 'pointer'. But we surely would like to be able to
identify the 'xrefs' that point to the timeline, as opposed to
other 'xrefs'. So what we get would be 'xref type=time'
instead of 'pointer'. What is the difference, apart from an
increase in bulk?
In our proposal we recommend 'pointer' for cases which could
not be handled by 'start' and 'end' attributes of the
elements. The new alignment proposal seems to involve the use
of a lot more 'xrefs' than we had pointers. Is there a
sufficient gain in preciseness of encoding to justify this?
Finally, the biggest difference between the timeline proposal
and the new alignment mechanism. In the latter the points
(locs) contain references summarizing the places in the text
which refer to a particular point (whereas our 'point' is an
empty element). This seems like a heavy apparatus to reveal
what could be done by a search. More important, the references
in a particular point (loc) would not summarize everything
going on at a particular time (because in a lot of cases there
would only be references to the timeline for the start and end
of events). And we feel that points should be empty not least
because they represent points in time (here I quote And Rosta,
the member of our working group who is the main originator of
the timeline idea).
In general, I am not as pleased with our proposals as the
above may indicate. It is significant that Brian MacWhinney,
in a recent brief comment on our working paper, could not
really see the usefulness of the proposals. Whatever solution
is chosen, the encoding must be as simple as possible and must
be relatable to encoding practice within existing schemes.
Oslo, 5 Dec -91