[tei-council] Fwd: Issues related to the bibliographical work

[Lou Burnard]

[These issues are all -- regrettably -- 1.1 concerns, but I have 
commented on them anyway]

Laurent Romary wrote:
>
>> 2. We are missing means to represent all types of affiliation 
>> information, typically:
>>
>> 2.a there is neither a "phoneNumber" element nor the possibility to 
>> type addressLine

There is however a class model.addrPart, to which you can add such 
elements. I quote
"Addresses may be encoded either as a sequence of
lines, or using any sequence of  component elements from the
model.addrPart class. Other non-postal forms of address, such as
telephone numbers or email, should not be included within an
<gi>address</gi> element directly but may be wrapped within an
<gi>addrLine</gi> if they form part of the printed address in some
  source text."

in other words -- addrLine is meant to contain the lines of a printed or 
written  address, which is why it isn't typed. If you want to interpret 
the function of those different lines, you need more elements. You could 
certainly argue that we need a generic addrPart element, but addrLine 
isn't it.

>> 2.b <email> is not allowed in <address>, nor <affiliation>

See above, re email (it's a kind of an address, not a component of one).

Affiliation is a property of a person, not an address.

>>
>> See the illustrating example below:
>>     <analytic>
>>         <author>
>>             <forename>Telikepalli</forename>
>>             <surname>Kavitha</surname>
>>             <affiliation>
>>                 <orgName>CSA Department</orgName>
>>                 <orgName>Indian Institute of Science</orgName>
>>                 <address>
>>                     <settlement>Bangalore</settlement>
>>                     <postCode>560012</postCode>
>>                     <country>India</country>
>>                     <addrLine type="phone">+91-80-22932386</addrLine>
>>                     <addrLine type="fax">+91-80-23602911</addrLine>
>>                 </address>
>>             </affiliation>
>>             <email>_kavitha at csa.iisc.ernet.in_ 
>> <mailto:kavitha at csa.iisc.ernet.in></email>
>>         </author>
>>   </analytic>

This is an interesting example: you are treating <author> as if it were 
a special form of <person> rather than of <persName>, which is 
plausible, but has the same problem -- will you record this level of 
detail for every one of Kavitha's works?

>>
>>
>> 3. It's a pity that we can have <orgName> in affiliation, but not 
>> <org>, since we may want to add extra information 
>> about organizations which are not information about the name proper (I 
>> know Lou will be sensible to this argument).

Well, yes, I am -- but I don't agree with the idea of using <org> where 
you really mean <orgName>. Information about orgn which isnt about the 
name does not belong inside the orgName.

  Would we go in this
>> direction, it would then be nice to have things like <address> in <org>.

An <org> can have many addresses, different ones at different times for 
example. So it's a kind of orgState or orgTrait maybe?

>> By the way, it seems that <org> and <institution> are highly redundant 
>> (even if <institution> is limited to manuscripts descriptions)
>>

do you mean that they are effectively synonymous? if so, yes, I agree.


>> <affiliation>
>>     <org type="institution"> <!-- NOT ALLOWED in <affiliation>, but 
>> desirable, isn't it? -->

No. you mean <orgName ref="#MPIG">Max-Planck-Gesellschaft</orgName> or
( <orgName key="MPIG">MPIG</orgName> )