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

[Laurent Romary]

And my apologies for the huge amount of typos in my messages...

Le 22 janv. 09 à 10:38, Laurent Romary a écrit :

> 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
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council