Good morning, On Mon, Jan 9, 2012 at 9:55 AM, Galen Charlton <gmc@esilibrary.com> wrote:

On 01/09/2012 09:44 AM, Zeno Tajoli wrote:

...

I want to add, in "Koha to MARC mapping" a link beetween the mysql field biblio.frameworkcode to a marc21 subfield.

I think it is useful to have this data in the marc record.

Could you elaborate more on the use case this would support? The framework code is displayed in the bib editor, for example, which is one point where a cataloger would need to know about it. Adding it to the MARC framework would make it available for searching and make it a little more convenient to display the framework code in XSLT OPAC displays -- but to what end?

I have no idea, but I have no particular objection to it being stored in the MARC record. For MARC21 frameworks, if we were add to this to the default framework, I'd

prefer that the 942 or the 999 be used, as those are already supported for bib-level mappings -- no need to carve out another tag.

+1 on 942 Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/

Hi. This does open up possibilities for loading bib data directly into a particular framework. Currently for data loading I have not found any way to load bib records into anything but default framework and then with SQL change the frameworkcode for a range of biblionumbers (if I remembered to catch the numbers). Even if this is not automatically done as part of this change we could run sql to change the framework dependent on the contents of the subfield of 942 field. Hopefully the act of loading the bib data would not overwrite the 942 subfield as "default" (as currently bibs are loaded into default), if you see what I mean. Sounds a positive move to me. Ian On 09/01/2012 15:08, Galen Charlton wrote:

Hi,

On 01/09/2012 10:06 AM, Jared Camins-Esakov wrote:

...

On Mon, Jan 9, 2012 at 9:55 AM, Galen Charlton <gmc@esilibrary.com <mailto:gmc@esilibrary.com>> wrote: Could you elaborate more on the use case this would support? The framework code is displayed in the bib editor, for example, which is one point where a cataloger would need to know about it. Adding it to the MARC framework would make it available for searching and make it a little more convenient to display the framework code in XSLT OPAC displays -- but to what end?

I have no idea, but I have no particular objection to it being stored in the MARC record.

And to be clear, I don't have a particular objection either, just curiosity regarding the use case.

Regards,

Galen

-- Ian Bays Director of Projects, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7774 995297 (mobile) +44 (0) 800 756 6384 (fax) skype: ian.bays email: ian.bays@ptfs-europe.com

Zeno, et. al., On Mon, Jan 9, 2012 at 10:32 AM, Zeno Tajoli <tajoli@cilea.it> wrote:

oh, is quite simple. I want to export data in marc format to import in an other Koha and I use different frameworks to catalogue.

If I insertr biblio.frameworkcode, I can re-import records in different frameworks.

Clearly I need to setup 'marc to Koha links' before to import with bulkmarcimport.pl

...

For MARC21 frameworks, if we were add to this to the default framework, I'd prefer that the 942 or the 999 be used, as those are already supported for bib-level mappings -- no need to carve out another tag.

Well, in theory 999 are repetable, 942 is not repetable. So for me is better 942. A new subfield or we re-use $a ? The subfield used are [default framework]: -- 942

What about 942$f? For 'F'ramework? Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/

Hi to all, Il 09/01/2012 16:55, Ian Walls ha scritto:

I support 942$f for the following reasons:

1. best to use an existing tag, and 942 is the best-fit candidate for non-repeating biblio-level, Koha-specific information

2. New subfields for new content, rather than repurposing an old field (and possibly having data conflicts on systems that still have the old, obsolete value)

3. subfield letter is the initial (in English) for the thing being stored; easy to remember!

for me 942 $f is OK. Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer

Hi, On 01/09/2012 10:32 AM, Zeno Tajoli wrote:

Well, in theory 999 are repetable,

Actually, that's a problem. The 999 is indeed marked as repeatable in the (MARC21) frameworks, but since it is used to store the biblio(item)number, it really shouldn't be marked as repeatable (or even editable by staff users). Does anybody see any problem making it non-repeatable? Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

At 11:17 AM 1/9/2012 -0500, Galen Charlton wrote:

Hi,

On 01/09/2012 10:32 AM, Zeno Tajoli wrote:

...

Well, in theory 999 are repetable,

Actually, that's a problem. The 999 is indeed marked as repeatable in the (MARC21) frameworks, but since it is used to store the biblio(item)number, it really shouldn't be marked as repeatable (or even editable by staff users). Does anybody see any problem making it non-repeatable?

As far as I can see, they already appear to be non-repeatable (unless I modded the default framework in 3.2 and it's been imported into 3.6.) I find all four subfields (a, b, c and d) non-repeatable (according to the check box) and it doesn't seem to make much difference whether they are "ignored" or in tab 0 as no cataloguer will be able to attempt an edit|modification. Am I missing something? Or have I done something stupid? Thanks - Paul

Regards,

Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://UltraMarine.ca>, <http://AandC.org> and <http://MarDoc.ca>

Hi Paul and all,

----- Messaggio originale ----- Da: "Paul" <paul.a@aandc.org>

As far as I can see, they already appear to be non-repeatable (unless I modded the default framework in 3.2 and it's been imported into 3.6.)

If you see the definitions of file installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.sql lines 46 - 53: INSERT INTO `marc_tag_structure` (`tagfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `authorised_value`, `frameworkcode`) VALUES ('999', 'SYSTEM CONTROL NUMBERS (KOHA)', 'SYSTEM CONTROL NUMBERS (KOHA)', 1, 0, '', ''); INSERT INTO `marc_subfield_structure` (`tagfield`, `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `kohafield`, `tab`, `authorised_value`, `authtypecode`, `value_builder`, `isurl`, `hidden`, `frameworkcode`, `seealso`, `link`, `defaultvalue`) VALUES ('999', 'a', 'Item type [OBSOLETE]', 'Item type [OBSOLETE]', 0, 0, [...] ('999', 'b', 'Koha Dewey Subclass [OBSOLETE]', 'Koha Dewey Subclass [OBSOLETE]', 0, 0, [...] ('999', 'c', 'Koha biblionumber', 'Koha biblionumber', 0, 0, [...] ('999', 'd', 'Koha biblioitemnumber', 'Koha biblioitemnumber', 0, 0, [...] The result is: Field 999: repeatable Subfield 999$a: not repeatable Subfield 999$b: not repeatable Subfield 999$c: not repeatable Subfield 999$d: not repeatable But it is only the default. It was so also in 3.2 No problems if you change it. Bye Zeno Tajoli _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

Hi Paul and all, Il 27/01/2012 16:01, Paul Poulain ha scritto:

...

I want to add, in "Koha to MARC mapping" a link beetween the mysql field biblio.frameworkcode to a marc21 subfield.

I think it is useful to have this data in the marc record. I propose to use 997 $a. The tag 997 is an empty tag. Seeing this message just now, sorry for the delay: Just a big warning = be carefull that just mapping won't probably work well. It will need a lot of testing, but I fear that, frameworkcode being managed not like other fields, it won't work from scratch, you'll have to change many things in the core of Koha.

Maybe I'm too anxious though... but just double or triple check !

do you have any idea where can I start to check ? At present I use 942$f linked with biblio.frameworkcode and I don't see problems. In fact I use it in mass import. My MARC Bibliographic frameworks have a 942$f with a default value taken from an authorized list, a different value fro every framework. And catalogue don't change the value, so every update is a confirmation of the first input. Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer