LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  December 2017

BIBFRAME December 2017

Subject:

Re: CC:AAM Statement in Support of the Internationalization of BIBFRAME

From:

Karen Coyle <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Sun, 24 Dec 2017 12:21:42 -0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (204 lines)

Thanks, Stephen, for the reminder about authorities, especially since we
need to be thinking about how we will blend authorities and bibs in a
linked data future. The authority aspect is important and shouldn't be lost.

I still am unclear what the use cases are for this information. The only
one I can come up with off the top of my head is being able to show a
user a title or author in a language or script of their choice, rather
than the language of the resource itself. But, as Osma said, that can
probably be added to the strings based on the language of the resource;
and that can be a pre-processing step or it could even be built into the
design if we have works and expressions ("show me title for this
work/expression in x language" could find all expressions in that language).

If a large number of cases are covered by a combination of the language
of the resource and the language of the catalog, then we're probably at
the 90% rule or more, and catalogers are already giving us what we need
for this.

kc
p.s. This brings up another conundrum which may be solved by
authorities: the information in the current catalog vs. general
bibliographic information. If my library does not have Name of the Rose
in Chinese that information has to come from a larger view of the
bibliographic universe. Authorities have some of this today.

On 12/22/17 10:03 AM, Stephen Hearn wrote:
> I'm glad to see authority records being brought up. Authority records,
> not bib records, have been the primary locus for dealing with language
> (and other) variants of terms, not bib resource descriptions and statements.
> 
> At the same time, authorities have been crafted to serve different
> language communities. An LCNAF authority can include variant forms in
> many languages and scripts, yet still be regarded as a useful set of
> variants for a primarily English-speaking community. In a context of
> multiple, community-oriented authority files, the language (or
> languages) of each term is less important than the language-orientation
> of the authority file.
> 
> That said, when we move beyond the use of authorized terms (as I think
> we will), there will be a need for coding to identify the
> language/script etc. of names and other terms in cluster vocabularies;
> but won't there also be a need to identify preferred terms for display
> in specified contexts, like a catalog with a primary user population? 
> 
> Cataloging has long embraced the use of vernacular terms in its
> descriptions. Maybe the desire to encode every term with language/script
> etc. specifications is an underestimation of the ability of most
> metadata users to understand a multilingual message.
> 
> Stephen
> 
> On Fri, Dec 22, 2017 at 9:14 AM, Osma Suominen
> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
> 
>     Hi Karen!
> 
>     According to Wikipedia [1] Orwell's book is "Nineteen Eighty-Four,
>     often published as 1984". The article has a picture of the cover of
>     the first edition which uses the spelled out name. So apparently
>     both versions of the title are used in English language editions,
>     but the long version was used in the first edition.
> 
>     You're right that having catalogers choose the language for every
>     field is probably asking too much. However, in most cases it should
>     be possible to infer the language from other information in the
>     record, so having catalogers explicitly tag the language may not be
>     necessary as long as the cataloging system is smart enough - for
>     example defaulting the language of most fields to the language of
>     the work. Problems arise e.g. in situations when there are multiple
>     titles in different languages. Then it would be good to have an
>     explicit language tagging mechanism.
> 
>     I wonder if LOC has considered language tagging in their BIBFRAME
>     pilots?
> 
>     Also, authority records currently are very problematic. In our
>     corporate name authority we currently have the following alternative
>     names for the City of Helsinki ("Helsingin kaupunki" in Finnish):
> 
>     City of Helsinki
>     Elsínkia
>     He'lssen
>     Heilsincí
>     Helsig
>     Helsingfors
>     Helsingfors stad
>     Helsingi
>     Helsingia
>     Helsingjafoss
>     Helsingki
>     Helsink
>     Helsinki
>     Helsinkis
>     Helsinko
>     Helsinky
>     Helsinqui
>     Helsset
>     Helsínquia
>     Hen-xin-ki
>     Hèlsinki
>     Stadt Helsinki
>     Ville d'Helsinki
>     Ȟel'sinki
>     Хельсинки
> 
>     These are all just names in the 410a field, with no information
>     about the language of each. It's quite awkward to deal with this
>     outside the MARC records, since we don't know which names to display
>     in which situations. For example the English language name should
>     probably be preferred when displaying the information within an
>     English language UI. To my knowledge, there is no way of indicating
>     the language of a name in 4xx fields of authority records. It would
>     be very useful to be able to tag them with languages, though it
>     would take a lot of work to go through all the existing records and
>     add the language information.
> 
>     -Osma
> 
>     [1] https://en.wikipedia.org/wiki/Nineteen_Eighty-Four
>     <https://en.wikipedia.org/wiki/Nineteen_Eighty-Four>
> 
> 
>     Karen Coyle kirjoitti 22.12.2017 klo 16:42:
> 
>         Osma, I took all of those examples of 1984 from LoC's catalog. While
>         Wikidata may think they have different titles, we don't know how
>         that
>         decision was made (there are no cataloging rules for Wikidata).
>         In no
>         case have I seen "Nineteen Eighty-Four" for the English version
>         (although it was filed that way in card catalogs as per the ALA
>         Filing
>         Rules). Your examples all conveniently prove your point, but I still
>         think that asking catalogers to determine the language of every
>         field is
>         going to create difficulties. It would be a good idea to take a
>         sampling
>         of records and try this out. From the cataloger's point of view.
> 
>         kc
> 
>         On 12/21/17 7:44 AM, Osma Suominen wrote:
> 
>                 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)
> 
> 
>             I don't think that's a problem at all. In fact this is a
>             great example,
>             since the name of Orwell's novel (assuming you meant it)
>             actually
>             differs between many languages. According to Wikidata
>             (http://www.wikidata.org/entity/Q208460
>             <http://www.wikidata.org/entity/Q208460>) it is called
> 
>             "1984" in German
>             "1984" in Hebrew (but rendered with right-to-left alignment!)
>             "Nineteen Eighty-Four" in English (not 1984!)
>             "Vuonna 1984" in Finnish
>             "নাইন্টিন এইটি-ফোর" in Bengali
> 
> 
> 
> 
>     -- 
>     Osma Suominen
>     D.Sc. (Tech), In
>     <https://maps.google.com/?q=(Tech),+In&entry=gmail&source=g>formation Systems
>     Specialist
>     National Library of Finland
>     P.O. Box 26 (Kaikukatu 4)
>     00014 HELSINGIN YLIOPISTO
>     Tel. +358 50 3199529 <tel:%2B358%2050%203199529>
>     [log in to unmask] <mailto:[log in to unmask]>
>     http://www.nationallibrary.fi
> 
> 
> 
> 
> -- 
> Stephen Hearn, Metadata Strategist
> Data Management & Access, University Libraries
> University of Minnesota
> 170A Wilson Library (office)
> 160 Wilson Library (mail)
> 309 19th Avenue South
> Minneapolis, MN 55455
> Ph: 612-625-2328
> Fx: 612-625-3428
> ORCID:  0000-0002-3590-1242

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager