Re: Indexing ISBNs

[Wee Joo Gim <clbweejg@xxxxxxxxxx>]

Sorry if I have caused any confusion.   In our case, at the time of
implementing the III, we were not ready for the downloading of availble
MARC records from external sources and hence could not test how it worked
before the actual implementation, and hence did not realise the
non-matching issue of ISBNs with and without the suffix.  And by the time
we streamlined our workflow and were ready to download USMARC records (I
recall it was from Bibliofile), we had the hitch in that duplicate records
were created and we had a hard time in datacleaning the unnecessary
duplicates created after the downloading was over.  We were trying to use
the ISBNs as the match point for duplicate checking when we wanted to
overlay our brief order bibliographic records by LCMARC records and hence
approached III to help to see if we could have the feature of having the
matching strictly based on the 10 numbers of the ISBNs and I remember that
I was told by my fellow colleagues who liaised with III tht it was at cost
to have the re-indexing done in order to achieve what we wanted. As we
were faced with financial constraints, we could not pursue the matter at
all and left it as that and then revised our workflow and re-considered
and chose other alternatives for match point in overlaying of records.

As for the ISSN, I guess it was not much of a problem because in ISSN,
there was no suffix like (pap) or (hardcover) that complicated the matter.
But nowadays, I noticed that there are ISSN (electronic) and ISSN for the
printed serials title, so I am not sure if there is any problem in the
matching and overlaying of records or not irrespective to whether the
suffix is present or not and  hence am unable to throw more light on this.

Judy: May I ask what is this IISNs?  Is that the same as ISSN
(electronic) for the e-journals or something else?

To me, the best thing to do  is to seek clarification directly from III
regarding how the downloadindg of records from external sources work
w.r.t. their  indexing system and do the actual testing with concrete
examples because we all have different workflows and datacapture records
from different sources.  

These are also my PERSONAL viewpoints based on my personal recollection of
the  datacleaning problems  that my fellow colleagues doing acquisitions
and catalouging had faced when we were implementing the acquisitions and
cataloguing modules years back.  Things may have changed and improved
by III by now in their new enhanced Millennium Products by taking note of
the constant feedbacks and enhancement requests from IUGs and other
customer libraries far and near. 



Joo-Gim Wee

On Tue, 5 Sep 2000, Elizabeth Thomsen wrote:

> Now I'm confused.  Do you mean that it's possible to only index the
> first ten characters of the 020 field, and the only problem is having
> the indexing profile changed and reindexing the database?  Or was
> Joo-Gim Wee saying that Innovative considered this change in indexing
> custom programming...
>
> 
> -- 
> Elizabeth Thomsen, Member Services Manager
> NOBLE: North of Boston Library Exchange
> Danvers MA 01923
> et@xxxxxxxxxx
> 
> 
> Judith A Schneider wrote:
> > 
> > I think the reason this can be done at cost is that your ISBN/ISSN index is
> > already built. You'd have to ask III to re-build the index, and they generally
> > charge for that.
> > 
> > Also ... what about IISNs? They're 8 characters. Would they be in the same
> > index? If you're using ISBN, do you also use ISSN to match?
> > 
> > Judy Schneider                 "So Many Books ...
> > US GAO Library                     So Little Time"
> > schneiderj.isc@xxxxxxxxxx
> > 
> > My opinions are mine! All Mine!
> > 
> > ____________________Reply Separator____________________
> > Subject:    Re: Indexing ISBNs
> > Author: <innopac@xxxxxxxxxx>
> > Date:       09/02/2000 9:35 AM
> > 
> > We have  asked for this years back since  we started to implement the
> > Innopac system but was given the answer that that could be done at cost.
> > We were trying to press for free enhancement but got informal feedback
> > that most libraries in the States did not rely on the ISBNs as the match
> > point in the downloading of MARC records from external sources as they use
> > the OCLC's record number since they do copy cataloguing from OCLC's source
> > as members of OCLC.  There were some viewpoints expressed that ISBN is
> > not a "reliable" match point since some titles carry wrong ISBNs - this to
> > me is the fault of the publishers that led to the confusion and hence the
> > eventual mismatch, and publishers should be informed to rectify it.
> > 
> > Personally I also support that the indexing of the 10 numbers of the
> > ISBNs is a good  enhancement to provide additional match point to help
> > libraries to download MARC records from external sources (e.g. some
> > vendors that offer books with MARC records).  Most vendors that offer
> > books with MARC  actually  use the ISBNs for the matching of their
> > customers' brief order records against their records in the supply of MARC
> > records to their customers.
> > 
> > Joo-Gim Wee (Ms)
> > Deputy Librarian (Technical Services)
> > National University of Singapore
> > 
> > On Fri, 1 Sep 2000, Diane Goodman wrote:
> > 
> > > I would also support indexing only the 10-number ISBN part of the 020 field.
> > Would this help with the following problem?
> > >
> > > Since we get bib. records from various sources, we set ISBN as a match point.
> > When you have "0671234567" in a brief "order" bib. and the incoming full bib.
> > has "0671234567 (pbk)," it is NOT considered a match, and the record will not
> > overlay.
> > >
> > > Diane L. Goodman
> > > Technical Service Manager
> > > Sarasota County Library System
> > > Sarasota, Florida
> > > dgoodman@xxxxxxxxxx
> > >
> > >
> > > --
> > > This message was distributed through the Innovative Users Group INNOPAC list.
> > > Private replies:  "Diane Goodman" <dgoodman@xxxxxxxxxx>
> > > Public replies:   INNOPAC@xxxxxxxxxx
> > > Archives:  http://innopacusers.org/list/archives/
> > >
> > 
> > --
> > This message was distributed through the Innovative Users Group INNOPAC list.
> > Private replies:  Wee Joo Gim <clbweejg@xxxxxxxxxx>
> > Public replies:   INNOPAC@xxxxxxxxxx
> > Archives:  http://innopacusers.org/list/archives/
> > 
> > --
> > This message was distributed through the Innovative Users Group INNOPAC list.
> > Private replies:  "Judith A Schneider"<schneiderj.isc@xxxxxxxxxx>
> > Public replies:   INNOPAC@xxxxxxxxxx
> > Archives:  http://innopacusers.org/list/archives/
> --
> This message was distributed through the Innovative Users Group INNOPAC list.
> Private replies:  Elizabeth Thomsen <et@xxxxxxxxxx>
> Public replies:   INNOPAC@xxxxxxxxxx
> Archives:  http://innopacusers.org/list/archives/
> 

--
This message was distributed through the Innovative Users Group INNOPAC list.
Private replies:  Wee Joo Gim <clbweejg@xxxxxxxxxx>
Public replies:   INNOPAC@xxxxxxxxxx
Archives:  http://innopacusers.org/list/archives/