[Koha-devel] Imported MARC notice and Authorities: : inconsistent database
Chris Cormack
chrisc at catalyst.net.nz
Wed Feb 16 09:02:28 CET 2011
* Fridolyn SOMERS (fridolyn.somers at gmail.com) wrote:
> Hie,
>
> Thanks for the solution.
>
> I have a question :
> In this script, it seems that if the authority is changed, the items are
> deleted :
> # delete any item tags
> my ($itemtag, $itemsubfield) =
> GetMarcFromKohaField("items.itemnumber", '');
> foreach my $field ($bib->field($itemtag)) {
> $bib->delete_field($field);
> }
>
> Why is that ?
Hi Fridolyn
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2258
If you want to know more check out commit
6858da97c361fe9a5fddfed7c6d9b1103b27dca0
The commit message is
bug 2258 - do not duplicate embedded items
If a MARC bib is modified by this batch job,
do not duplicate the item tags embedded in
it (e.g., 952 for MARC21). When modifying
a bib record, any embedded item tags must
be removed before calling ModBiblio - perhaps
this should be moved to ModBiblio itself.
Also removed an error in the job's help
text.
FYI I found this information using git blame.
Chris
>
> Regards,
>
> 2011/2/15 Chris Cormack <[1]chrisc at catalyst.net.nz>
>
> * Fridolyn SOMERS ([2]fridolyn.somers at gmail.com) wrote:
> > Hie,
> >
> > I see what you meen.
> >
> > But has far as I know, the link between biblio and authorities is
> not
> > managed during import (it would be quite difficult I think).
> > Subfield 700$9 is considered as a normal data.
> >
> > You may find a script in Koha to synchronise the biblio fields with
> the
> > existing authorities.
> > If not, you'll have to create it. Maybe a SQL script is enought.
> >
> > Tell us if you suceed.
>
> Hi All
>
> There is a script in misc [3]link_bibs_to_authorities.pl which should
> create the linkages for you
>
> Chris
>
> >
> > Best regards,
> >
> > 2011/2/15 Fr�re S�bastien <[1][4]semarie-koha at latrappe.fr>
> >
> > Hello,
> >
> > As we obtain no reply for an inconsistent database, I will
> explain again
> > the problem, with SQL for examples.
> >
> > Currently, after using imported set of notices and using it we
> have the
> > following results:
> >
> > SELECT count(*)
> > �FROM biblioitems
> > �WHERE extractvalue(biblioitems.marcxml,
> > '/record/datafield[@tag="700"]/subfield[@code="9"]') != ''
> > � AND extractvalue(biblioitems.marcxml,
> > '/record/datafield[@tag="700"]/subfield[@code="9"]') NOT IN (
> > � �SELECT authid FROM auth_header );
> > +----------+
> > | count(*) |
> > +----------+
> > | � � �121 |
> > +----------+
> >
> > english-version: If I extract from MarcXML (on table biblioitems)
> the
> > 700.9 (Primary Author, koha_internal_code) and search in
> auth_header, we
> > currently have 121 items with no-existent 700.9 .
> >
> > This is only a part of the problem: some 700.9 are existent but
> wrong
> > (points to bad authority).
> >
> > SELECT count(*)
> > �FROM biblioitems, auth_header
> > �WHERE extractvalue(biblioitems.marcxml,
> > '/record/datafield[@tag="700"]/subfield[@code="9"]') =
> > auth_header.authid
> > � AND extractvalue(biblioitems.marcxml,
> > '/record/datafield[@tag="700"]/subfield[@code="a"]') !=
> > extractvalue(auth_header.marcxml,
> > '/record/datafield[@tag="200"]/subfield[@code="a"]');
> > +----------+
> > | count(*) |
> > +----------+
> > | � � � �3 |
> > +----------+
> >
> > Any suggestions ? This seems a bug (in import of notices where
> old
> > koha_internal_code is not removed), but I would prefered have
> your
> > opinion before submit a bugreport.
> >
> > And I will like some clues to correct the inconsitences !
> > Thanks.
> >
> > --
> > Fr�re S�bastien Marie
> > Abbaye Notre Dame de La Trappe
> > 61380 Soligny-la-Trappe
> > T�l: 02.33.84.17.00
> > Fax: 02.33.34.98.57
> > Web: [2][5]http://www.latrappe.fr/
> >
> > On Sat, Jan 29, 2011 at 12:13:28PM +0100, Fr�re S�bastien Marie
> wrote:
> > > Hello,
> > >
> > > Recently, we have imported a set of notices, from another
> abbey, in
> > > the reservoir.
> > >
> > > When we create a new examplar using the previous imported
> notices,
> > > the field 700.9 (authority - internal koha number) refering the
> > > auth_id isn't updated or removed (still reference the old
> authority
> > > number, in the other catalog).
> > >
> > > As result, we have an examplar with 700.a (authority name)
> correct,
> > > but with an internal reference wrong (not valid in us catalog).
> > >
> > > If we search all notices linked with an authority, there is
> wrong
> > > attribution.
> > >
> > > Next an example.
> > >
> > > Starting with:
> > > �- Notices in reservoir:
> > > � �- Title_A / Author_A (auth_id = 1) [from import]
> > >
> > > �- Authority in catalog:
> > > � �- Author_B (auth_id = 1) [created locally]
> > >
> > > �- Notice in catalog:
> > > � �- Title_B / Author_B (auth_id = 1)
> > >
> > >
> > > Next, we create a new examplar based on notice in reservoir,
> result:
> > > �- Authority in catalog:
> > > � �- Author_B (auth_id = 1) [created locally]
> > >
> > > �- Notice in catalog:
> > > � �- Title_A / Author_A (auth_id = 1)
> > > � �- Title_B / Author_B (auth_id = 1)
> > >
> > > (doubt if Author_A added in authorities or not)
> > >
> > > Now, if search notice attached with Author_B (auth_id = 1):
> > > �results:
> > > � - Title_A / Author_A (auth_id = 1)
> > > � - Title_B / Author_B (auth_id = 1)
> > >
> > > The database is inconsistent.
> > >
> > > Where is the problem:
> > > �- a misused of imported MARC: an option somewhere should be
> set...
> > > �- a bug in importing MARC: 700.9 should be cleaned before
> import...
> > > �- another possibility ?
> > >
> > > Currently, no bug report filled, as I don't no if it is a
> misusing
> > > or a bug.
> > >
> > > Thanks.
> > > --
> > > Fr�re S�bastien Marie
> > > Abbaye Notre Dame de La Trappe
> > > 61380 Soligny-la-Trappe
> > > T�l: 02.33.84.17.00
> > > Fax: 02.33.34.98.57
> > > Web: [3][6]http://www.latrappe.fr/
> > _______________________________________________
> > Koha-devel mailing list
> > [4][7]Koha-devel at lists.koha-community.org
> >
> [5][8]http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : [6][9]http://www.koha-community.org/
> > git : [7][10]http://git.koha-community.org/
> > bugs : [8][11]http://bugs.koha-community.org/
> >
> > --
> > Fridolyn SOMERS
> > ICT engineer
> > PROGILONE - Lyon - France
> > [9][12]fridolyn.somers at gmail.com
> >
> > References
> >
> > Visible links
> > 1. mailto:[13]semarie-koha at latrappe.fr
> > 2. [14]http://www.latrappe.fr/
> > 3. [15]http://www.latrappe.fr/
> > 4. mailto:[16]Koha-devel at lists.koha-community.org
> > 5.
> [17]http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > 6. [18]http://www.koha-community.org/
> > 7. [19]http://git.koha-community.org/
> > 8. [20]http://bugs.koha-community.org/
> > 9. mailto:[21]fridolyn.somers at gmail.com
> > _______________________________________________
> > Koha-devel mailing list
> > [22]Koha-devel at lists.koha-community.org
> >
> [23]http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : [24]http://www.koha-community.org/
> > git : [25]http://git.koha-community.org/
> > bugs : [26]http://bugs.koha-community.org/
>
> --
> Chris Cormack
> Catalyst IT Ltd.
> [27]+64 4 803 2238
> PO Box 11-053, Manners St, Wellington 6142, New Zealand
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1a04UACgkQZgbcHEvgMLP8wgCgk+uADfW1pIdH4bg3NqhRJBy4
> VEkAmgLTX84coNwkJT7j18YgXV2OOiCt
> =3N0Z
> -----END PGP SIGNATURE-----
>
> --
> Fridolyn SOMERS
> ICT engineer
> PROGILONE - Lyon - France
> [28]fridolyn.somers at gmail.com
>
> References
>
> Visible links
> 1. mailto:chrisc at catalyst.net.nz
> 2. mailto:fridolyn.somers at gmail.com
> 3. http://link_bibs_to_authorities.pl/
> 4. mailto:semarie-koha at latrappe.fr
> 5. http://www.latrappe.fr/
> 6. http://www.latrappe.fr/
> 7. mailto:Koha-devel at lists.koha-community.org
> 8. http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> 9. http://www.koha-community.org/
> 10. http://git.koha-community.org/
> 11. http://bugs.koha-community.org/
> 12. mailto:fridolyn.somers at gmail.com
> 13. mailto:semarie-koha at latrappe.fr
> 14. http://www.latrappe.fr/
> 15. http://www.latrappe.fr/
> 16. mailto:Koha-devel at lists.koha-community.org
> 17. http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> 18. http://www.koha-community.org/
> 19. http://git.koha-community.org/
> 20. http://bugs.koha-community.org/
> 21. mailto:fridolyn.somers at gmail.com
> 22. mailto:Koha-devel at lists.koha-community.org
> 23. http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> 24. http://www.koha-community.org/
> 25. http://git.koha-community.org/
> 26. http://bugs.koha-community.org/
> 27. file:///tmp/tel:%2B64%204%20803%202238
> 28. mailto:fridolyn.somers at gmail.com
--
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110216/b336ebce/attachment.pgp>
More information about the Koha-devel
mailing list