[tei-council] genetic proposals: follow up (long!)

Lou Burnard lou.burnard at retired.ox.ac.uk
Mon Jun 6 08:19:22 EDT 2011


Following our discussions in Chicago, I sent an email to the working 
group, as proposed, outlining and summarizing the Council's opinions.
I've just received from Elena a summary of the group's reaction to 
this., based on a conversation she had with them last week.

I think there's a basic agreement, but the details still need some 
further thought: Council members' input warmly welcomed. I think we 
should also now start opening up discussion of this topic to a wider 
group: suggestions for how that might be done also welcomed!

For completeness, I include below both my original message, and the 
response.


----------------

On 16/05/2011 15:29, "Lou burnard" <lou.burnard at tge-adonis.fr> wrote:

 > >
 > >Dear colleagues
 > >
 > >As you may have heard, the "genetic module" proposals from this work
 > >group were finally discussed in some detail at the recent TEI Council
 > >meeting in Chicago. Elena did an excellent job of presenting them and
 > >the Council engaged very positively with the ideas proposed. Although
 > >the document has been on its agenda for rather a long time, this was
 > >the first time Council  had discussed it in any detail.
 > >
 > >You can see the official record of the discussion in the Council
 > >minutes which are available online at
 > >http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml.  However,
 > >Elena and I thought it would be useful to bring the outcomes to your
 > >attention in advance, especially in cases where the Council did not
 > >reach a firm conclusion.
 > >
 > >The document was considered under three headings, each of which
 > >corresponds with a different Sourceforge ticket (this is the usual
 > >mechanism for proposing changes to the TEI).
 > >
 > >Firstly, the proposal for a new <document> element.
 > >
 > >The minutes say "Council recognised and endorsed the use case for a
 > >view of the encoded physical object, comprising surfaces, zones,
 > >patches, and optionally lines of writing. diploma was suggested as an
 > >alternative name. Discussion focussed chiefly on the distinction
 > >between the proposed <document> and the existing <facsimile>
 > >elements. Some expressed concern that it would be difficult to explain
 > >and justify this distinction; others felt that the two were entirely
 > >discrete. It might be possible to regard the existing <facsimile> as a
 > >special case of the proposed <document> , even though (for example)
 > >the <zone> s identified within a <facsimile> might be motivated by
 > >other factors than those identified within a <document> . We agreed
 > >that it might be useful to find out whether the proposed user
 > >community would find it unacceptable to embed the image information
 > >currently managed by <facsimile> within the proposed <document>
 > >element."
 > >
 > >So the question is: do you feel that it would be appropriate to
 > >combine the functionality of the existing <facsimile> with the
 > >proposed <document> ? If we agree on that, then it will be necessary
 > >to think up a new name (which is neither "document" nor "facsimile").
 > >
 > >Secondly, the proposed new transcriptional elements.
 > >
 > >The minutes say "We agreed that <modSpan> was unnecessary if <mod>
 > >was provided, and a member of att.spanning. We agreed that <rewrite>
 > >might be better renamed as <retrace> . We noted that <used> was a
 > >special case of <metamark> . Some felt the need for greater clarity
 > >about the distinction between <undo> and <redo> . Discussion chiefly
 > >focussed on which of these elements, if any, should be permitted in
 > >the content of <document> ; EP felt strongly that all transcriptional
 > >elements (these, plus the existing ones) should be permitted in both
 > ><text> and <document> ; others were less sure. Some of them seemed
 > >definitely non-documentary, others less so."
 > >
 > >We (Elena and I) agree that <modSpan> is unnecessary, and that
 > ><retrace> is a much better name than <rewrite> ; we hope you do
 > >too. The main issue here is where the transcriptional elements should
 > >be permitted -- in other words, what the content model of the proposed
 > >"facsimile/document" should be. The current proposal allows all
 > >transcriptional elements anywhere. An alternative would be to say decide
 > >which transcriptional elements belong to the "text" view only, and
 > >which to the "document" view only. What's your view?
 > >
 > >Finally, renaming the element/attribute currently known as stage
 > >
 > >The minutes say "We agreed that the idea of documenting writing stages
 > >in this way was useful and feasible. We noted that stages of this kind
 > >were not necessarily always chronological, but that could be used for
 > >any kind of grouping; also that a given stretch of writing might be
 > >assigned to multiple stages.  Mostly we found it difficult to decide
 > >on a better name than "stage" which was clearly too confusing in a TEI
 > >context. Alternatives proposed were "layer", "changeSet", "stratum" or
 > >"phase".
 > >
 > >After prolonged debate subsequent to the meeting, the Council
 > >concluded by recommending "layer". This means that the attribute
 > >@stage will become @layer, the element <stageNote> will become
 > ><layer>, and the element <stageNotes> will become <layerNotes>.
 > >
 > >I would much appreciate your opinion about all of these proposals, so
 > >that we can move forward to including them (or some version of them)
 > >in the next release of the TEI Guidelines.
 > >
 > >best wishes
 > >
 > >Lou
------------------------------

and the summary I've just received:

-------------------------------



Skype conf call held on the 3rd of June 2011
Present: Fotis Jannidis, Malte Rehbein, Elena Pierazzo, Gregor Midell, 
Moritz Wissenbach

<document>/<facsimile>
Although none of us was particularly thrilled about the idea of having 
the functions of document and facsimile conflated under a single element 
(name to be found), we understood the issues raised by the Council and 
agreed we can survive with it. Nevertheless, while we see little 
problems when zones that have been drawn for ‘graphical’ reasons 
coincides with zones drawn for transcription purposes, we envisage 
possible confusion when these do not coincide, so we recommend the 
possibility of clearly distinguishing the types of zones (by the mean of 
@type, for instance). We also recommend that the wrapping element 
(whatever its name) should be repeatable, in case someone wanted to keep 
separated the zoning on the images from the zoning on the document.
We thought briefly about the possible name for the wrapping element and 
we propose <layout>. A minority suggestion is <docRepresentation>

<modSpan/>
We agree it should be ignored

<rewrite>
We agree that <retrace> is a better name. We also discussed the use of 
<retrace> as opposed to or in combination with <redo> and we thought we 
want to preserve both: <retrace> should be reserved for the retracing of 
text only: it is an element with content and its semantic means that 
whatever is contained in <retrace> has been traced twice; on the other 
side <redo> should be reserved for all other case of redoing something, 
for instance (as in the example at the bottom of section 3.1), for the 
redoing of a deletion, for this reason it is an empty element that point 
to another element. In this way <redo> is not connected to <undo> but is 
simply a way to marking that something has been redone.

<used>
We agreed that <used> is a special case of <metaMark> and therefore we 
don’t object to the fact that it can be suppressed. We also think that 
<metaMark> should not be allowed outside <zone> (<used> was allowed 
within <surface>).

Which elements for which views
While it is true that some editorial approaches distinguish elements 
that belong to the documentary encoding from the one that belong to the 
textual encoding, this is not true for many other approaches, therefore 
putting limitation on which editorial/transcriptional elements belong to 
which view seems to break the normal ecumenical TEI approach with 
respect to editorial theories. The group recommends allowing all 
transcriptional and editorial elements to appear in both textual and 
documentary views.

New name for “stage”
‘changeSet’ is the favourite because it does not imply any temporal 
assumption, which cannot be predicated in all circumstances. ‘layer’ was 
not discarded either

----------------------------------


More information about the tei-council mailing list