Loading ...
Sorry, an error occurred while loading the content.
 

Re: tc-list New ENTMP

Expand Messages
  • Robert B. Waltz
    ... Just a few thoughts.... The idea of HTML tags for nomina sacra, etc. have advantages. But I see a bit of a problem. HTML-style tags, obviously, use the
    Message 1 of 4 , Aug 2, 1999
      On 8/2/99, Dave Washburn wrote, in part:

      >The transcriptions I did didn't have any real way to indicate
      >abbreviations (I assume you mean little ligatures like the trailing-off
      >line on kappa at the end of a line to indicate KAI, that sort of
      >thing?), but under James' direction I used brackets to indicate
      >uncertain or supplied letters, and I believe we were playing with a
      >pseudo-HTML tag <BAR></BAR> to indicate NS. I would tend to
      >prefer something like this that keeps the format of running text,
      >simply because later on it should make it easier to mark up (then
      >again, I may be wrong about that). Here's the preliminary
      >transcription of 071 that I did lo, those many ages ago:

      Just a few thoughts....

      The idea of HTML tags for nomina sacra, etc. have advantages. But
      I see a bit of a problem. HTML-style tags, obviously, use the angle
      brackets < >. But > is a symbol one sometimes encounters in a
      manuscript. Does one, then, use the correct HTML symbol > in the
      transcription? If so, we're not using ASCII any more. :-)

      I might be tempted instead to use something else like {} for these
      sorts of tags. If one then wishes to convert to HTML, it's a simple
      change -- just { to < and } to >. And it leaves us [] for lacunae
      and perhaps () for uncertain letters.

      I'm not trying to make life difficult here, just point out some things
      to think about.

      [ ... ]

      >Agreed. If the goal is transcription rather than collation, then
      >IMNSHO the ms. should be transcribed exactly as it appears.

      I think this should be the goal even with collations. :-) Personally,
      I prefer collations most of the time, because it's so much easier to
      notice the difference between, say, ECOMEN and ECWMEN. :-) But it
      depends on circumstances. I do think that the collation base needs
      to be posted on the site in its entirety; it's *not* enough to just
      list it.

      [ ... ]

      >As I recall, this was one of the original ideas of the ENTMP. Pass
      >them around freely so anyone can use them, definitely. But I
      >would push for a centralized location (or at least style and dtd) for
      >markup, rather than each doing what is right in his own eyes...

      I have to agree with this one. I've had to work with some really
      strange collation styles in my life (the award, I think, goes to
      Davies's collations of 330, 436, 462, and 2344. I *still* stumble
      over that one sometimes). Ditto the Collate format for transcriptions.
      My first few attempts to convert Tim Finney's transcriptions of
      Hebrews resulted in quite a few bollixes, especially as regards
      correctors. Using more than one standard is a shortcut to trouble.

      [ ... ]

      > > Yes, yes, yes. My only complaint about CCAT (and Beta code) is the
      > > transcription of xi with C and chi with X. In Athens, taxi is spelt with
      > > xi, not chi. Oh well.
      >
      >Agreed. However, any mapping scheme is going to have some
      >less-than-ideal features. The main reason I suggested CCAT is
      >because a) it's already in place and used profusely, and b) there
      >are numerous fonts for just about any platform, floating around the
      >Net, that are based on it, so all one has to do is download one,
      >install it, and go.

      Obviously the big hang-up here is X/C. (At least, every scheme I've
      ever seen renders theta as Q, and the rest are obvious.) Maybe it's
      actually time for a vote. :-)

      I vote C=chi and X=xi, for what it's worth.

      Bob Waltz
      waltzmn@...

      "The one thing we learn from history --
      is that no one ever learns from history."
    • Dave Washburn
      ... Good point. This is the sort of thing that needs to be agreed upon, though I would suggest that when we re down to the level of tweaking individual
      Message 2 of 4 , Aug 3, 1999
        Bob Waltz wrote:
        > On 8/2/99, Dave Washburn wrote, in part:
        >
        > >The transcriptions I did didn't have any real way to indicate
        > >abbreviations (I assume you mean little ligatures like the trailing-off
        > >line on kappa at the end of a line to indicate KAI, that sort of
        > >thing?), but under James' direction I used brackets to indicate
        > >uncertain or supplied letters, and I believe we were playing with a
        > >pseudo-HTML tag <BAR></BAR> to indicate NS. I would tend to
        > >prefer something like this that keeps the format of running text,
        > >simply because later on it should make it easier to mark up (then
        > >again, I may be wrong about that). Here's the preliminary
        > >transcription of 071 that I did lo, those many ages ago:
        >
        > Just a few thoughts....
        >
        > The idea of HTML tags for nomina sacra, etc. have advantages. But
        > I see a bit of a problem. HTML-style tags, obviously, use the angle
        > brackets < >. But > is a symbol one sometimes encounters in a
        > manuscript. Does one, then, use the correct HTML symbol > in the
        > transcription? If so, we're not using ASCII any more. :-)
        >
        > I might be tempted instead to use something else like {} for these
        > sorts of tags. If one then wishes to convert to HTML, it's a simple
        > change -- just { to < and } to >. And it leaves us [] for lacunae
        > and perhaps () for uncertain letters.

        Good point. This is the sort of thing that needs to be agreed upon,
        though I would suggest that when we're down to the level of
        tweaking individual characters like this, we're pretty close to a
        standard. Since as I recall the > and < characters are used for
        accents, they wouldn't be a problem for the earlier mss, and such
        things could be adjusted during markup later. I could live with that.

        Of course, if this expands into Hebrew mss, then using { and }
        won't work because in CCAT these denote a couple of very
        common final-form letters...

        > I'm not trying to make life difficult here, just point out some things
        > to think about.

        And your points are well taken, at least by yours truly.

        > [ ... ]
        >
        > >Agreed. If the goal is transcription rather than collation, then
        > >IMNSHO the ms. should be transcribed exactly as it appears.
        >
        > I think this should be the goal even with collations. :-) Personally,
        > I prefer collations most of the time, because it's so much easier to
        > notice the difference between, say, ECOMEN and ECWMEN. :-) But it
        > depends on circumstances. I do think that the collation base needs
        > to be posted on the site in its entirety; it's *not* enough to just
        > list it.
        >
        > [ ... ]
        >
        > >As I recall, this was one of the original ideas of the ENTMP. Pass
        > >them around freely so anyone can use them, definitely. But I
        > >would push for a centralized location (or at least style and dtd) for
        > >markup, rather than each doing what is right in his own eyes...
        >
        > I have to agree with this one. I've had to work with some really
        > strange collation styles in my life (the award, I think, goes to
        > Davies's collations of 330, 436, 462, and 2344. I *still* stumble
        > over that one sometimes). Ditto the Collate format for transcriptions.
        > My first few attempts to convert Tim Finney's transcriptions of
        > Hebrews resulted in quite a few bollixes, especially as regards
        > correctors. Using more than one standard is a shortcut to trouble.

        I haven't tried these, but I wholeheartedly agree with the last
        sentence.

        > > > Yes, yes, yes. My only complaint about CCAT (and Beta code) is the
        > > > transcription of xi with C and chi with X. In Athens, taxi is spelt with
        > > > xi, not chi. Oh well.
        > >
        > >Agreed. However, any mapping scheme is going to have some
        > >less-than-ideal features. The main reason I suggested CCAT is
        > >because a) it's already in place and used profusely, and b) there
        > >are numerous fonts for just about any platform, floating around the
        > >Net, that are based on it, so all one has to do is download one,
        > >install it, and go.
        >
        > Obviously the big hang-up here is X/C. (At least, every scheme I've
        > ever seen renders theta as Q, and the rest are obvious.) Maybe it's
        > actually time for a vote. :-)
        >
        > I vote C=chi and X=xi, for what it's worth.

        The only problem there is getting folks like SP to make the
        necessary adjustments in their fonts etc. as well as changing all
        the transcriptions that are already out there, such as the stuff at
        the Perseus Project etc. Were it to come down to a vote, I would
        probably vote the same way. However, I can see mountains of
        impracticalities in trying to get the rest of the world to change it...

        Dave Washburn
        http://www.nyx.net/~dwashbur
        A Bible that's falling apart means a life that isn't.
      Your message has been successfully submitted and would be delivered to recipients shortly.