[290] in ad-lib
Re: MIT OCLC TABLE SPEC
daemon@ATHENA.MIT.EDU (Sarah Mitchell)
Wed Apr 5 13:53:08 1995
To: m.ridgeway%34@gem.geac.com
Cc: ad-cat@MIT.EDU
In-Reply-To: Your message of "Wed, 05 Apr 1995 10:24:00 EDT."
<950405102824.AA01875@gem.geac.com>
Date: Wed, 05 Apr 1995 13:52:40 EDT
From: Sarah Mitchell <smitchel@MIT.EDU>
Since we do want to cover the 866 field and the 852 creation with this
Enhancement Table, it looks like we will have to devise a
distinguishing code for the periodicals if the indicators aren't
desirable.
Glad to hear, however, that you can decode any length data in subfield
a. Would you have any problems with our using codes that included a
dash, e.g., b-av-ref ? We also want to work with lower case
characters so we can avoid using the shift key.
--
>
>In terms of locating the code and the bracketed information, the
>spec was written to the way it is now, i.e., read 1st 4 characters,
>go to 6th character or [. If 852 creation is the only use, why not
>devise unique codes that are not limited to 4 characters? The program
>can decode any length data in a subfield a. I would prefer not to
>use indicators.
>
>Regarding what GeoCat can or can't do - well, this is joint development,
>isn't it. I think some comments on what it should do would be
>appreciated. Does the UBIX functionality need enhancement? When files/
>records are added, what steps should be taking place? As far as I know,
>the UBIX functionality will be carried out - this is the way our i/f
>currently work...
>
>
>--
>Michel Ridgeway, Project Manager, Libraries m.ridgeway@geac.com
>923 West King Road, Malvern, PA 19355
>voice (610) 644-4071 fax (610) 644-0907
