Hi all, In rel_2_2, every framework can have holdings fields, and this can lead to confusion when there are conflicts. I propose that in rel_3_0 we eliminate that confusion and only have holdings fields for the default framework. Any objections to this? Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua M. Ferraro wrote:
Hi all,
In rel_2_2, every framework can have holdings fields, and this can lead to confusion when there are conflicts. I propose that in rel_3_0 we eliminate that confusion and only have holdings fields for the default framework. Any objections to this?
Hi Joshua Not sure I follow you here. So would it work this way, you enter your bibliographic information using your framework, then for the holdings information it flicks to the default framework? Chris
----- "Chris Cormack" <chris@katipo.co.nz> wrote:
Joshua M. Ferraro wrote:
Hi all,
In rel_2_2, every framework can have holdings fields, and this can lead to confusion when there are conflicts. I propose that in rel_3_0 we eliminate that confusion and only have holdings fields for the default framework. Any objections to this?
Not sure I follow you here. So would it work this way, you enter your bibliographic information using your framework, then for the holdings information it flicks to the default framework? 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. Joshua
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? Chris
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
----- "Chris Cormack" <chris@katipo.co.nz> wrote: 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? -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua M. Ferraro wrote:
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?
That makes more sense, is holdings the only place where conflicts might occur? Chris
Joshua M. Ferraro a écrit :
----- "Chris Cormack" <chris@katipo.co.nz> 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
----- "Henri-Damien LAURENT" <laurenthdl@alinto.com> wrote:
----- "Chris Cormack" <chris@katipo.co.nz> 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
Joshua M. Ferraro a écrit : 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 jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Hello, I agree with this thread, so, if I summarize, we could have : - mapping MARC >> koha for items, available only for default framework. - other parameters available for any framework (display, description, tab,...) sounds OK to me. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
participants (4)
-
Chris Cormack -
Henri-Damien LAURENT -
Joshua M. Ferraro -
Paul POULAIN