Re: [CODE4LIB] date fields

[Jonathan Rochkind]

> but since there is really no standard field for such a value, anything I
choose is all but arbitrary. I’ll use some 9xx field, just to make things
easy. I can always (and easily) change it later.

More like there are SEVERAL standard fields for such a value.

You can certainly put it in one of the existing standard fields, you just
have to actually follow the (often byzantine legacy) rules for such entry.
For instance, the date you want may very well already be in the fixed field
008, and you could certainly add it if it weren't. But the rules and
practices for 008 are confusing -- in part, because the actual real world
universe of "what is the date of this thing" is itself complex in the real
world of actually cataloged things, including serials and series,
manuscripts, reprints and fascimiles, old things where we aren't sure of
the exact dates, etc.  And in part just because the MARC standard is kind
of old and creaky, especially with regard to fixed fields like 008 being
designed to cram maximum amount of information in minimum bytes, beyond any
reasonable economy actually needed today.

I just learned about the 264 from Karen Miller's post (thanks Karen), I
dunno about that one, but it looks like it might be applicable too.

Standards, why have just one when you can have a dozen?

On Tue, Jul 12, 2016 at 10:12 AM, Eric Lease Morgan  wrote:

> On Jul 11, 2016, at 4:32 PM, Kyle Banerjee 
> wrote:
>
> >>
> https://github.com/traject/traject/blob/e98fe35f504a2a519412cd28fdd97dc514b603c6/lib/traject/macros/marc21_semantics.rb#L299-L379
> >
> > 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.
>
>
> Thank you, one & all, for the input & feedback. After thinking about it
> for a while, I believe I will save my normalized dates in a local (9xx)
> field of some sort.
>
> My use case? As a part of the "Catholic Portal", I aggregate many
> different types of metadata and essentially create a union catalog of rare
> and infrequently held materials of a Catholic nature. [1] In an effort to
> measure “rarity” I've counted and tabulated the frequency of a given title
> in WorldCat. I now want to measure the age of the materials in the
> collection. To do that I need to normalize dates and evaluate them. Ideally
> I would save the normalized dates back in MARC and give the MARC back to
> Portal members libraries, but since there is really no standard field for
> such a value, anything I choose is all but arbitrary. I’ll use some 9xx
> field, just to make things easy. I can always (and easily) change it later.
>
> [1] "Catholic Portal” - http://www.catholicresearch.net
>
> —
> Eric Lease Morgan
>

Re: [CODE4LIB] date fields

[Eric Lease Morgan]

On Jul 11, 2016, at 4:32 PM, Kyle Banerjee  wrote:

>> https://github.com/traject/traject/blob/e98fe35f504a2a519412cd28fdd97dc514b603c6/lib/traject/macros/marc21_semantics.rb#L299-L379
> 
> 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.


Thank you, one & all, for the input & feedback. After thinking about it for a 
while, I believe I will save my normalized dates in a local (9xx) field of some 
sort.

My use case? As a part of the "Catholic Portal", I aggregate many different 
types of metadata and essentially create a union catalog of rare and 
infrequently held materials of a Catholic nature. [1] In an effort to measure 
“rarity” I've counted and tabulated the frequency of a given title in WorldCat. 
I now want to measure the age of the materials in the collection. To do that I 
need to normalize dates and evaluate them. Ideally I would save the normalized 
dates back in MARC and give the MARC back to Portal members libraries, but 
since there is really no standard field for such a value, anything I choose is 
all but arbitrary. I’ll use some 9xx field, just to make things easy. I can 
always (and easily) change it later.

[1] "Catholic Portal” - http://www.catholicresearch.net

—
Eric Lease Morgan

Re: [CODE4LIB] date fields

[Karen Miller]

And don't forgot to check the MARC 264$c as well. That's the field that we use 
with RDA and you'll find it in newer records.

Karen

Karen D. Miller
Monographic Cataloger/Metadata Specialist
Northwestern University Libraries
Northwestern University
1970 Campus Drive
Evanston, IL 60208
www.library.northwestern.edu
k-mill...@northwestern.edu
874.467.3462


-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Trail, 
Nate
Sent: Monday, July 11, 2016 2:24 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] date fields

Don't forget that it might be duplicative of the 260 but the 008 has "machine 
readable" date info that may be less specific than the 260 but more uniformly 
entered (or that's the only place there is a date associated with 
publication/release).
Nate

==
Nate Trail
LS/ABA/NDMSO
Library of Congress
n...@loc.gov



-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Joy 
Nelson
Sent: Monday, July 11, 2016 3:19 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] date fields

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 <emor...@nd.edu> 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 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__bywatersolutions.com=CwIDaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=P54V6LrXJP5Ddzc8ZItBdqB1Kr3elvFIQ04P7n0UCbQ=7EQN_apayMI2O9udJ8Gn13kbTRlzE3oKz9kl-QycF_4=gUcx8tWq301tcZq4tIjJChWJ86ObInENcFh-D7ljgx4=
 > Support and Consulting for Open Source Software
Office: Fort Worth, TX
Phone/Fax (888)900-8944
What is Koha? 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__bywatersolutions.com_what-2Dis-2Dkoha_=CwIDaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=P54V6LrXJP5Ddzc8ZItBdqB1Kr3elvFIQ04P7n0UCbQ=7EQN_apayMI2O9udJ8Gn13kbTRlzE3oKz9kl-QycF_4=UyhUbm0XaO342AgjKgfi20M3VKgVg1yUboM2ldc04sw=
 >

Re: [CODE4LIB] date fields

[Kyle Banerjee]

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 
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 
> 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 
> > 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 
> > Support and Consulting for Open Source Software
> > Office: Fort Worth, TX
> > Phone/Fax (888)900-8944
> > What is Koha? 
> >
>

Re: [CODE4LIB] date fields

[Jonathan Rochkind]

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 
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 
> 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 
> Support and Consulting for Open Source Software
> Office: Fort Worth, TX
> Phone/Fax (888)900-8944
> What is Koha? 
>

Re: [CODE4LIB] date fields

[Trail, Nate]

Don't forget that it might be duplicative of the 260 but the 008 has "machine 
readable" date info that may be less specific than the 260 but more uniformly 
entered (or that's the only place there is a date associated with 
publication/release).
Nate

==
Nate Trail
LS/ABA/NDMSO
Library of Congress
n...@loc.gov



-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Joy 
Nelson
Sent: Monday, July 11, 2016 3:19 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] date fields

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 <emor...@nd.edu> 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/>

Re: [CODE4LIB] date fields

[Knight, Kathryn E.]

Hey there, 

If you're using MARC, you could try the 046 field. It's for special dates. 

-Katie

-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Joy 
Nelson
Sent: Monday, July 11, 2016 3:19 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] date fields

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 <emor...@nd.edu> 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/>

Re: [CODE4LIB] date fields

[Joy Nelson]

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  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 
Support and Consulting for Open Source Software
Office: Fort Worth, TX
Phone/Fax (888)900-8944
What is Koha? 

[CODE4LIB] date fields

[Eric Lease Morgan]

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