LISTSERV mailing list manager LISTSERV 16.5

Help for TEI-L Archives


TEI-L Archives

TEI-L Archives


TEI-L@LISTSERV.BROWN.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEI-L Home

TEI-L Home

TEI-L  January 2019

TEI-L January 2019

Subject:

Re: Use restore for an editorial action?

From:

Torsten Schassan <[log in to unmask]>

Reply-To:

Torsten Schassan <[log in to unmask]>

Date:

Wed, 30 Jan 2019 14:53:03 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (143 lines)

Hello,

I guess we have a twofold problem here:

- For once we have to distinguish between "editorial" interventions that
took place inside the source and those carried out by the modern editor.

- Secondly, we might want to decide whether the (TEI) elements by itself
are meant to (or could) express this distinction.

I suppose that Peter was talking about an authorial deletion which a
modern editor would like to restore, right? If this is the case, I would
dare say the use of @hand is not the best way to express this relation,
I would prefer to use @resp on <restore>. If, and only if, <restore>
could be considered to testify modern editorial interventions at all.

Thomas on the other hand is describing the presentation of the edition
only in which a piece of text is either shown or not. But the decision
of the editor to restore some "faulty" deleted text is stored in the
transformation. I think this decision should be documented in the
(edition's) source code i.e., the TEI-XML file. Using a proper element
or attribute.

Frederiks remark seems to be a reasonable (and the preferable) solution.

IMHO, the definition of <restore> doesn't exclude the interpretation of
Peter: The authorial marking is in the source and the (modern) editor
carries out the restoration. Unfortunately, the explanation of the use
of <restore> in the guidelines limits the semantics of the element to
the author or scribe. I guess we have to decide whether we want to limit
the use of the element down to the source and adjust the definition or
to allow to express the (modern) editorial decision using this element
and adjust the guideline's text accordingly.



Best, Torsten


Am 30.01.2019 um 13:42 schrieb Frederik Elwert:
> Hello Peter,
> 
> if you want to include that information you could also look into the @status attribute of <del>. It’s scope is a bit different, but in another project I used status="faulty" to mark an intervention that the editor did not agree with. (If faulty is too strong, you might find another value that better represents the editor’s rationale.)
> 
> In the XSLT, a test for @status = "faulty" then reversed the usual action: Not omit a deletion, not include an addition, not perform a substitution.
> 
> Interestingly, "faulty" is not included in the list of sample values, but it is mentioned in the usage note (probably as a super-category of the supplied values):
> 
>> Marking a deletion or addition as faulty is inescapably an interpretive act; the usual test applied in practice is the linguistic acceptability of the text with and without the letters or words in question.
> 
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.transcriptional.html
> 
> Best,
> Frederik
> 
> Am 30.01.19 um 13:28 schrieb Thomas Stäcker:
>> Peter,
>> I am not sure about this. What is usually meant is that an author
>> strikes through a passage, but by realizing that it was wrongly done
>> adds some dashes below the word to restore the previous state. As in the
>> case of rend/rendition/style I tend to limit the use of <restore>  to
>> phenomena I see in the source in front of me and wouldn't use it for the
>> purpose of providing a special view on the document.  Your meaning of
>> "editorial" here seems to suggest a particular output  produced by an
>> e.g. XSLT. Accordingly I'd rather use a xml:id attribut for the relevant
>> <del> element  and display it by XSLT whereas the other <del> elements
>> are left out.
>> Best,
>> Thomas
>>
>>
>> Am 30.01.2019 um 09:58 schrieb Peter Boot:
>>>
>>> Hello list,
>>>
>>>  
>>>
>>> In one of our editions, the bits of text that the author deleted,
>>> marked as <del>, are not shown in the final reading text. Suppose
>>> there is also a larger text fragment that was deleted, which, as an
>>> exception, the editor wants to include in the reading text. How would
>>> you feel about encoding this as:  
>>>
>>>  
>>>
>>> <restore hand="#editor"><del> …. deleted text …. </del></restore>
>>>
>>>  
>>>
>>> The definition of <restore> says ‘restoration of text to an earlier
>>> state by cancellation of an **editorial** or authorial marking or
>>> instruction’. So to me this seems perhaps strange, but still entirely
>>> legitimate.
>>>
>>>  
>>>
>>> Any opinions? Handle this in a rend attribute perhaps?
>>>
>>>  
>>>
>>> Peter
>>>
>>>  
>>>
>>>  
>>>
>>> Peter Boot ([log in to unmask]
>>> <mailto:[log in to unmask]>)
>>>
>>> Senior researcher
>>>
>>> Huygens Institute for the History of the Netherlands (Royal
>>> Netherlands Academy of Arts and Sciences)
>>>
>>> http://www.huygens.knaw.nl/boot/ 
>>>
>>> http://peterboot.nl/
>>>
>>> Tel.: +31 20 2246825
>>>
>>>  
>>>
>>
>> -- 
>> ***************************************
>> Prof. Dr. Thomas Stäcker
>> Direktor der
>> Universitäts- und Landesbibliothek Darmstadt
>> Magdalenenstr. 8
>> 64289 Darmstadt
>> +49 (0)6151 16-76200
>> [log in to unmask]
>>
> 


-- 
Torsten Schassan - Digitale Editionen, Abteilung Handschriften und
Sondersammlungen
Herzog August Bibliothek, D-38299 Wolfenbuettel, Tel. +49 5331 808-130
Fax -165
Handschriftendatenbank <http://diglib.hab.de/?db=mss>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Error during command authentication.

Error - unable to initiate communication with LISTSERV (errno=111). The server is probably not started.

Log In

Log In

Get Password

Get Password


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

ATOM RSS1 RSS2



LISTSERV.BROWN.EDU

CataList Email List Search Powered by the LISTSERV Email List Manager