[OPEN-ILS-DEV] MARC 008 madness

[Duimovich, George]

Following up on some discussion on IRC yesterday (dbs/drycona), we looked at how many records we had with bad 008 data. So we identified lots of bad data  from mostly one previous ILS, but we also had lots of errors across all of our tcn_sources.  We'll explore what automated fix-ups are possible. 

Has anybody given any thought as to how we might tame some of the madness of MARC 008's "space as data" (aka "character position") and related data integrity challenges?  

What I'm curious about is for any practical approaches that could be taken within the MARC Editor to minimize coding errors for 008 and/or highlight / provide validation for these errors when using the MARC editor. 

For example:

* When viewing an empty fixed field element (say "Date1"), there's no immediately visual way that I can see that there's already 4 positions reserved as 'empty data' or if that's 3 spaces or none. Would it be helpful to have better identification of "space as data" in fixed field section? If so, how without cluttering up things. E.g. should empty spaces be styled in a different background colour, or is there a way of highlighting empty character positions as well as errors through some other visual techniques? 

* Right now, 008 is twice editable (in the fixed field editor box, but also in the 008 line item). It's hard to know how many errors are introduced through awkwardness of direct edits to the 008 row but wonder if protecting 008 row would help us any (some ILS systems basically hide 008 in favour of 'guided' or input box data entry, etc.).

* or maybe just adding some simplified 008 validation (say against char_length) so that upon saving a record you're given an error message ("Invalid 008 entry" or whatever) with an option to ignore errors, save and continue?

Thanks,

George Duimovich
NRCan Library / Bibliothèque de RNCan



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20111110/b66342f1/attachment-0001.htm>