I have been giving the <seg> markup convention I intend to use for
this manuscript much thought. I have not implemented it yet, and wish
to get the thoughts of others on the OSIS list before I do. Here are
my thoughts on the matter, as well as notes about implementation
should these manuscript elements I propose find their way into the
OSIS Schema.
<seg type="x-mssTextUnclear></seg>
This segment type should be used when it happens that the manuscript
text is unreadable due to damage, entropy, or whatever. This should
never be used to indicate text that simply has an unclear or vague
meaning in the linguistic sense.
When a Manuscripts text is unclear, there are two options:
1. Do not insert any text from a secondary manuscript source. Instead,
place an ellipsis "..." in the tags to indicate missing text.
In the future, should a formal segment type be adopted to handle this
function, it may be preferable to simply have empty tags (following
the xml rules for empty tags). It that case, it would be the
responsibility of the OSIS rendering agent to handle such display
issues. Though, in any event a note SHOULD be generated to document
this, in case the rendering agent fails to handle the tag correctly.
2. Insert text from a secondary source. In that event a note MUST
accompany this segment type. The note MUST be used to document the
source of the inserted text (i.e. the secondary manuscripts name, or
other commonly accepted designation).
In the future, should a formal segment type be adopted to handle this
function, I would strongly suggest that a non-empty segment of this
type depend on the presence of a non-empty note directly adjoining it
of the a schema specified type. So, if text is inserted, and no
documentation given any attempt to validate the xml document against
the schema will produce an error.
<seg type"x-mssSribeIndicatesChange></seg>
This segment type is used to markup text that, through some scribal
convention, the Manuscript's scribe indicates has been changed in some
way. The scribal convention used to indicate this change, SHOULD be
explained in an adjoining note tag.
<seg type"x-mssMissingLetters></seg>
This tag is to be used to indicate the insertion letters lost from a
single word due to damage to the manuscript or scribal error. If
damage to the manuscript, or scribal error is sufficient that the
intended spelling is at all in doubt, this tag may not be used.
Instead, a note should be generated, and the mssTextUnclear type tag
should be used. This tag should also not be used to "normalize" the
spellings of names.
<seg type"x-mssScribeAdds></seg>
This tag is to be used to indicate words that are apparently added to
the manuscript by the scribe. That is, the word or words are unique to
this manuscript, or a certain subset of manuscripts. It might be wise
to document what other manuscripts share the added words, and what
ones do not.
<seg type"x-mssScribeDiffers></seg>
This tag is to be used to indicate sections of the text that are
significantly different in some way from the commonly accepted reading
of the text. (i.e., it appears the scribe may have taken inappropriate
liberties and rewritten, modified, or replaced the text).
I suggest a new type of segment be added to a future revision of the
OSIS schema standard <mss> (short for manuscript). And that tag be
used in manners similar to the custom <seg> types outlined above. I
suggest the <mss> tags be of the following types:
textUnclear
scribeIndicatesChange
missingLetters
scribeAdds
scribeDiffers
Also I suggest the addition of the following note types:
mssFeatures - to be used when encoding manuscripts to describe
unusual, or noteworthy features of the manuscript or its text
(especially if such features are difficult to render in electronic
form).
scribal - to be used to describe scribal conventions used in the text,
and meanings of those conventions.
source - to be used to document text supplied from another manuscript,
in the event that the primary manuscript being encoded is illegible.
That's it for now, please give me your thoughts. Feel free to poke
"poke holes" in my suggestions. If any of you think I have missed
anything, let me know that too!
Thanks people :-)
--Jeff G.
|
