[tei-council] Responses to some of Lou's queries about my comments on ch. 11 [was Re: Fwd: Re: Re: Notes on chapter 11 (part two)]

[Brett Barney]

> > If a digital text contains one image per page or column (or similar
> > unit), and no more complex mapping between text and image is envisaged,
> > then the facs attribute may be used to point directly to a graphic
> > resource: Just a bad sentence (flabby to the point of saying nothing at
> > the end, I'd argue), but I'm OK with letting it slide.
>
> This is, if you will forgive me, an entirely exasperating commenm! You
> say you don't like the sentence, but you don't say why, and you have
> nothing concrete to say about improving it.

Forgive me for being exasperating, rather. I don't have anything
concrete to say about improving it because I don't understand what it's
trying to say and therefore can't form an opinion about how better to
say it.

But I will try to say why I don't like it. First, I have a hard time
knowing what is meant by "or similar unit." What is similar to a page
and a column? What characteristic(s) do pages and columns have in common
that the unnamed other unit might be expected to share? Is the salient
characteristic representation by a milestone element? The next bit,
about "more complex mapping" will really only make sense to those who
have read later parts of the chapter. Since this sentence doesn't
indicate what sort of more complex mapping one might do (for which @facs
on <pb/> or <cb/> or similar is inadequate) it doesn't seem to me to add
anything beyond what the previous sentence has already said better: "The
facs attribute is used to associate any element in a transcription with
an image of the corresponding part of the source, by means of the usual
URI pointing mechanism."

As I said, though, I'm OK with letting the whole thing slide, esp. now
that it seems quite likely that the problem is in my head.

>  >  > The coordinates of the surface (that is, the area of the image
>  >  > which represents the written two page spread)
>  >
>  > ---!!!!!! This is more of the problem that I was trying to call
>  > attention to when I wrote about what seemed to me a confounding of
>  > physical surfaces and surfaces as defined by the encoder. There *is
>  > no* single surface in the physical object, I would argue.
>
> I am not sure what you want changed here.

This issue is one that got a fair bit of discussion during our Tuesday
morning session. (See point #1 of Elena's comments regarding outstanding
"major problems.") I don't feel I should try to revise all of the
relevant bits of the chapter unilaterally, but I'd be happy to
participate in a group effort to do so (the group perhaps including
Elena, Lou, maybe even some non-Council person working on Goethe or
Proust or similar?).

> > Alternatively, if the transcription is intended to prioritize
> > representation of the process by which the document came to take its
> > present form over representation of the final text , it may be
> > preferable to use a subset of the available elements and to embed them
> > within the zone element, as further described in section 11.1.3
Embedded
> > transcription below.
> >
> > Smallest point here is that there's an extra space before the comma.
> > More important: This language does not, to my mind, suggest the
> > possiblity of doing strictly diplomatic transcription.
>
> Please suggest an improvement.

Alternatively, if the transcription is intended not to prioritize
representation of the final text so much as the process by which the
document came to take its present form and/or the physical disposition
of its component parts, it may be preferable to use a subset of the
available elements and to embed them within the zone element, as further
described in section 11.1.3 Embedded transcription below.

> > > Now suppose that we wish to align a transcription of this page
> > > with the zones identified above. The first step is to give each
> > > relevant part of the facsimile an identifier:
> >
> > As there's been a paragraph along these same lines added just above,
> > this sentence needs to begin differently.
>
> Again, I am at a loss as to what change you think is needed here. I've
> rewrittenm the first sentence as:
>
> If we wish to align a transcription of this page with particular zones
> within a facsimile, we begin by giving each relevant part of the
> facsimile an identifier:

OK. Might you also revise "this page" to "a page" or "the page"? (I'm
concerned that the discussion of the presumed antecedent, the page from
Géometrie Pratique, is no longer the subject of discussion in what
immediately precedes this sentence. So I suppose "the page from
Géometrie Pratique" might work, too.)

>  > > @binder describes the method by which a patch is or was connected
>  > > to the main surface
>  >
>  > but a "binder" isn't a method. Instead of "method" how about one of
>  > these:
>  >
>  > instrument device property apparatus
>  >
>
> these dont seem to work for me. surely the possible values indicate that
> it is a method?

Right. So, attacking from the other direction: "glued," "pinned," and
"sewn" are not binders. (Glue, pins, and thread *are*.) I would be fine
with changing the name of the attribute if that is less traumatic. @method
already exists (with two different sets of legal values, so maybe another
set wouldn't hurt anything?). At a glance, I don't see any of these:
@technique, @means, @procedure.

> > > editor may wish to assign a set of alterations (deletions,
> > > additions, substitutions, transpositions, etc.) or any other act of
> > > writing to a particular change, to indicate both that one or more of
> > > such phenomena preceded or followed another and also to indicate
> > > that they are related in some way, for example that one is a
> > > consequence of the other.
> >
> > Same objection that I registered above (and have before, on the list):
> > These need not be time-located, right?
>
> But this is the usual and prototypical case, so it seems appropriate to
> start with that. Happy to add a sentence licencing other uses if you'd
> like to propose one.

OK, something like this:

. . . for example that one is a consequence of the other. One might also
wish to group together certain revisions, regardless of when they might
have occurred, based on a variety of other shared characteristics (e.g.,
corrections of factual errors or revisions that incorporate suggestions
made by a given reader).

Probably would need massaging to fit with the surrounding landscape,
though.


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Lou Burnard <lou.burnard at retired.ox.ac.uk>                                                                                                        |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |TEI Council <tei-council at lists.village.Virginia.EDU>                                                                                              |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |11/10/2011 06:21 AM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |[tei-council] Fwd: Re: Re:  Notes on chapter 11 (part  two)                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





[this combines comments from martin, piotr, and brett]

-------- Original Message --------
Subject: Re: Re: [tei-council] Notes on chapter 11 (part four)
Date: Thu, 10 Nov 2011 10:10:36 +0000
From: Lou Burnard <lou.burnard at retired.ox.ac.uk>
To: Martin Holmes <mholmes at uvic.ca>

On -10/01/37 20:59, Martin Holmes wrote:
> (11.3 - 11.3.2)
>
> "...addition, deletion, or substitution of material, and the like."
> [Suggest "and other such alterations", because "and the like" is used
> just above this, as is "and so on" and "etc.".]

if you insist...

>
> The lengthy discussion of the "euery persone" abbreviations would
> benefit from a graphic showing the original MS.
>

it would. I wonder if I can find one.

> "<note target="#exp01">The stroke added to the final d could signify the
> plural ending (-es, -is, -ys>) but the singular<hi rend="it">good</hi>
> was used with the meaning<q>property</q>,
> <q>wealth</q>, at this time (v. examples quoted in OED, sb. Good,
> C. 7, b, c, d and 8 spec.)</note>" [Here I think there should be a final
> e in the note: "the singular<hi rend="it">goode</hi>  was used..."]

Done

>
> "For alle the while that I had
> <choice>
>    <sic>good<abbr>ɽ</abbr>
>    </sic>
>    <expan resp="#mp" cert="high">good<ex>e</ex>
>    </expan>
> </choice>
> I was welbeloued"
> [This is supposed to show an abbreviation "represented by the hooked d",
> but it appears to use a different character in addition to the d. I
> think it should us u+0257, shouldn't it?]

yes, and that should replace the "d" in good.

>
> "If it is desired to express aspects of certainty and responsibility for
> some other aspect of the use of these elements,..." [Repetition. Delete
> the first "aspects of", or change to "degrees of".]


Now reads "If it is desired to express certainty of or responsibility
for some other aspect of the use of these elements, "


> _______________________________________________

On -10/01/37 20:59, Martin Holmes wrote:
 > 11.3.3
 >
 > "For example, in the manuscript of William James's A Pluralistic
 > Universe, edited by Fredson Bowers (Cambridge: Harvard University Press,
 > 1977) a sentence first written..." [There should be a comma after
"1977)".]

Fixed

 >
 > "The advantage of the former solution is that it permits the same
 > annotation to refer to several corrections." [For clarity, suggest
 > adding "by including more than one pointer in the @target attribute of
 > the<note>, as exemplified below.]

