#184 Move <space> to core module

AMBER
closed
nobody
5
2010-04-30
2009-05-20
No

I think that <space/> ought to be moved from transcr to core in order to be more generally available (e.g. to TEI Tite). It doesn't make a lot of sense for <gap/> to be there but <space/> not to be. The two elements have clearly distinct purposes: <gap/> is for recording "a point where material has been omitted in a transcription", whereas <space/> "indicates the location of a significant [intentional] space in the copy text".

This phenomenon is hugely widespread in the transcription of legal and legislative documents. Take a look at the attached document to George Washington (also at http://lister.ei.virginia.edu/~drs2n/space-doc.jpg\) . There is no reasonable TEI element to use between "bearer" and "Horseley" other than <space/>.

Discussion

  • David Sewell

    David Sewell - 2009-05-20

    Doc to George Washington w/intentional space

     
  • David Sewell

    David Sewell - 2009-05-20

    Addendum: <space/> is needed for this purpose not just in transcribing manuscripts, but in encoding printed books that are representing transcribed manuscripts, as in the page attached from the Washington Papers.

     
  • Lou Burnard

    Lou Burnard - 2009-08-01
    • milestone: --> AMBER
     
  • Lou Burnard

    Lou Burnard - 2009-08-01

    This is a lovely example! But is the space between "bearer" and "Horseley" really correctlty encoded as a <space>? The note says "This element should be used wherever it is desired to record an unusual space in the source text, e.g. space left for a word to be filled in later, for later rubrication, etc." This is a printed text, so I don't see that the space serves that function: you can';t fill it in. If the editor had chosen to represent the original blank by means of a long dash "bearer ------ Horsely", how would you encode it? Maybe we need a special <blank> element....

    However, the fact that it;s not clear how to encode this feature is not a reason for moving an element into the core. The ciore contains elements which appear in the majority of documents likely to be encountered, I am not convinced that this phenomenon is in that category. <gap>s, by contrast, can and do appear in all kinds of texts, and <gap> is pretty close to what you want.

     
  • David Sewell

    David Sewell - 2009-08-03

    <gap/> is in fact used for this purpose, e.g (according to Paul Schaffner) in the University of Michigan Library's encoding guidelines. But it is mild tag abuse.

    A core <blank> tag having the semantics "this space intentionally left blank" would be useful, but I can't see that it is different enough from <space> to justify having a separate element.

     
  • Lou Burnard

    Lou Burnard - 2009-10-13

    agreed that this needs more thought, cf recent discussion on TEI-L

     
  • BODARD Gabriel

    BODARD Gabriel - 2009-12-09

    According to the note, space may be used _e.g._ for space left for filling, rubrication, etc., but presumably it would not be tag abuse to use it for any deliberate and significant space in a text. (Spacing between words is common and conventional, and so not significant in this sense.)

    I too don't see the need for <blank>, since I'm not offended by the use of <space> for pretty much any purpose it might be used for. (Not sure if it would work for a long dash, but then that's not really blank either, is it? I suppose if it's a long underscore ______ it could be considered space...)

    I note that even if this element isn't required in all transcriptions, it is pretty important to several (and quite disparate) projects, not only David's printed texts but in inscriptions and papyri space is considered very significant, and the <space> element is used very widely in most EpiDoc projects.

    Having said this, I'm not sure what adding the element to core would win us--could someone explain? We call in <space> from whatever module it's in, as we do many other elements. I suppose if it allowed spae to be more parallel to <gap> (which it is, in my view... space left clear by the scribe as opposed to text left out or unread by the editor), and inherit some of the attributes and content model that allowed them to be expressed and described in more closely analogous ways, that would be useful. (But does the core module really help us with that?)

    (I'd like <space> to inherit duration and responsibility [and possibly editLike, although less sure I can think of uses], as well as element content like <desc> and [eventually] certainty etc., to make it more parallel with gap.)

     
  • David Sewell

    David Sewell - 2009-12-09

    "I'm not sure what adding the element to core would win us--could someone explain?"

    The benefit would simply be that TEI customizations would inherit <space> by default. So in one sense this is merely a minor convenience. But if Council agree that <space> is an element that can reasonably be considered a "core element", the move to that module would reinforce the decision.

     
  • Lou Burnard

    Lou Burnard - 2010-04-30

    Council discussed again, and reaffirmed that <space> is the right element, and that using the transcription module is correct. Use of <gap> maybe needs more disambiguation.

     
  • Lou Burnard

    Lou Burnard - 2010-04-30
    • status: open --> closed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks