[tei-council] [Fwd: [ tei-Feature Requests-2909766 ] make <del> and <add> (etc) dateable]

[Elena Pierazzo]

Hi,
Sorry for slow replies, I was, ehm, on holiday!

Yes James is right here, this is addressed in the genetic module in 
several ways according to the complexity of the case, but the simplest 
one is by the use of an attribute @stage so you can express that some 
additions/deletions or indeed other operation in the document belong to 
the same stage of revision. Stages are defined and dated into the 
header. Have a look at 
http://users.ox.ac.uk/~lou/wip/geneticTEI.doc.html#stages

Question is: should we hold this until the genetic module is ready for 
the council to be submitted, or should the council act as we did not 
know that such a module is in preparation?

Elena

James Cummings wrote:
> Hiya,
>
> I think I'm very slightly against this because of exactly the point 
> Sebastian later made about using @when to record when we decided 
> something.  Even if in the case of add/del we were recording the date at 
> which we thought the addition/deletion took place, we already have 
> mechanisms in place to do this. (timeline being one of them)  Also, 
> where does it stop?  Surely any act of scribal interaction with a 
> document could be similarly time coded? Then any act of editorial 
> interpretation.... then every act of encoding of the document.  Does it 
> really get us anywhere?  Technically someone could already do that with 
> a TEI document (with a stand-off solution being the easiest to implement).
>
> Surely this is a concern in genetic editing? Has the group of people 
> working on the Genetic ODD added anything additional to deal with 
> time/order or authorial interventions?  If so, it would make sense to 
> examine that before deciding on this.
>
> If I was too lazy to use timeline or similar though I'd probably just 
> do: <add><date notAfter="1802"/>foo</add>.  While a little bit 
> incorrect, probably, it does embed a date inside the add and so work for 
> purposes of processing.
>
> -James
>
> Laurent Romary wrote:
>   
>> I add my vote, with the word of caution that this should probably not  
>> be extended to any element taken at randon in the TEI (cf. the <death  
>> when> (counter-)example). The ad/del combinaiton with when is  
>> straightforward, though.
>> Laurent (from Hong Kong...)
>>
>>     
>>>> Initial Comment:
>>>> I am using <del> and <add> to mark changes in a born-digital  
>>>> document, and I know the exact date of the additions and deletions.  
>>>> It seems obvious to me that I should be able to say <add  
>>>> when="2009-11-01">, of course</add>. Can we just add these elements  
>>>> to the dateable class?
>>>> Message:
>>>> Slippery slope warning. The date is presumably unambiguously always  
>>>> the
>>>> date that the addition or deletion was made, rather than the date  
>>>> that it
>>>> was identified by the encoder? So I can say <add
>>>> notAfter="1802">wibble</add> for an addition which I think was made  
>>>> before
>>>> 1802. Of course some bright spark will now ask for the ability to  
>>>> record an
>>>> addition that was (prior to evidence uncovered in 1904) believed to  
>>>> be 19th
>>>> century, but which is actually much older.
>>>>         
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>   

-- 

Dr Elena Pierazzo

Research Associate

Centre for Computing in the Humanities

King's College London

26-29 Drury Lane

London WC2B 5RL


Phone: 0207-848-1949

Fax: 0207-848-2980

elena.pierazzo[at]kcl.ac.uk

www.kcl.ac.uk/cch