This assumes that the "place of publication" element fulfills these purposes. It only does so if ALL places of publication are recorded (which can run to dozens for publishers like Oxford University Press that like to have lots of places of publication) in an unambiguous manner. Since the place of publication is a transcribed element, I'm doubtful on these points (especially purposes dependent on reliable machine manipulation). For example, how many people know that "Harmondsworth, Middx" (long the place of publication for Penguin Books) refers to a place in the London borough of Hillington? Taylor & Francis, on the other hand, is located in Abingdon, Oxfordshire, but you would never know it from their title pages.
At any rate, I didn't come here for an argument, just to register my amusement--at my age, this is probably healthier--that the code-makers consistently try to make this element optional and are just as consistently thwarted. If evidence were needed that there was a vocal cataloging constituency for retaining place of publication, that would suffice. My suspicion remains, however, that this support is more a matter of inertia: "We've always done it this way, and we must have had our reasons". The arguments put forward now seem more ex post facto and fatally assume this element is formally controlled in some way when it's merely transcribed.
________________________________________
From: Next generation catalogs for libraries [NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Weinheimer Jim [j.weinheimer_at_AUR.EDU]
Sent: Sunday, January 02, 2011 3:07 AM
To: NGC4LIB_at_LISTSERV.ND.EDU
Subject: Re: [NGC4LIB] ONIX data
But if ONIX data comes from publishers, they should know better than anyone else in the world where they are located. All they have to do is look out the window or if that doesn't work, ask the person in the next desk what town they are in!
This is an example of a possible area of *cooperation,* i.e. when *everybody* involved can change. Instead of just giving up and saying it can't be done or it's not worth the effort, we need to look at the entire system and see which communities can provide specific information the most easily. Getting publishers to add a place of publication should be the easiest thing they can do--certainly much easier than expecting them to buy into this obscure system of FRBR/RDA works/expressions/manifestation/items.
Do we need place of publication? That is a matter of debate, but in my opinion, if we want systems to somehow automatically know what copyright laws are in effect for a resource, place of publication becomes vital because the laws are different all over the place. For example, it is such a pain for me in Italy to not see many items in full text from Google Books that I should. I would love having better and more reliable information in these areas. While I hope that the copyright laws unify someday, I am not holding my breath.
James L. Weinheimer j.weinheimer_at_aur.edu
Director of Library and Information Services
The American University of Rome
Rome, Italy
First Thus: http://catalogingmatters.blogspot.com/
________________________________________
From: Next generation catalogs for libraries [NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Ed Jones [ejones_at_NU.EDU]
Sent: Sunday, January 02, 2011 2:50 AM
To: NGC4LIB_at_LISTSERV.ND.EDU
Subject: Re: [NGC4LIB] ONIX data
For modern publications, I have never seen a convincing argument for spending time and effort on the place of publication except for obscure publishers (where the full address might be even more helpful). AACR2 tried to make this element optional back in 1978, but by the time the code was implemented in 1981 most libraries (including LC) had decided they would treat it as mandatory. RDA tried to make it optional again but this effort has been successfully beaten back.
________________________________________
From: Next generation catalogs for libraries [NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Karen Coyle [lists_at_kcoyle.net]
Sent: Saturday, January 01, 2011 9:39 AM
To: NGC4LIB_at_LISTSERV.ND.EDU
Subject: Re: [NGC4LIB] ONIX data
Quoting Charles Ledvina <cledvina_at_MAIL.OWLS.LIB.WI.US>:
>> Comments on LC record:
>> 010: retrieved from the electronic CIP application
>> 020: qualifier given here rather than in 500.
>
> I will see if I can remap this data to the 020.
While this would be correct, resulting in something like:
020 $a 3846750293 (paperback)
it is a TERRIBLE practice because it mixes up the ISBN, which we need
for all kinds of linking, and text, which always has to be removed
before we can make use of the ISBN. The textual part REALLY needs to
be in a separate subfield. This is a place where it might be valuable
to vary from usual library practice.
>
>> 260: cataloger supplied place to ONIX converter application, also for
> 008.
>
> Amazon does not supply this information. I suppose I could add a lookup
> function that will provide a place based on matching a publisher's name.
> Does anybody on this list know of a comprehensive publisher database?
I don't know of one, and in some cases the publisher publishes from
more than one place -- so a book by the same publisher may come out as
London or New York or both. However, you can "guess" the publisher
using the ISBN prefix. There is a partial list at this wikipedia page:
http://en.wikipedia.org/wiki/Isbn#Publisher_code
It'll probably work for the proverbial 80-90% of mainstream publishing.
>
>> 300: LC decided not to add pagination at this time.
>
> This is a good idea. My experience is that the pagination is usually
> wrong, however, the number of discs for sound recordings or videodiscs is
> usually correct. I added a button on top of the full record screen which
> will replace the 300 field data with "p. cm."
My impression is that the publishers provide the literal "number of
pages" while libraries code "pagination" - so it's the difference
between:
x, 350
and
360
Again, it would be great to have a "number of pages" option in MARC,
which would be better than not recording anything. It does give the
user some idea of the size of the book, and the difference between
pagination and pages for the users is probably not significant.
>
>> 490: cataloger found series number in electronic manuscript and added
> it.
>
> Amazon's series sometimes contains the number. In fact Amazon does not
> have a series field in the ONIX record, the converter simply takes
> whatever
> it finds between the parentheses in the title field.
I've run into all kinds of odd "problems" or differences of opinion
about series, and it turns out to be a very complex concept with many
different interpretations. Many readers consider "Harry Potter" or
"the Kinsey Millhone mysteries" to be a series, and ones they would
like to find made visible in catalogs since they want to read them
all, and in order. Libraries have a different interpretation of
series. But, yes, Amazon puts its interpretation of series in the
title field. *sigh*
> This is the very reason why I use Amazon for my source. Publishers from
> around the world send to them their data and Amazon compiles it and dishes
> it
> out for free!
>
This is pretty much the same reason why the Open Library uses Amazon
data. It's up to date (include forthcoming books), it gathers from a
lot of different sources (some of which aren't so hot, by the way --
the third-party sellers turn out some really ugly data and it might be
best to skip those), and it is free. That's hard to beat.
kc
--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Received on Sun Jan 02 2011 - 15:17:19 EST