[OPEN-ILS-DEV] MARC 008 madness

[Thomas Berezansky]

Manual editing is a problem. But automatic editing via the fixed  
fields editor could be improved a bit, I think.

Currently in master (at least) it won't update the fixed fields unless  
you enter the full length of the field. That could be changed to force  
a space-padding, so if you enter 1 character into a 4 character field  
it adds 3 spaces transparently in the background to fill out the 4  
characters. Probably with a "trim trailing (but not leading) spaces  
when populating the editor" catch needed too.

Thomas Berezansky
Merrimack Valley Library Consortium


Quoting "Duimovich, George" <George.Duimovich at NRCan-RNCan.gc.ca>:

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