Print

Print


Interesting what you've done with these dates. In your examples,
"inferred" doesn't mean anything to me. Is there a better more descriptive
name for that attribute? This is a limitation on the accuracy of the
date. Any ideas?

We had figured that if you have a date and there is no encoding specified
that it is assumed to be free text. That's why we didn't add anything like
"unstructured". In a number of places in MODS the lack of encoding or
authority means unstructured or uncontrolled. Is it necessary to
explicitly say that? If so, I would think that in terms of dates, it would
be encoding="unstructured", rather than type (also since we now might have
type=copyright under dateIssued).

Rebecca

On Thu, 1 May 2003, Tod Olson wrote:

> >>>>> "RG" == Rebecca S Guenther <[log in to unmask]> writes:
>
> RG> There are various ways to approach this. One problem is that in terms
> RG> of a MARC to MODS conversion where the data being converted has used
> RG> the transcription rules of AACR2, it is unfortunately not that
> RG> predictable the way the data will appear. So the simple case is
> RG> "c1999", but there are all kinds of variations in what would be in the
> RG> 260$c. If you look at the format examples there are things like "1979
> RG> printing, c1975", "April 15 1977". You could also have "ca. 1820". So
> RG> it may not be a good idea to fool with the data and try to take out the
> RG> "c", since the program would have to look at the data and will only
> RG> catch some of them.
>
> [sample options deleted]
>
> One would not blindly remove any "c" in an AACR2 date, but rather write a
> parser to cover a variety of cases.  This is something of a nightmare,
> given that the date in AACR2 is little better than free text, but the
> majority of cases can be identified and handled.  Currently, those of us
> who need to do date comparisons on exported MARC data have to write these
> parsers anyhow.  Here are a few examples of dates I had to parse for a
> recent project:
>
>     1857
>     183-
>     c1856
>     ca. 1852
>     [between 1842 and 1844]
>     [not before 1852]
>     1842?
>
> >From this perspective, it would be nice if MODS were more predictable in
> its date formats.  As Mr. Tennant points out, additional information, if
> deemed necessary, could be provided by attributes.  The conventions here
> have not been well-considered and are for purposes of illustration only:
>
>     <dateIssued encoding="iso8601">1857</dateIssued>
>     <dateIssued encoding="iso8601" inferred="within decade">1830</dateIssued>
>     <dateIssued encoding="iso8601" type="copyright">1856</dateIssued>
>     <dateIssued encoding="iso8601" inferred="circa">1852</dateIssued>
>     <dateIssued encoding="iso8601" inferred="between">1842/1844</dateIssued>
>     <dateIssued encoding="iso8601" inferred="not before">1852</dateIssued>
>     <dateIssued encoding="iso8601" inferred="probable">1842</dateIssued>
>
> In case of multiple dates in the 260$c, they will be separated by a comma
> and can be reliably separated into multiple <dateIssued> elements.  The
> above example of "1979 printing, c1975" becomes something like:
>
>     <dateIssued type="printing">1979</dateIssued>
>     <dateIssued type="copyright">1975</dateIssued>
>
> Correct AACR2 terms and punctuation could then be supplied for display by
> an XSLT stylesheet, if desired.  This goes further than the guidelines
> currently do in moving responsibility for ISBD punctuation into the
> stylesheets, but the payoff is functional date parsing.
>
> If absolutely necessary, extremely nasty, unparsable date info could
> be marked so that programs can treat it literally for display, and avoid it
> like the plague for date matching:
>
>     <dateIssued type="unstructured">1953 [1935]</dateIssued>
>
> (Though here there could, if needed, be some other way to record a
> misprinted date.)
>
> The point is that a well-defined date format is an asset of MODS,
> especially when we consider that applications will need to do date
> processing on MODS data.  Conformance to such date formats should be
> explicitly encouraged if not required.  Any need to support AACR2 date
> formatting and a MARC to MODS crosswalk should be secondary to support for
> this more basic need.
>
>
> Tod A. Olson <[log in to unmask]>     "How do you know I'm mad?" said Alice.
> Sr. Programmer / Analyst            "If you weren't mad, you wouldn't have
> The University of Chicago Library    come here," said the Cat.
>