OK
 >
 > "If it is desired to express aspects of certainty and responsibility for
 > some other aspect of the use of these elements,..." [As elsewhere,
 > repetition of "aspect". Suggest changing the second instance to
"features".]

Already fixed

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

On -10/01/37 20:59, Piotr Bański wrote:
 > I am editorially wondering about the Dulce et decorum est example at the
 > end of 11.3.5: the order of the bullets below the XML should be reversed
 > (and go from top to bottom, to be more reader-friendly), and what is
 > this sinister shortEnd?

nothing sinister about it. but i agree the list needs to be reordered.

 >
 > And there's "resemblence" instead of "resemblance" somewhere.
 >

not any more there isnt


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

On -10/01/37 20:59, Brett Barney wrote:
 >  > It should be noted that, as elsewhere in these Guidelines, this
chapter
 >  > places more emphasis on the problems of representing the textual
 > components
 >  > of a document than on those relating to the description of the
document's
 >  > physical characteristics such as the carrier medium or physical
 > construction.
 >  > These aspects, of particular importance in codicology and the
 > bibliographic
 >  > study of incunables, are touched on in the chapter on Manuscript
 > Description
 >  > (10 Manuscript Description) and also form the subject of ongoing work
 > in the
 >  > TEI Physical Bibliography workgroup.
 >
 > Is the binary "textual components" vs. "physical characteristics" still
 > satisfactory? I wonder whether the diplomatic transcription
