[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.
Cheers,
Martin
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