Print

Print


Dot Porter wrote:
[...]

> Our concern is with associating editorial notes with the textual content
of
> the edition. By "editorial notes" I mean that these are the opinions of
our
> own (electronic) editor, not footnotes in a published document. This type
of
> note would be used in cases where we wouldn't necessarily want to use
other
> descriptive markup. We're hesitant about using TEI <note> in this way for
a
> few reasons.

[...]
>
> Trying to anticipate some concerns:
>
> 1. We are not concerned with including markup in the editor's comments, so
> there is no issue with placing markup in that attribute value.

Really? Are you sure your editorial notes will never, ever, involve
emphasis, supserscription, bibliographical references, inclusion, e.g by way
of reference to a MS glyph, of a character that has no Unicode codepoint (I
could go on, but you doubtless get the idea). But even if you are certain
that you will never require any sort of markup, there are serious practical
and conceptual reasons, no matter what past practices were, for in future
avoiding natural-language text (rather than tokens from a controlled
vocabulary) in attribute values, which have driven a good portion of the
most important changes in P5.  I refer, for example, to the rationale for
the dropping of the "Janus pairs" in favour of choice, amply documented in
the materials associated with P5. When I voiced my plainly idiosyncratic but
still invincible unhappiness about P5's abandonment of the old TEI lang
global attribute in favour of xml:lang, Christian's response,
http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0502&L=tei-l&P=R5843&D=0&H=0&O=T&T=1
presumably expressing the upshot of Council's deliberations on the matter,
was in effect that come the Revolution or the definitive P5, whichever gets
here first, natural language lexemes will be banished from TEI-conformant
attribute values altogether, thus removing the basis of the anxiety Robin
Cover had expressed about xml:lang in the TEI context and which had led me
to utter one more time on the matter. But whatever: this really isn't the
time to launch extensions that put large chunks of  #PCDATA into attribute
values.

> 2. "But what you're saying is that that ms text is being described as an
> editorial note, right?" Well, right now we are calling the element
<ednote>.
> But what if we call it something different, like <noteSub>, for the
subject
> of the note?  And the attribute value is the note that describes the
> subject?

Well, I have come to the conclusion that some scholars really do think that
"their" texts (i.e. somebody else's which they have appropriated to fuel
their career path) were somehow, in the Great Scheme of Things, created just
so that they could one day come along and annotate them. But I'd draw the
line at enshrining something that looks perilously like that view in TEI
markup.  Maybe it's a matter of taste. Personally, I could never bring
myself to deface a text, even a disposable "teaching" copy, with a pen or a
highlighter in order to mark places I wanted to find quickly when teaching
class, even though I knew a lot of people who did. But when those little
coloured transparent tape-tags with post-it-note type adhesive came along, I
had no qualms about peppering my teaching copies with those, since they
adhered only lightly, and left no trace when removed. I suppose the closest
encoding equivalent to my non-defacing and ephemeral marker tapes would be
full-blown standoff markup, but despite many deliberations, and the switch
to Xlinking in P5, we aren't really equipped for that just yet. The next
best thing in my view are anchor milestones. Because they don't actually
assert themselves as part of the dominant hierarchy, they strike me as more
like my temporarily-attached physical markers, whereas the span of an
in-line element resembles for me more a splash of indelible ink.

Like Lou, I wondered at first if the hesitation over the use of <note>
wasn't merely a matter of failing to realise that <note>s need not be
interspersed into the source text flow. (Nor, by the way, does associating a
out-of-line <note>  with a number of consecutive <l>ines involve a list of
every ID involved. That's what range notation is for. Provided the start and
end IDs are given, the scope of the reference is unambigiously marked.
XPointers allow even greater precision with similar economy)

But then I looked again at the somewhat puzzling phrasing of "for editorial
reasons we are keen to keep the content of our document limited to the
content of our source manuscript". Puzzling, because here "our document"
plainly can't mean "our document instance": after all, any annotations,
whatever the mechanics of their association with the main text, plainly
belong to the latter. So I can only take this to mean "we want the text
content of all the elements in our document instance (TEIHeader aside, one
presumes) to consist of nothing more or less than the text of our source
MS." That interpretation makes sense of the plan to put the annotations into
attribute values, but I am at a loss to understand why this should be
thought desirable, for editorial or any other reasons. Could this possibly
be an echo of the days of pure SGML, when once markup of any sophistication
was in place, recovering the source text entailed the often not
inconsiderable grief of installing and cranking up an SGML parser, unless
the "element text content only" principle was followed, in which even the
most blissfully parser-free users could pull out the pristine text in a
jiffy with a simple regex. But now that all our machines are stuffed full of
free and efficient software that will extract whatever we want from our
document instances with supreme ease, wherever it lurks, even in a different
part of a filestore, I don't see what the issue is.

Michael Beddow






>
> <noteSub noteContent="here is the opinion of the electronic editor">ms
> text</noteSub>
>
> Are there other problems with approaching editorial notes in this way? Has
> anyone else dealt with this issue, and if so how did you work with it?
>
>
> Thanks,
>
> Dot
>
>
>
> **********************************
> Dorothy Carr Porter
> Program Coordinator, Research in Computing for Humanities
> 3-51/3-52 William T. Young Library
> University of Kentucky
> Lexington, KY  40391
> 859-257-9549                      http://www.rch.uky.edu
> **********************************
>