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. >