[tei-council] AMBER for your action

[Dan O'Donnell]

Gabriel Bodard wrote:
> Dan O'Donnell a écrit :
>   
>>> 2672530 	Remove repository element requirement in msIdentifier
>>>       
>> Here I wonder if the problem may involve the semantics of the element 
>> name which could be adjusted with some minor changes. What Hugh is 
>> really concerned about is that he thinks that some material has 
>> locations rather than repositories. Looking at the element description, 
>> I see that repository is very manuscript centric--in fact much more than 
>> our description of the applicability of the module:
>>
>> Element: contains the name of a repository within which manuscripts are 
>> stored, possibly forming part of an institution
>> Manuscript module description: Although originally developed to meet the 
>> needs of cataloguers and scholars working with medieval manuscripts in 
>> the European tradition, the scheme presented here is general enough that 
>> it can also be extended to other traditions and materials, and is 
>> potentially useful for any kind of inscribed artefact.
>>     
>
> The point here is not so much the definition of 'repository', but the 
> fact that some text-bearing objects just aren't held by any kind of 
> institution. I think repository *is* a useful concept as apart from just 
> place: something that's in a museum or a library or a university or an 
> auctioneer's warehouse or even a private collection should be recorded 
> explicitly as such. But the repository element shouldn't be required for 
> an object that is a graffito on an outside wall, a text carved into the 
> face of a cliff, the pavement of a street, etc. Or an item now lost, of 
> which all we know is that it was once seen "in a field outside 
> Aphrodisias in the 18th century".
>   
I guess my problem is that the examples provided all seem to have either 
a location instead of a repository--a kind of regular contrast that 
suggests to me that we are really talking about the same thing and that 
it is the natural language semantics of word "repository" that is 
getting in the way. If we'd called the element "location" instead, would 
this problem exist? A manuscript location could be in a library 
(Location: british library). A graffito could have a non-repository 
location: "on the south wall of the third stall from the west in the 
men's room on the second floor of the british library."

What I'm getting at is that, like Polkaroo and the male host on the 
Canadian children's show "the Polka Dot Door," locations and 
repositories seem never to be seen together (at least not in the 
examples we're getting): suggesting they might be one and the same 
thing, in terms of encoding.
>   
>>> 2209933 	content model of 'am' (cf bug 2542813)
>>>       
>> maybe.
>>
>> https://sourceforge.net/tracker/index.php?func=detail&aid=2209933&group_id=106328&atid=644065
>>
>> This is an old problem similar to what used to affect w: that is to say 
>> if you are transcribing for meaning by indicating am, are you really 
>> also transcribing for diplomatic features like unclear? What is striking 
>> in each of the cases Gabriel supplies is that he in fact knows what the 
>> resolution is, indicating that from the perspective of the text (rather 
>> than its diplomatics) the text is not unclear.
>>     
>
> I don't see how the fact that we "know" what the resolution is changes 
> the status of the transcription of the text in this case. I can say that 
> a 'G' is unclear even if I can speculate with some confidence that it 
> must (from context) be a 'G'; even more obviously I can say that a 'G' 
> has been deleted even if it is still perfectly visible on the page. In 
> any case, I can tag a symbol as <am> even if I don't know the resolution 
> of the abbreviation.
>
>   
>> I'm sympathetic to the processing issues, but found myself working with 
>> w that there is some real reason in the current madness. Elena makes a 
>> good point in her comment. If we say no here (and even if we don't), 
>> perhaps we need to look at abbr?
>>     
>
> I'm not sure I get the first part of what you're saying here, but if I 
> do understand then surely the solution is for you to have a rule in your 
> local encoding practice (or schema customization) not to tag 
> text-transcriptional information inside <am> (or abbr, aut sim.) in 
> certain contexts (or just to ignore it in processing). There are clear 
> cases where we *do* need such tagging in core TEI.
>   
I think there is a larger issue going on, but your solution is probably 
the only way forward since w was expanded to allow non-linguistic 
content. I certain understand the frustration people feel in these 
circumstances (having felt it myself). And while I think there is an 
intellectual reason for not allowing it, I think this is a case where 
lack of theoretical purity makes one a more pleasant person. So let me 
change to yes.
> Best,
>
> G
>
>   


-- 
Daniel Paul O'Donnell
Associate Professor of English
University of Lethbridge

Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/)
Founding Director, Digital Medievalist Project (http://www.digitalmedievalist.org/)
Chair, Electronic Editions Advisory Board, Medieval Academy of America

Vox: +1 403 329-2377
Fax: +1 403 382-7191 (non-confidental)
Home Page: http://people.uleth.ca/~daniel.odonnell/