There's some super useful data in the MARC fixed fields too -- more useful
than the semi-transcribed values in 260c, although it's also a pain to
access/transform to something reasonably machine actionable.
Here's the code from traject that tries to get a reasonable date out of
marc fixed fields, falling back to 260c if it needs to.
There are already quite a few places in MARC for dates. It's just they're
all weird. You're making up yet a new kind of date to your own local
meaning and specs. I doubt there's an existing MARC field you can put it in
where it won't just add to the confusion. (obligatory reference to
I'd just put it in a 9xx or xx9 field of your choosing, they are reserved
for local use.
On Mon, Jul 11, 2016 at 3:19 PM, Joy Nelson <[log in to unmask]>
> Hi Eric-
> Are you planning on storing the 'normalized' dates for ever in the MARC?
> i.e. leave the c1900 in the 260$c and have 1900 in another place?
> I think what you do depends on your ILS and tools. My first reaction would
> be to stash the date in an unused subfield in the 260. If your system
> allows you to add 'non standard' subfields, you could use 260$z to stash
> But, then I start to think that might rankle some catalogers to have 'non
> standard' date data in the 260 (or 264). I would probably then look at
> using one of the local use tags. 901-907, 910, or 945-949. You could be
> the date in $a and even a brief description in a second subfield.
> 901$a1900$bnormalized date for project XYZ -initials/date
> On Mon, Jul 11, 2016 at 12:51 PM, Eric Lease Morgan <[log in to unmask]>
> > I’m looking for date fields.
> > Or more specifically, I have been given a pile o’ MARC records, and I
> > be extracting for analysis the values of dates from MARC 260$c. From the
> > resulting set of values — which will include all sorts of string values
> > (, c1900, 190?, 19—, 1900, etc.) — I plan to normalize things to
> > integers like 1900. I then want to save/store these normalized values
> > to my local set of MARC records. I will then re-read the data to create
> > things like timelines, to answer questions like “How old is old?”, or to
> > “simply” look for trends in the data.
> > What field would y’all suggest I use to store my normalized date content?
> > —
> > Eric Morgan
> Joy Nelson
> Director of Migrations
> ByWater Solutions <http://bywatersolutions.com>
> Support and Consulting for Open Source Software
> Office: Fort Worth, TX
> Phone/Fax (888)900-8944
> What is Koha? <http://bywatersolutions.com/what-is-koha/>