In our case, *customization* is the key while transcribing facsimiles within <sourceDoc>. If you are 98% satisfied with the content model of zone or line, and just need to mark up, for example, some persons using <rs> (as is our case), then I would consider it an overkill to produce a whole additional transcription within <text> just in order to do this. I therefore put this in a TEI feature request some weeks ago, but for the time being, customization will do.
I know of course, if you begin relaxing the content model of line, other requests will follow up pretty soon. Nevertheless, I'm in favor of this relaxation, but would suggest to carefully consider every new request separately.
Von: TEI (Text Encoding Initiative) public discussion list [mailto:[log in to unmask]] Im Auftrag von Martin Holmes
Gesendet: Dienstag, 4. Februar 2014 21:50
An: [log in to unmask]
Betreff: Re: [TEI-L] Embedded transcription and text structure
I often find myself wishing that every element and attribute were
available in every context; in other words, that there be no restriction
on content models whatsoever. This is usually when I find myself
confronted by a structure which is so clearly (to me) an X inside a Y,
but it proves impossible to convince anyone else on Council that Xs
really do appear inside Ys.
Nevertheless, the issue here isn't really one of
what-should-be-allowed-in-what; it's more a question of a principled
separation of concerns. Using <sourceDoc> implies, I think, an approach
to transcription which is inimical to the kinds of categorization
implied by <list> and <item>. If it seems overly redundant or intricate
to transcribe text twice (albeit in two different ways), or to deal with
the slightly tricky linking mechanisms required to handle the
relationship between <sourceDoc> or <facsimile> and <text>, then a
practical approach would be to create a customization allowing
whatever-you-want wherever-you-want, and coupling this with an XSLT
transformation which generates the clean separation in a conventional
TEI-conformant file suitable for archiving or interchange.
On 14-02-04 12:37 PM, Patrick Sahle wrote:
> James, Martin and Frederik,
> I completely understand the genesis and intention of <zone>. In a way
> I'd even concede that it is somehow consistent.
> I just wanted to give some feedback that not everybody must be perfectly
> happy with it. As I said, I for myself would rather like to go the whole
> way from visual evidence to semantic interpretation through one thread
> instead of having to switch from sourceDoc to text at a certain point
> and make complex linkages between the two. Mainly because I don't see
> this point indicated by our reading procedures. Of course I see the
> problems of overlapping hierarchies ...
> Of course, typed zones can take us at least a step further. But here we
> get a good argument for more explicit elements at the same time:
> <zone type="list">
> <zone type="item">
> It's an item _because_ it's in a list. Do we really want to express this
> dependency by using attributes?
> Best, Patrick
> Am 04.02.2014 18:24, schrieb Frederik Elwert:
>> Dear all,
>> Am Dienstag, den 04.02.2014, 18:01 +0100 schrieb Patrick Sahle:
>>> Am 04.02.2014 17:21, schrieb Gerrit Brüning:
>>>> Dear all,
>>>> Ulrike's and Matt's statements are further evidence that the
>>>> currently very strict content model of <line> can not be maintained.
>>>> The strictness only seems to stimulate a variety of workarounds.
>>> to me the problem is not the content model of <line> but the content
>>> model of <zone>
>>> When I read Ulrike's initial post ...
>>> <line>5. <seg xml:id="S1">Trad. de A.C.</seg> – <hi rend="underline">The Keeper of Sheep</hi>.</line>
>>> <line>6. <seg sameAs="#S1" rend="line"/> – <hi rend="underline">Le Gardien des<hi rend="superscript">e</hi> Troupeaux</hi>.</line>
>>> ... what bothered me was the fact that in my view there are no lines
>>> at all - but entries of a list, or list items
>>> Intuitively I would have liked something like this:
>>> I see that I cross the border between the visual perception of the
>>> document and the rather abstract description of a textual structure
>>> here. But to me, a good transcription might be the protocol of a
>>> reading process - and that one take these steps: "I see an area on the
>>> page, it contains a list, the list contains entries, the entries
>>> consist of letters and signs ..."
>> I think I’d see the visual representation and the textual structure both
>> as valid, but rather separate interpretations of the same source. In a
>> similar discussion with Egyptologists, we came up with a linking
>> mechanism, something along the lines of:
>> <line xml:id="l1">5. <seg xml:id="S1">Trad. de A.C.</seg> – <hi rend="underline">The Keeper of Sheep</hi>.</line>
>> <line xml:id="l2">6. <seg sameAs="#S1" rend="line"/> – <hi rend="underline">Le Gardien des<hi rend="superscript">e</hi> Troupeaux</hi>.</line>
>> <item n="5." xml:id="i1"> ... </item>
>> <link target="#l1 #i1"/>
>>> Best, Patrick
>>>> Am 04.02.2014 16:19, schrieb Matthew Davis:
>>>>> Dear Ulrike,
>>>>> I ran into something similar in that I needed to use <ex> under
>>>>> <line>. What I ended up doing is wrapping the actual
>>>>> transcription in an <orig> tag, which then allowed me to use many
>>>>> of the tags that were otherwise unavailable under <line> directly.
>>>>> Perhaps you can do something similar?
>>>>> All best,
>>>>> On Feb 4, 2014, at 10:12 AM, Ulrike Henny
>>>>> <[log in to unmask]> wrote:
>>>>>> Dear list,
>>>>>> if I would like to transcribe a source document inside of
>>>>>> <sourceDoc> because I am interested in its physical realization,
>>>>>> how can I represent text parts or zones that "look like"
>>>>>> headings, paragraphs or lists, for example?
>>>>>> Would those simply be zones (maybe typed somehow) and list items
>>>>>> with labels marked up as single lines or as segments?
>>>>>> Why is it not possible to use the corresponding structural
>>>>>> elements inside of <surface> or <zone>?
>>>>>> Best regards,
>>> Cologne Center for eHumanities (CCeH) (Substitute, Professorship on
>>> Digital Humanities)
>>> Institute for Documentology and Scholarly Editing (Member)
>>> Postal: Cologne Center for eHumanities (CCeH), Universität zu Köln,
>>> Albertus-Magnus-Platz, D-50923 Köln
>>> Office: Universitätsstr. 22, Attic floor right
>>> Telephone: +49 - (0)221 - 470 3894
>>> Latest Publication: Patrick Sahle, Digitale Editionsformen -
>>> Further information:http://www.uni-koeln.de/~ahz26
> Cologne Center for eHumanities (CCeH) <http://www.cceh.uni-koeln.de/>
> (Substitute, Professorship on Digital Humanities)
> Institute for Documentology and Scholarly Editing <http://www.i-d-e.de>
> Postal: Cologne Center for eHumanities (CCeH), Universität zu Köln,
> Albertus-Magnus-Platz, D-50923 Köln
> Office: Universitätsstr. 22, Attic floor right
> Telephone: +49 - (0)221 - 470 3894
> Latest Publication: Patrick Sahle, Digitale Editionsformen -
> Further information: http://www.uni-koeln.de/~ahz26