040 $b has only come into general use in the last few years.  OCLC says, "Historically in WorldCat the absence of subfield ǂb in field 040 has indicated that English is the language of cataloging. OCLC now prefers always coding this element." ( 

The WorldCat version of LCCN 93019721 does have 040 $b eng, but it also has about 30 additional symbols in 040 $d.  Any one of them could have added $b, including OCLC.

John Hostage
Senior Continuing Resources Cataloger
Harvard Library--Information and Technical Services
Langdell Hall 194
Harvard Law School Library
Cambridge, MA 02138
[log in to unmask]
+(1)(617) 495-3974 (voice)
+(1)(617) 496-4409 (fax)
ISNI 0000 0000 4028 0917

-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Wednesday, December 20, 2017 11:25
To: [log in to unmask]
Subject: Re: [BIBFRAME] CC:AAM Statement in Support of the Internationalization of BIBFRAME

On 12/19/17 8:15 AM, Jennifer Martin wrote:
> Regarding "the language of the catalog" (or "language of cataloging"), under MARC, it is encoded in 040 $b (field 040 subfield b). So it is currently coded in most libraries' metadata. The language of cataloging matters when dealing with strings supplied by the cataloger (as opposed to transcribed from the resource); for example, "172 pages" makes sense to an English speaker, but "172面" or "172 stran", not so much.

Thanks, Jennifer. I didn't remember seeing this subfield, but I haven't been looking at many MARC records lately. However, when I look at records in catalogs, such as in LC's catalog, that subfield is not there for older items.
  040	__	 |a DLC |c DLC |d DLC

(I can't see MARC tags in OCLC so I can't compare this to the OCLC version. Anyone? Thanks.)

I do see it in newer ones:
   040	__	 |a DLC |b eng |c DLC |e rda |d DLC

OCLC statistics show it as very highly used.

This makes me wonder if this isn't a new practice, and that OCLC has added them during its record import or perhaps has done a cleanup. Many or most catalogs can be associated unambiguously with a single language of the catalog.

BIBFRAME copies over the language of catalog if it is in the MARC record:

But does not add it if it is not:

(it is "descriptionLanguage")

If it is true that the language of catalog has been added by OCLC where it is missing, the converted BIBFRAME records will not have that unless it is added to the conversion code. In any case, it does make sense to add it as records are converted for those catalogs where it will always be the same.


> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] On Behalf Of Karen Coyle
> Sent: Tuesday, December 19, 2017 9:32 AM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] CC:AAM Statement in Support of the 
> Internationalization of BIBFRAME
> On 12/17/17 3:56 PM, Andrew Cunningham wrote:
>> Karen,
>> language taging is complex. In the first instance there is the 
>> language of the object/resource being describe.
> Yes, which is why I suggested that the language tagged is limited to the language of the resource.
>> Then there is the language used in the BIBFRAME doc, which may not be 
>> the same as the language of the object being described.
> We generally refer to this as "the language of the catalog." That isn't coded in our metadata, AFAIK, although I wonder if CanMARC covered that, since they often produce both an English-catalog and a French-catalog version. Anyone?
>> Some strings may also be in language of the object, in script and in 
>> romanisation.
>> Depending on the userver of the BIBFRAME document all the above need 
>> to be included.
>> For instance an institution that is displaying daat in a Web 
>> interface and need to meet accessibility requirements will need to 
>> mark up all changes in language.
>> Identifying lanGuage of strings may affect browers choice of language 
>> or what localised features are applied during rendering.
>> For instance in most library catalogue language markup is non existent.
>> So Traditional Chinese text will be displayed by either a Japanese 
>> font or a simplified Chinese font. Browsers will never use a 
>> traditional Chinese font if language markup is not present.
> Do browsers have markup within the page for this? I'm aware of the 
> head language encoding, but not of individual elements in the page. I 
> guess that CSS may add something - I'm not up with everything you can 
> do today. However, there is a big problem with trying to attribute
> *language* to fields in bibliographic data. It only takes a few examples to understand why:
> Title:
> 1984 (book in German)
> 1984 (book in Hebrew)
> 1984 (book in English)
> Title:
> Marie Antoinette (book in English)
> Marie Antoinette (book in Swedish)
> Author:
> Wong, Mario (a real name, altho not an author)
> If special exceptions are need for the unified ideograms, then I see that as an exception that affects display, not a general declaration of the language of strings.
> kc
>> Most if not all library catalogues fail to meet what I would consider 
>> minimum Web internationalization standards.
>> This is partly due to limitations in MARC itself and how it is used.
>> BIBFRAME needs a robust internationalization model other wise its 
>> usefullness will be limited in the wider context of the Internet.
>> Andrew
>> On 15 Dec 2017 02:12, "Karen Coyle" <[log in to unmask] 
>> <mailto:[log in to unmask]>> wrote:
>>     It is very important to consider internationalization early on the life
>>     of a standard, so this is an important effort.
>>     I noticed what appears to be a confusion (which it may be only in the
>>     wording) in the section on language tags. BCP47 is defined as "(Internet
>>     Best Current Practice for the use of language tags in cases where it is
>>     desirable to indicate the language used in an information object)." The
>>     next paragraph refers to "romanized fields". I interpret BCP47's
>>     "information object" to be the object that is described by the metadata,
>>     not the metadata itself, although it could presumably be used for
>>     either. However, defining the language of individual metadata fields is
>>     fraught, and I don't think you are suggesting that. It would be good to
>>     be clear (if this is what you mean) that language codes are defined for
>>     described resources, and that only transliteration is coded for metadata
>>     fields.
>>     kc
>>     On 12/13/17 12:30 PM, Robert J. Rendall wrote:
>>     > Colleagues -
>>     >
>>     > The ALA/ALCTS Committee on Cataloging: Asian and African Materials
>>     > (CC:AAM) has voted to approve a Statement in Support of the
>>     > Internationalization of BIBFRAME, containing recommendations on
>>     > character encoding, the representation of original script and
>>     > romanization, normalization, and language tags:
>>     >
>>     >
>>     <>
>>     >
>>     > Robert Rendall
>>     > Chair, CC:AAM 2017-2018
>>     >
>>     <>
>>     >
>>     > Robert Rendall
>>     > Principal Serials Cataloger
>>     > Original and Special Materials Cataloging, Columbia University
>>     Libraries
>>     > 102 Butler Library, 535 West 114th Street, New York, NY 10027
>>     > tel.: 212 851 2449 <tel:212%20851%202449>  fax: 212 854 5167
>>     <tel:212%20854%205167>
>>     --
>>     Karen Coyle
>>     [log in to unmask] <mailto:[log in to unmask]>
>>     m: +1-510-435-8234 <tel:%2B1-510-435-8234>
>>     skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
>> --
>> Andrew Cunningham
>> [log in to unmask] <mailto:[log in to unmask]>

Karen Coyle
[log in to unmask]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600