[tei-council] NH

[Daniel O'Donnell]

I'm wondering about the larger issue here for this chapter: I think
Sebastian's original suggestion that it seemed hesitant and more like a
discussion paper than a guidelines chapter was right, though I disagreed
with him that it seemed to imply the TEI was maybe a bad choice after
all (to paraphrase very badly and broadly). I also thought that the
discussion section could be safely removed no matter what we do with the
chapter.

Given the date, it seems to me that the questions we really need to
answer now are:

1) Should, and in what fashion, this material appear in the Guidelines?
Should it appear as a chapter, as an appendix, as a related document, a
tutorial (A TEI U-series publication, at long last!), whitepaper, or
what?

I think the material is very useful and worthwhile--in fact reading it
has helped me in a project I'm currently consulting on. I can see the
point of those who say it doesn't define anything in the schema, though.
And it certainly reads extremely different from all the other chapters.

Me, I'm thinking an appendix or a U-series paper. But I'm happy with the
will of council. Given that it is not an essential part of the model, it
should of necessity at this stage be lower priority than other chapters
that need more editorial attention, methinks. Only if it is truly low
hanging fruit should we go for getting it in the P5 1.0 as a chapter.

If we deal with this issue, then the next becomes:

2) Is the current organisation optimal? (in an email that may not have
been distributed to the list, or was too stupid to receive comment), I
suggested it might not be difficult to reorganise the sections so that
we dealt with TEI conformant methods first and then moved on to ones
that required customisation and finally non-XML methods, for example,
but I'm not wedded to that. And those changes may be more than is
feasible at this point.

And it seems to me that we can then debate at that point about whether
various approaches fit the abstract model or are really ideally
non-conformant.

I think this debate is really useful, but it leads me to suspect that it
might be yet be premature for inclusion: I can see an interesting
post-P5 1.0 discussion on council about the issues that are coming up.

-dan

On Sat, 2007-09-29 at 16:26 +0100, Lou Burnard wrote:
> Syd Bauman wrote:
> >> This is not conformant because it breaks the abstract model. A
> >> <seg> is supposed to have some content.
> >>     
> >
> > Indeed, that is one perspective, with which I am pretty sympathetic.
> > But I then read the actual description of <seg>, which says it
> > "contains any arbitrary phrase-level unit of text"; seems to me
> > nothing (i.e., no content) fits into the category of an arbitrary
> > unit.
> >
> >   
> 
> Indeed it does, but in your example the empty <seg/> element did not 
> have the meaning "empty segment here" but rather "start of segment here" 
> which is not at all the same thing.
> 
> 
> >
> >> If you rewrote it with milestones it would be OK though.
> >>     
> >
> > Well it might be valid, but it would still violate the TEI abstract
> > model. It would confound the difference between segment boundaries
> > and milestones, which (I believe) is an important, useful
> > distinction. Milestones are not arbitrary empty elements (like
> > <anchor>[1]), but "simply mark the points in a text at which some
> > category in a reference system changes". 
> 
> OK, I agree that "milestone" is a more specific case of
> the more general "segment boundary". I think though that it's not an 
> unnatural extension of the meaning you quote to say that a milestone is 
> therefore a segment boundary: it marks the boundary between a segment 
> without some  property and a segment  with it (or vice versa, depending 
> which end you're looking at)
> 
> > Milestone elements, like the
> > milestones along the road after which they are named, mark the
> > passage from one to another *of the same feature*, e.g. miles of the
> > road, pages of a book, or the reels of a movie. Thus in the general
> > case a milestone element marks both the beginning and the end of *the
> > same feature*, just with a different reference. 
> Not so. It marks a transition from one state to another.
> 
> 
> > That is, with respect
> > to the feature being encoded, the stuff before and the stuff after
> > the milestone are fundamentally the same.
> not necessarily
> >  As section HD54M puts it, a
> > milestone indicates where a state 'variable' changes its value.
> >   
> Yes.
> > One interesting feature of milestones is that the ranges into which
> > they divide their ancestor element of interest (typically <text>)
> > tessellate it.
> 
> Not necessarily. A milestone might be used to mark changes of speaker, 
> or changes of rhetorical style, or changes of ink, for example. None of 
> these tesselate the text necessarily: there may be passages where there 
> is no speaker, where the style is not marked, or written in pencil.
> 
> >  This permits software to find out something about the
> > current feature by looking at the preceding milestone (e.g., to find
> > current page number, looking for preceding::tei:pb[1]/@n) and to find
> > its edges by looking for the preceding and following milestones. 
> >
> > All this is patently untrue of segment boundary delimiters, which
> > indicate a feature that does not tessellate its ancestor, by
> > explicitly marking the beginning and the end. In some sense, they are
> > not marking where a state 'variable' changes its value, but rather
> > are marking the boundaries of a completely different state of
> > affairs, a different variable, altogether. Unlike milestones, you
> > can't just go to the preceding element to get information, as the
> > preceding element may be the end of a previous occurrence, as opposed
> > to the beginning of the one you're in.
> >
> >
> >   
> The phenomena you distinguish are distinct, but I think you are 
> restricting the field of application for milestones too much.  If you 
> want to introduce a new "milestone-like" element called "segment 
> boundary" (hey, we could call it <sb/> for short), well fine, but that 
> doesn't seem to be on the table.
> 
> 
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
-- 
Daniel Paul O'Donnell, PhD
Department Chair and Associate Professor of English
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Chair, Text Encoding Initiative http://www.tei-c.org/

Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox +1 403 329-2377
Fax +1 403 382-7191
Email: daniel.odonnell at uleth.ca
WWW: http://people.uleth.ca/~daniel.odonnell/