discussion puts
 > the lie to this statement, now, or at least makes it need more nuance.
 >

In the absence of any proposed rewording, I am unsure what to do with
this suggestion.

 > "ongonig work in the TEI Physical Bibliography workgroup" Again
wondering
 > whether this is still the right way to put this.
 >
Probably not, since we dont have any such workgroup. I have now decided
to delete the whole para.

 >  > These Guidelines are mostly concerned with the preparation of digital
 > texts,
 >  > in which a pre-existing text is transcribed or otherwise converted
into
 >  > character form, and marked up in XML.
 >
 > Tiny point, but the comma adfter "texts" would seem to indicate a
 > non-restrictive clause, but it turns out to be a *restrictive* clause,
 > so the
 > comma should be deleted. (I.e., the bit following "digital texts"
doesn't
 > define that term but specifies which ones are meant.

Yes. Reworded as well:

These Guidelines are mostly concerned with the preparation of
digital texts in which pre-existing sources are transcribed or
otherwise converted into character form, and marked up in
XML. However,

 >
 >  > att.global.change supplies the change attribute, allowing its member
 > elements
 >  > to specify one or more states or revision campaigns with which
they are
 >  > associated.
 >
 > still doesn't seem to allow for the possibility of grouping changes
whose
 > association is not defined by temporality (e.g., those changes that are
 > marked in red because they have to do with correction vs. those marked
in
 > black because they have to do with revision).

"state" is the best I can do for that... other suggestrions welcomed

 >
 >  > If a digital text contains one image per page or column (or similar
 > unit),
 >  > and no more complex mapping between text and image is envisaged,
then the
 >  > facs attribute may be used to point directly to a graphic resource:
 >
 > Just a bad sentence (flabby to the point of saying nothing at the end,
 > I'd argue),
 > but I'm OK with letting it slide.
 >
This is, if you will forgive me, an entirely exasperating commenm! You
say you don't like the sentence, but you don't say why, and you have
nothing concrete to say about improving it.


 >  > By convention, this encoding indicates that the image indicated by
facs
 >  > attribute
 >
 > ---!!!!! As I commented before, I think there's a "the" missing before
 > "facs"

OK, fixed.


 >
 >  > And it makes the management of the information about the images more
 >  > difficult by scattering references to them through the file.
 >
 > Is this true? (Honest question. I just don't know what sort of
"management
 > of the information" is being posited.)

Revised as:

The management of information about the images may become more
difficult if references to them are scattered through many files
rather than being concentrated in a single identifiable
location.

 >
 >  > individuals appearing in a group portraits
 >
 > ---!!!!! I pointed this out long ago and thought it had been fixed.

Sorry, I missed it.Fixed now.


 >
 >  > surface defines a written surface in terms of a rectangular
 > coordinate space,
 >  > optionally grouping one or more graphic representations of that
 > space, and
 >  > rectangular zones of interest within it.
 >
 > I *think* that "rectangular" here is now passe, since zones need not be
 > rectangular (?)

fixed

 >
 >  > a legal TEI document may thus comprise any of the following:-
 >
 > seems to be a typo (extra "-" at the end)
 >

A Briticism. Replaced by a gallicism (nbsp before the colon)!


 >  > A surface might be a sheet of paper or parchment
 >
 > Not the sheet but one side of it, no? (unless it's a mobius strip)
Maybe:
 > "A surface might be one side of a sheet of paper or parchment"

Yes, fixed.

 >
 > ---!!!!! As I said before: "Also, I'm not sure why the definition of
 > att.coordinated is repeated in such a short space. I would think that
 > the two
 > could be combined and all of the attributes listed at once and then
 > discussed
 > one by one, in the ways that I believe the discussions of other
attribute
 > classes elsewhere are organized."

The intent was to discuss the co-ordinate setting (ulx, urx etc.)
attributes separately from the zone defining ones, but I forgot that the
class definition would in any case be included. Will think again.

 >
 > Also: for the <des> of the class, could we change it to something like:
 > "provides attributes which can be used to position an element within
a two
 > dimensional coordinate system."

The problem is that sometimes it does that, but sometimes it also
*defines* the coordinate system.

 >
 >  > in neither case is any specific mapping to the physical dimensions
of the
 >  > object represented implied.
 >
 > Awkward. Perhaps: "in neither case is any specific mapping to the
 > dimensions of
 > the physical object implied."
OK

 >
 > OR (if need be): "Neither practice implies any specific mapping to the
 > physical dimensions of the object represented."

Much better, Now reads


Neither practice implies any specific mapping between the co-ordinate
system used and the actual dimensions of the physical object represented.

 >
 >  > 34
 >  >
 >  > A zone may be used to define any region of interest, such as a
detail or
 >  > illustration,
 >
 > The footnote indicator "34" seems misplaced?
turned the note back into a para
 >
 >  > each of which specifies a point on the line surrounding the zone.
 >
 > Not my area of specialty, so I'm happy to be wrong, but I would have
 > thought a rectangle has more than one line?

introduced the word "perimeter" to clarify this.

 >
 >  > Note that this mechanism does not provide any way of addressing a
 >  > non-rectangular area, nor of coping with distortions introduced by
 >  > perspective or parallax; if this is needed, the more powerful
mechanisms
 >  > provided by the Scalable Vector Graphics (SVG) language 35 should be
 > used to
 >  > define an overlay, as further discussed in 16.4.3 A Three-way
Alignment.
 >
 > This is confusing to me for several reasons. 1) It seems that the
mechanism
 > just described has very explicitly explained how to address
non-rectangular
 > areas; 2) What do distortions have to do with anything, since the
reference
 > is to the digital image rather than to the physical object?

Yes, this is a bit left over from an earlier state of the text!
Paragraph now dleted.

 >
 >  > The coordinates of the surface (that is, the area of the image which
 >  > represents the written two page spread)
 >
 > ---!!!!!! This is more of the problem that I was trying to call
attention to
 > when I wrote about what seemed to me a confounding of physical
surfaces and
 > surfaces as defined by the encoder. There *is no* single surface in the
 > physical object, I would argue.

I am not sure what you want changed here.

 >
 >  > Zones within a surface Figure 3. Zones within a surface
 >
 > This text (caption) is misplaced in the output at least. Oh, wait. Is
the
 > problem that the image isn't embedded but linked?

Formatting artefact. Circumvented by using "In the following figure"


 >
 >  > Zones need not nest within each other; they must however be
 > rectangular, as
 >  > previously noted.
 >
 > ---!!!!! Again, this is a problem that I pointed out before.
 >

Now fixed


 >  > Alternatively, if the transcription is intended to prioritize
 > representation
 >  > of the process by which the document came to take its present form
over
 >  > representation of the final text , it may be preferable to use a
 > subset of
 >  > the available elements and to embed them within the zone element, as
 > further
 >  > described in section 11.1.3 Embedded transcription below.
 >
 > Smallest point here is that there's an extra space before the comma.
More
 > important: This language does not, to my mind, suggest the possiblity of
 > doing strictly diplomatic transcription.

Please suggest an improvement.


 >
 >  > Now suppose that we wish to align a transcription of this page with
 > the zones
 >  > identified above. The first step is to give each relevant part of the
 >  > facsimile an identifier:
 >
 > As there's been a paragraph along these same lines added just above,
this
 > sentence needs to begin differently.

Again, I am at a loss as to what change you think is needed here. I've
rewrittenm the first sentence as:

If we wish to align a transcription of this page
with particular zones within a facsimile, we begin by giving each
relevant part of the facsimile an identifier:
 >
 >  > This is the function of the start attribute, which supplies the
 > identifier of
 >  > the element containing the transcribed text found within the surface
 > or zone
 >  > concerned.
 >
 > This needs to acknowledge that (as will probably be usual and at least
 > seems to be true of the example given) the element indicated does not
 > "contain" the text but marks the beginning of the text.

This is made clear in the definition for @start, but I've also added "at
least the start of" before "the transcribed text" here.


 >
 >  > An embedded transcription is one in which words and other written
 > traces are
 >  > encoded as subcomponents of elements representing the physical
surfaces
 >  > carrying them
 >
 > not all of the elements are "surfaces." Most obviously, <line> and <seg>
 >
 > but wait, I was pretty sure that we decided that we *didn't* want to
re-use
 > <seg> in this way. I was expecting <block> here

No, we decided we didn't want <block> -- we use zone instead. And <seg>
is needed for stretches of transcipt which are smaller than either line
or zone.



 >
 >  > patch a part of a surface which was originally physically distinct
 > but was
 >  > combined with it at some time prior to some or all of the writing
on the
 >  > surface.
 >
 > Well, I think Elena will better articulate one of my objections here,
but a
 > second is that I still don't get why the timing matters. Is it not a
<patch>
 > if I affix it last?

we agreed to abolish patch, so this all needs some rethinking

 >
 >  > @binder describes the method by which a patch is or was connected
to the
 >  > main surface
 >
 > but a "binder" isn't a method. Instead of "method" how about one of
these:
 >
 > instrument device property apparatus
 >

these dont seem to work for me. surely the possible values indicate that
it is a method?

 >  > @flipping indicates whether the patch is attached and folded in such
 > a way
 >  > as to provide two writing surfaces
 >
 > I think I have a better name: @hinged

yes, I agree that is better. or @folded .
 >
 >  > The elements surface and zone were introduced above, .
 >
 > Typo (superfluous comma)
 >

Ok


 >  > Walt Whitman archive
 >
 > Cap on "Archive"
 >
OK

 >  > editor may wish to assign a set of alterations (deletions, additions,
 >  > substitutions, transpositions, etc.) or any other act of writing to a
 >  > particular change, to indicate both that one or more of such
phenomena
 >  > preceded or followed another and also to indicate that they are
 > related in
 >  > some way, for example that one is a consequence of the other.
 >
 > Same objection that I registered above (and have before, on the list):
 > These need not be time-located, right?

But this is the usual and prototypical case, so it seems appropriate to
start with that. Happy to add a sentence licencing other uses if you'd
like to propose one.

 >
 >  > <listChange> groups a number of change descriptions associated either
 > with
 >  > the creation of a source text or with an encoded text.
 >
 > Should be
 >
 > <listChange> groups a number of change descriptions associated with the
 > creation of either a source text or an encoded text.
 >
 > or something very similar

OK, I suppose, if you regard an "encoded text" as a "text" in the same
sense as we mean when talking about "creation of a text". I was trying
to sharpen the distinction. How about

"groups a number of change descriptions associated
with either the creation of a source text or the revision of an encoded
text."

 >
 >  > <change> documents a change or set of changes made during the
 > production of a
 >  > source document, or during the revision of an electronic file. 2.5
The
 >  > Revision Description
 >
 > Up until this point "change" has been used as notionally encompassing
the
 > plural, so it's odd to start talking here of "a set of changes."
 >
 >  > Hence, having a certain order of stages put in place before
transcription
 >  > begins, will allow the encoder to reduce verbose tagging,
 >
 > Small point: incorrect comma between subject and predicate

OK

 >
 >  > A nested listChange elements is also useful to indicate a partial
 > ordering of
 >  > revision campaigns.
 >
 > Should be either "Nested listChange elements" or "A nested listChange
 > element"

ok

 >
 >  > Note first, that a change
 >
 > Another unnecessary comma

sorry. i just, love commas.


 >
 >  > initially it takes place in the second stage, but is fixated as a
 > whole in
 >  > the third.
 >
 > "fixate" is not right here. Should be "but is fixed as a whole in the
 > thired" vel sim.
 >

ok



 >  > From the documentary perspective, the stage assignments describe the
 > writing
 >  > process, in that they specify, which segment has been written when
 > and how
 >  > often.
 >
 > no comma after "specify"
 >

i think that one was german in origin. anyway, it's gone.




 > (T)reading on...
_______________________________________________
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20111114/e3d8efce/attachment-0002.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20111114/e3d8efce/attachment-0003.gif