Dear all,

Thank you very much for sharing all this and rising up that, even if
palimpsest phenomenon is a simple issue (not an easy one), the palimpsest
phenomenon is still a complex issue. I'll try to share with you my
understandings, so you could maybe correct me.

I looked at Fragmentarium projects in search of xml code. I might have
missed something, I have not found some xml code:

Would it be possible please to give us a link eventually?

I also read the following codes.

such as in this one:

andthe xml code of this one:

On E-codices, the xml files for the descriptions (standard and additional)
of the manuscript, and the palimpsestic phenomenon, as far as I understand
it, are expressed in the code especially with various MSPARTS and
MSCONTENTS. It is a very accurate, precise and understable encoding. At the
same time it remains difficult for me to understand that we are making a
difference between two parts of a TBO and that those two parts are the same
part of the TBO.

Elements ZONE and SURFACE are confusing us for the same reasons more or
less, and I might have misunderstood, so please do not hesitate to
rephrase. They are confusing us because:

1- a ZONE (or a SURFACE) is unique (like the part of a manuscript). If
there are two tags, there are two different zones or two different
surfaces. One cannot refers to the same topological reality saying that
there are two different topological realities. For those who finds help in
philosophy, it refers to concept "identity of indiscernibles".

2- ZONE and SURFACE, for now, are defined as two dimensional elements. A
surface can be tridimentional and three dimentional writings exist even in
Ancient Egypt.

For me, a palimpsest phenomenon refers more to a stack - like a sandwich if
I may use such a metaphore. Bread, ham and cheese are not in the same zone
nor in the same surfaces. Otherwise, the sandwich would be flat. Instead of
metaphore, I would like to add some arguments related to GIS (we are
mapping several layers of geographical information on the same topological
reality), 2-d, 3-D, specchio epigrafico and so on, but I'd like to keep
this email short and I would add them later if it helps to make progress.

In my first email I used the word "layer" because it is the one the
epigrapher uses and also the one of the digital modelling we use for the
same problem: layers of writings, layers of texts that are autonomous but
not independent because of the unicity of their materiality. They can be
distinguished, but they cannot be separated. It is a bit holistic. It texts
are overlapping it is because there writings are overlapping two And the
only surface or zone they have in common is the one were writings (or any
element that create the text) are overlapping, I suppose.

Lou Burnard used the word "layer" too, a couple of time, in his previous
answers. When I checked the TEI guidelines, the word "layer" appears a
couple of time and only in written Enligh when the word was useful to
explain something in English, not like a specific concept: "layers of
responsabilities". It is very useful to understand ANNOTATION block, for

I am not asking for two new tags such has a STACK element that could
contain two or more tag LAYER. But I am unfortunately a very lazy and bad
encoder and when I got lost this way I tend to make abusive uses of AB
element and @TYPE.

For now, I need to record this palimpsest situation in a way that is easy
to change automatically afterwards, once a solution will be applied by
everybody. I was taking in consideration to produce temporarily an
antonomous xml file by layer and to indicate in each file that there is a
relationship dependency with the other xml file. There will be a lot of
redundancy, but it does not cost a lot. Would that be too unorthodox? I
count on your indulgence and I do thank you very much.



2016-06-21 16:54 GMT+02:00 Kevin Hawkins <
[log in to unmask]>:

> Ah, but this is misrepresenting Torsten's question.  He asked if
> profileDesc relates to the *text* of the source document, not to the
> physical source document itself.  Lou and I argued over this in October
> 2011.  While we agreed that profileDesc is not about the physical source
> document, in the end we admitted that profileDesc is ambiguous on the
> matter that Torsten raises.  --Kevin
> On 6/20/16 8:54 AM, Lou Burnard wrote:
>> <creation> is intended to hold information about the creation of the
>> TEXT, not the document/s attesting it. For example, suppose we encode
>> the text of a poem known to have circulated in manuscript form during
>> the 16th century, but of which no copy text survives earlier than the
>> 20th. The profileDesc/creation  might talk about the fact that the poem
>> was created in the 16th c; the sourceDesc should describe the 20th c.
>> source document/s from which we made the encoding; the revisionDesc
>> should describe the history of the encoded version itself./s
>> This seems quite unambiguous to me in the current description of
>> <creation> in the Guidelines, (probably because I wrote it).
> On 20/06/16 15:34, Torsten Scha├čan wrote:
>>> Dear Matthew, dear all,
>>> this is something I always "struggle" with: Does the description
>>> within <profileDesc> relate to the text of the TEI file or to the text
>>> of the document represented, i.e. described, transcribed etc, in the
>>> TEI file?