Re: [Koha-devel] Holdings and MARC Frameworks

[Joshua M. Ferraro]

----- "Henri-Damien LAURENT" <address@hidden> wrote:
> Joshua M. Ferraro a écrit :
> > ----- "Chris Cormack" <address@hidden> wrote:
> >   
> >>> How about for frameworks other than default, you can't link to 
> >>> any items fields. And for any functions that check for mappings
> to
> >>> items tables, they only pull from default framework.
> >>>
> >>> The alternative is what we have now in rel_2_2, where you can
> have
> >>> one framework for BOOKS, with items.barcode linked to 952$p, then
> >>> you can go and create another framework for PERI, with
> >>>       
> >> items.barcode
> >>     
> >>> linked to 952$b. And I'm pretty sure we haven't coded carefully
> >>> enough in rel_2_2 for those to both work all the time ... and in 
> >>> Zebra, it won't work at all because you'd have to define a new
> >>> entry in record.abs for each of those frameworks entries. Hope
> that
> >>> clarifies.
> >>>
> >>>       
> >> Hmm not really :-)
> >>
> >> So only things who use the default framework can have items?
> >>
> >> Im more wondering how it would work from the users point of view.
> IE,
> >> is 
> >> it useful to have frameworks that cant have items?
> >> Taking your example above with a framework for BOOKS and one for
> PERI.
> >> How would this work with only default framework having items ... is
> it
> >> like I was saying, you use the BOOKS framework for the
> bibliographic 
> >> data, then when you go to enter item information it changes to the
> 
> >> default framework?
> >>     
> > Yep, that's the idea. You'd want to revert to the default framework
> > whenever you went to edit items. I guess the limitation this would
> > put on you is that you couldn't have more than one framework for 
> > items, but the alternative is the possibility that you'd have 
> > conflicts ... I dunno, maybe its 6 to one, half dozen to the other,
> > what do you think?
> >
> >   
> let me tell you about a UNIMARC french special use :
> We commonly use 995 recommandation which specifies holding tags and
> subfields.
> So that it is only tag 995$k that contains itemcallnumber, 995$f
> itembarcode.
> 
> According to what you say, the problem comes when ppl choose 952$p
> for
> barcodes for books and 952$b for barcodes for PERI.
> And yes, THIS is a problem.
> 1) But the fact is that all our *MARC to Koha Links* are based, as
> far
> as I know of our clients', on default framework and do not depend on
> frameworks.
> 2) an other problem to take into account is that librarians even if
> you
> have the same links may want to display an input things differently.
> For instance : for PERI, librarians use 995$v to store serial issue
> number but it is nonsense to display and use 995$v for BOOKS.
> Thus it is not only a link problem BUT also a display/input facility.
Good points Henri-Damien, I think point #2 is the clincher ... that
flexibility is important so I think sticking with the current
implementation makes the most sense.

Cheers, 

-- 
Joshua Ferraro                       SUPPORT FOR OPEN-SOURCE SOFTWARE
President, Technology       migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
address@hidden |Full Demos at http://liblime.com/koha |1(888)KohaILS