Print

Print


I was referring to the dates of publication, not the dates related to
the subjects. Sorry, I was so focused on dates of publication that I
didn't even notice the others.

The subject dates are part of an artificial language called "Library of
Congress Subject Headings" and therefore are nicely regular. Actually, I
would think that we'd want the subject language to have its own encoding
rather than defining that in MODS, since MODS should be able to handle
any subject heading scheme.

kc

On Fri, 2003-08-01 at 10:31, Bruce D'Arcus wrote:
> On Wednesday, July 30, 2003, at 10:44  AM, Karen Coyle wrote:
>
> > Bruce, I'm not against adding a qualifier. But I think we have to be
> > realistic about how MODS will be used and figure out how stringent we
> > want to be with coding rules. If you have a citation that looks like:
> >
> > Kleist, Peter. G.P.U. Justice . Edited by Maurice Edelman. London,
> > 1938.
> >
> > (This is a real citation, btw)... how would you want the date to be
> > coded? Do you want to assume that this is a firm date? Think of writing
> > the algorithm that would transfer a variety of citations into MODS
> > format.
>
> I personally think this should (at least for my needs) just be:
>
> <dateIssued>1938<dateIssued>
>
> > So I am arguing for the ability to encode both highly structured
> > bibliographic data AND the less structured in MODS.
>
> I think we all agree.
>
> > And to me that means that you need to know how to interpret both.
>
> For my realm I see no problem, or at least adding what I am proposing
> certainly doesn't make things worse.  Also, note that I am coming at
> this from the other direction: how can MODS records minimize
> interpretation difficulties, for humans and machines (xslt processors)?
>   To be honest, I don't really even know what the following means:
>
> <dateIssued>c.1938</dateIssued>
>
> This is unambiguous though:
>
> <dateIssued type="copyright">1938</dateIssued>
>
> > My preference is that you assume nothing that isn't explicit.In this
> > case, you would have a date that cannot get any of the codes for
> > dates, and the metadata format must allow for that.
>
> I'm not following you here; specifically the "get any of the codes for
> dates" part.
>
> > If instead you received this as a highly coded MARC
> > record:
> >
> >  Record number:         1
> >      FMT                  BK
> >      LDR                  00907Qam 2200229Sa 4504
> >      005                  19990827000000.0
> >      008                  711129s1938 000 0 engx
> >      040                  |a DLC |c DLC |d CU-SC
> >      1001                 |a Edelman, Maurice, |d 1911-
> >      24510                |a G. P. U. justice, |c by Maurice Edelman.
> >      260                  |a London, |b G. Allen & Unwin, ltd. |c
> > [1938]
> >      300                  |a 2 p. l., 7-231 p. |c 19cm.
> >      500                  |a "The narrative which follows [was] written
> > from the notes of Peter Kleist, a German engineer accused of espionage
> > and held in prison by the G. P. U. for examination."-Pref.
> >      600                  |a Stalin, Joseph, |d 1879-1953.
> >      600                  |a Trotsky, Leon, |d 1879-1940.
> >      610                  |a Soviet Union. |b Obedinennoe
> > gosudarstvennoe politicheskoe upravlenie.
> >      650 0                |a Prisons |z Russia.
> >      651 0                |a Soviet Union |x Politics and government.
> >      70010                |a Kleist, Peter.
> >      090                  |a DK267.E46
> >
> > your MODS record would be much richer as a result. (And the coding of
> > the date type would probably depend on your knowledge of the source as
> > much as the coding in the record.) But think about adding either or
> > both
> > of these to your bibliography and how you would handle the data
> > elements.
>
> Are you asking how I would propose dealing with *all* these dates, or
> just the one in field 260?
>
> If the former, just for illustration purposes, one option is:
>
> 1)  allow dates in other elements (such as names and subject) and allow
> "birth," "death," and "copyright" types there.
>
> 2)  add another attribute to date and names elements called, for lack
> of a better term, "qualifier."  Possible values might be: unknown,
> inferred (using Tod's suggestion from May), uncoded, and ???.
>
>
> This could allow (though certainly not require):
>
> <name type="personal">
>         <namePart type="given">John</namePart>
>         <namePart type="family">Smith</namePart>
>         <date type="birth">1618</date>
>         <date type="death">1652</date>
>         <description>poet</description>
> </name>
>
> and for cerca dates:
>
> <date qualifier="inferred">1645</date>
>
> for assumed authors:
>
> <name type="personal" qualifier="inferred">
>         <namePart type="given">John</namePart>
>         <namePart type="family">Smith</namePart>
>         <date type="birth">1618</date>
>         <date type="death">1652</date>
>         <description>poet</description>
> </name>
>
> for unattributed authors (pretty much any article in the Economist):
>
> <name qualifier="uncoded"/>
>
> (or maybe using the type attribute is better?)
>
> Topics:
>
> <topic>
>     <name type="personal">
>         <namePart type="given">Stalin</namePart>
>         <namePart type="family">Joseph</namePart>
>         <date type="birth">1879</date>
>         <date type="death">1953</date>
>     </name>
> etc...
> </topic>
>
> What do you think?
>
> Bruce