Re: [Koha-devel] Holdings and MARC Frameworks

[Henri-Damien LAURENT]

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.

My 2cts.
-- 
Henri-Damien LAURENT