Is the idea that this new field would be stored as MARC in the system (the
ILS?).

If so, the 9xx solution already suggested is probably the way to go if the
008 route suggested earlier won't work for you. Otherwise, you run a risk
that some form of record maintenance will blow out all your changes.

The actual use case you have in mind makes a big difference in what paths
make sense, so more detail might be helpful.

kyle



On Mon, Jul 11, 2016 at 1:06 PM, Jonathan Rochkind <[log in to unmask]>
wrote:

> 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.
>
> https://github.com/traject/traject/blob/e98fe35f504a2a519412cd28fdd97dc514b603c6/lib/traject/macros/marc21_semantics.rb#L299-L379
>
> 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
> https://xkcd.com/927/).
>
> 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]>
> wrote:
>
> > 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
> > it.
> >
> > 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
> >
> > -Joy
> >
> > On Mon, Jul 11, 2016 at 12:51 PM, Eric Lease Morgan <[log in to unmask]>
> > wrote:
> >
> > > I’m looking for date fields.
> > >
> > > Or more specifically, I have been given a pile o’ MARC records, and I
> > will
> > > 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
> > > ([1900], c1900, 190?, 19—, 1900, etc.) — I plan to normalize things to
> > > integers like 1900. I then want to save/store these normalized values
> > back
> > > 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/>
> >
>