Print

Print


Michael, see my note dated today about the variation in relator codes.

kc

On 5/29/13 10:18 AM, Mitchell, Michael wrote:
>
> This is why S.l. and S.n. should have been left alone in RDA. And 
> relator codes should be preferred. Let the machines deal with them not 
> fallible humans.
>
> Michael Mitchell
>
> Technical Services Librarian
>
> Brazosport College
>
> Lake Jackson, TX
>
> Michael.mitchell at brazosport.edu
>
> *From:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *On Behalf Of *Diane Hillmann
> *Sent:* Wednesday, May 29, 2013 12:00 PM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Consistency
>
> Roy:
>
> I found the same kinds of things when aggregating NSDL data about a 
> decade ago, though of course on a smaller scale! (Defaults with 
> various misspellings of 'unknown' were my particular trigger). I think 
> that what would help us avoid having to cope with crappy text into our 
> dotage is to build tools that help us serve up standardized text when 
> we think we still need it, while not actually creating or storing it 
> as text. We know humans will continue to make these kinds of errors if 
> we ask them to enter text during the cataloging process, but if users 
> need to see these kinds of notes, we need to build smarter tools to 
> make it happen.  Continuing to rant about the imperfect humans around 
> us doesn't help at all.
>
> Diane
>
> On Wed, May 29, 2013 at 10:49 AM, Tennant,Roy <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
> On 5/28/13 5/28/13 € 10:48 PM, "Bernhard Eversberg" 
> <[log in to unmask] <mailto:[log in to unmask]>>
> wrote:
>
> >Consistency is not hugely important for purely descriptive data...
>
> >
> >Consistency is of utmost importance for access-related data.
>
> Agreed. But we nonetheless seem to have focused too much on consistency of
> descriptive data (for example, "ill." in collation statements) and yet not
> enough in access-related data (for example, we are unable to consistently
> determine when a URL will take the user to the full item).
>
> And as the table that my colleague Ralph LeVan provided earlier
> demonstrates, our data is horribly inconsistent in the aggregate.
>
> Here is but a beginning list of the problems we face in trying to be
> consistent:
>
> 1) Rules that are inexact or difficult to understand.
> 2) An unclear understanding, or an imperfect use (whether deliberate or
> inadvertent), of those rules.
> 3) Typographical errors.
> 4) Data acceptance systems (either single record or batch) that fail to
> validate appropriate elements.
> 5) Violation of rules for local purposes (for example, putting data in a
> different element so it will display in a particular system; or adding
> HTML markup to elements for local display purposes).
> 6) etc.
>
> I'd like to assert that these problems are in our past, but I clearly
> cannot. Let's take the 264 field for example[1]. Recently created, these
> fields are now pouring into WorldCat (in Jan. we found 56,706 such fields
> and in April we found 158,019 -- nearly three times as many). Meanwhile,
> the rules seem fairly specific about what one should do if the place of
> publication is not apparent[2]: put "[Place of publication not identified]
> :" in the $a. Not any of these:
>
> [Place of publication not identified :
> [place of publication not identified] :
> Place of publication not identified :
> [Place of publication unknown] :
> [Place of publication not given] :
> Unknown place of publication :
> [place of publication not indicated] :
> [Place of publication not known] :
> Unknow place of publication :
> No place of publication :
> Place of publication unknown :
>
> All of which (and more) already occur[3], and more still as they continue
> to pour in.
>
>
>
> So I guess my point is this: we all need to own this problem and work
> against the forces of inconsistency outlined above and others that may
> occur to you. These will include a wide variety of techniques that must
> encompass the entire library metadata ecosystem -- from the individual
> cataloger to the massive aggregators like my employer.
> Roy Tennant
> OCLC Resarch
>
> P.S. And please don't get me started on that colon. One rant per day is
> quite enough.
>
> [1] http://experimental.worldcat.org/marcusage/264.html
> [2] http://www.loc.gov/marc/bibliographic/bd264.html
> [3] http://experimental.worldcat.org/marcusage/pob.txt and for additional
> amusement, see all the ways "New York" has already been entered here:
> http://experimental.worldcat.org/marcusage/ny.txt
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet