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

Martin Holmes mholmes at uvic.ca
Mon Jun 6 08:39:54 EDT 2011

It looks like we're close to a general agreement about almost 
everything. We'll need to discuss what's new in the working group's 
report, which I think includes:

  - <layout> as a single replacement for <facsimile> and the 
previously-proposed <document>. Obviously we'll have a 
backwards-compatibility issue here; how will we deal with it? Should we 
allow both <facsimile> and <layout> to exist in parallel for P5, and aim 
to retire <facsimile> in P6?

  - <changeSet> instead of <layer> (and friends). I think this would be 
uncontroversial, since some of us voted for it already.

Is there anything I'm missing?

If we (council and working group) can agree on a joint proposal, it 
needs to be drafted in full and opened up to TEI-L for discussion.


On 11-06-06 05:19 AM, Lou Burnard wrote:
> 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
> ----------------------------------
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> PLEASE NOTE: postings to this list are publicly archived

More information about the tei-council mailing list