Print

Print


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: 

http://fragmentarium.ms/case-studies.html

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


I also read the following codes.

such as in this one: http://www.e-codices.unifr.ch/xml/tei_published/csg-0194.xml

andthe xml code of this one: http://dcl.slis.indiana.edu/petrarchive/content/c026r.xml

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 instance.

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.

ML




 
ML

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?