[tei-council] Proposal <idno> coverage -SF 2493417

[Laurent Romary]

As a matter of fat, we speak of application where <author> is not a  
text only element. The standard case would be a descrtion provided by  
a publisher (I have tons of example in the context of the EU PEER  
project) or a publication repository, namely:
                     <author>

                         <idno type="isni">12345xx79</forename>

                         <forename>Laurent</forename>

                         <surname>Romary</surname>

                         <affiliation>

                             <orgName>Max Planck Digital Library</ 
orgName>

                             <address>

                                 <street>Invalidenstr. 35</street>

                                 <postCode>10115</postCode>

                                 <settlement>Berlin</settlement>

                                 <country>Deutschland</country>

                             </address>

                             <email>... at ...</email>

                         </affiliation>

                     </author>


Le 22 janv. 09 à 10:30, Lou Burnard a écrit :

> Yes, apologies for forgetting that! it is a strong argument for not  
> using @key in this case, I agree. But I remain unhappy with the idea  
> of introducing additional elements inside what is basically a text  
> only element like <author>. Another possibility I suppose might be to
> put all the <idno>s for an item together, outside <author> or  
> <publisher> ?
>
> Laurent Romary wrote:
>> The other (important) argument is that we need to have more then  
>> one <idno> for one author (cf. examples provided by Peter).
>> Le 22 janv. 09 à 10:04, Lou Burnard a écrit :
>>> Sorry to be picky, but  if I have understood it correctly, the  
>>> existing proposal certainly does break current encoding  
>>> practice.My understanding is that the current proposal would  
>>> include the new <idno> as a child of <author>, title etc. Please  
>>> tell me I am wrong if that is not the case!
>>>
>>> If the only argument against using the existing @key to provide an  
>>> identifier of this kind is that it does not allow you to specify  
>>> the source for the associated range of keyv values, why not  
>>> propose an additional @keySource attribute to att.naming? That  
>>> would integrate very nicely with current practice, avoid  
>>> duplication, and add a useful new feature.
>>>
>>>
>>>
>>> , Laurent Romary wrote:
>>>> Hi all,
>>>> Whether or not it is a major semantic shift, the  proposal has  
>>>> the property not to break existing usage and integrate smoothly  
>>>> in the encoding practices that lay behind the use of <idno> for  
>>>> other bibliographical component (note that an ISSN reference does  
>>>> not sit around on a shelf either: its an abstract entity allowing  
>>>> one to identify groups of publications ) one culd use the same  
>>>> argument to mean that an author identifier groups all papers from  
>>>> one author).
>>>> Anyhow, I fully support Peter's argumentation.
>>>> Laurent
>>>> Le 21 janv. 09 à 23:11, Lou Burnard a écrit :
>>>>> Peter Boot wrote:
>>>>>> This does not involve, as Syd wrote on the TEI in Libraries
>>>>>> mailing list
>>>>>> (https://listserv.indiana.edu/cgi-bin/wa-iub.exe?A2=ind0901B&L=TEILIB-L&T=0&F=&S=&P=2774 
>>>>>> ),
>>>>>> a ‘semantic shift’: <idno> would have the same meaning it  
>>>>>> always had, it
>>>>>> would just be applied to new elements.
>>>>>
>>>>> That is *precisely* what I would consider to be a semantic shift!
>>>>> We have an element called "persName" which has the semantics of  
>>>>> "name
>>>>> applied to a person". If we redefine it to mean "name applied to a
>>>>> vegetable", it's still a name, but its semantics have changed.
>>>>>
>>>>> Similarly the current meaning of <idno> is that it's "an  
>>>>> identifier for
>>>>> a bibliographic item". Authors are not bibliographic items. They  
>>>>> do not
>>>>> (usually) sit around on shelves, and you cannot ask for a copy  
>>>>> of one!
>>>>> By all means let's expand its semantics to include authors  
>>>>> (etc), if we
>>>>> want to do that, but let's not pretend we're not making a major  
>>>>> change
>>>>> in the meaning of this element.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tei-council mailing list
>>>>> tei-council at lists.village.Virginia.EDU
>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council