[OPEN-ILS-DEV] EG 2.0 alpha4 problem with MARC defaults in Add MFHD Record

[Dan Scott]

On Thu, Nov 11, 2010 at 10:35:26AM -0500, Mike Rylander wrote:
> On Wed, Nov 10, 2010 at 10:42 PM, Dan Scott <dan at coffeecode.net> wrote:
> > On Wed, Nov 03, 2010 at 11:03:37PM -0400, Mike Rylander wrote:
> >> On Wed, Nov 3, 2010 at 10:49 PM, Dan Scott <dan at coffeecode.net> wrote:
> >> > On Wed, Nov 03, 2010 at 09:29:07PM +0100, Repke de Vries wrote:
> >>
> >> [snip]
> >>
> >> >
> >> >> - the 035 should not happen: this the very first time a MFHD record
> >> >> is created; only if some other library would take IISH's Holding
> >> >> Records, the IISH 001 and 003 should be pushed to the 035
> >> >
> >> > Agreed. Just to explain what's going on under the covers is that the
> >> > MFHD record is created with an auto-generated TCN (001), then when the
> >> > record is inserted into the database the update trigger runs and the 001
> >> > gets replaced with the record ID and the old 001 gets pushed into the
> >> > 035.
> >> >
> >> > I can't guarantee that we'll be able to fix this before the 2.0 release.
> >> > It would be great, though, if you could at least create a bug for this
> >> > so that we can at least track it.
> >> >
> >>
> >> Just a thought on implementation ... since the goal is to detect when
> >> the record is brand new, as opposed to updated, perhaps we just need
> >> to test whether create_date and edit_date are the same and if so we
> >> can skip the 035 dance.
> >>
> >
> > Hmm. I got to the point of implementing this, then realized that there's
> > currently not a good way (that my sleep-deprived brain can think of, at
> > least) for the trigger to distinguish between a new record that was
> > imported via Z39.50 (where you would _want_ to push the 001/003 into the
> > 035) and a new record that was created from scratch (where you would
> > want to just overwrite the 001/003 without creating a 035).
> >
> > Any further thoughts, Mike? Given MARC templates, I don't think we can
> > really cheat with any magic values for the 003. Meh.
> >
> 
> Not magic values, but certainly the lack of values, eh?  I propose the
> following rule:
> 
>  ** If you want your from-scratch records to /not/ get an 035, do not
> put an 001/003 in the template.  On the other hand, if you /do/ want a
> "magic" 035 marker that says, "this record was built from scratch,"
> then you /should/ add some locally designed 001/003 combo to the
> template, knowing that it will be pushed into 035.
> 
> Then we just do the 035 dance if there is an 001/003 combo to move.
> Would that be acceptable?

Ah, good thought. That is indeed acceptable (at least from my perspective).

So on authority and MFHD record entry creation, which are curently
generated via hard-coded templates, I'll ensure that no 003 is created
in the default template (currently I populate the authority record with
a default value) and let the maintain_control_number trigger generate
that for us; if there is no 003, then maintain_control_number will
simply stomp on the 001 instead of trying to push something into a new
035.

I will make it so on the database side; hopefully someone on the DIG
side can make this proviso show up in the documentation (it extends to
"In general, do not add 001/003 to records that you create, either via
templates or by manually editing them; relax and trust in the database
to add them for you".)

I'm struggling a bit with the 003 contents; we generate those on
the database side based on the library that owns a given record. But as
far as I can tell, we haven't exposed a UI that enables libraries to set
the owner of a given record. So the records are all getting the
consortial 003 value (control number identifier), even though one could
reasonably expect that if you've logged into BR1 and are creating a
record that it should be owned by BR1 and get the BR1 control number
identifier.

I could modify the authority and MFHD record-entry creation pieces to
set the owner to the current work OU, but I'm a little worried about
what that might mean when it comes to permissions to edit / view these
records in a consortial context. For 2.0, I'm tempted to simply say "set
the control number identifier at the consortial level" and leave it at
that until the corresponding record ownership functionality matures.