Koha Test Wiki MW Canasta on Koha Portainer

Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.

For the current Koha Wiki, visit https://wiki.koha-community.org .

Talk:Analytic Record support

From Koha Test Wiki MW Canasta on Koha Portainer
Jump to navigation Jump to search

Votes

Notes

Corrections

There needs to be a bugzilla link added to this RFC --Nengard 01:14, 11 November 2010 (UTC)

RFC Template not followed, please edit to use the template. --Nengard 01:55, 11 November 2010 (UTC)

Background

We are working on analytical records requirements related to:

  1. Individual photographs in a collection
  2. Articles in a Serials issue

MARC representation of relationships

  1. In 773/774, do we use $w to store the control number of the related biblio?
  2. For our requirements - field 774, instead of 490/830 seems a more appropriate choice for use in the parent record.

Record Import

We would like to include following in bulkmarcimport and the GUI import tools:

  1. If the biblio record contains $w in 773/774 pointing to an existing record in the database, then automatically establish the relationship between the biblios.
  2. If field 952 in the record being imported contains an itemnumber in $9 or a barcode in $p pointing to an existing item in the database, and if this existing item belongs to the related biblio as indicated in 773/774 then automatically establish the relationship between the biblio being imported and the existing item.

A chat about this problem

This is a chat log of analisys of the RFC. You can watch it in Koha log at 13/09/2010


15:17 jcamins to sekjal: before I comment on your analytic record RFC, I have a question for you. Does the RFC require a parent->child link to be present? That could result in excessively large records.

15:19 sekjal to jcamins: I was just talking to Savitra about this, but haven't gotten my ideas out beyond that thread

15:19 jcamins: Okay.

15:19 sekjal: I think there should be a concept of 'reciprocal relationships'

15:19 kf to sekjal: our idea was to provice a search link

15:19 kf to sekjal: and use some jquery magic to show the x first volumes directly in the record

15:20 sekjal: that is, if you add a 773 point record A to record B, it will automatically add a 774 from B to A (for example)

15:20 kf: parsed from the result page of the search link (not elegant... but my prototype works)

15:20 sekjal: or you could turn off the reciprocal, and only have links in one direction

15:20 kf: reciprocal will not work for us

15:21 we get our data from our union catalog - there is only a link in one direction there

15:21 as in marc21 standard

15:21 jcamins: I think we'd really like what kf is describing... a virtual reciprocal link, if you will.

15:21 kf: the union catalog data would overwrite those reciprocal links with every new import

15:22 jcamins: I think the problem with my solution is that you can't tell when to show the search link

15:22 it will show always - or perhaps you can hide it if the jquery gets no results

15:22 sekjal to kf: hmmm, okay... would it help your solution to consult a table of relationships?

15:23 that way, if on record didn't relate to any other, you wouldn't have to invoke the jquery

15:23 jcamins: We have one journal with 4176+ analytics, which would definitely put us way over the maximum record size limit.

15:24 sekjal: I think we need to store the relationships outside of MARC, and make the insertion of MARC fields something configurable depending on library policies/practices/desires

15:25 jcamins: Yeah, I like that idea.

15:25 sekjal: I'm thinking the same would hold for MFHD support

15:30 kf: sorry, afk now, will be back in a few minutes

15:30 slef to wizzyrea: thanks. Other vendors will be happy (I switched ours to use entities and work around it).

15:56 kf to sekjal: perhaps our problem is unique, not sure. for us the union catalog is the master database for the bibliographic records. If a record is changed, it's imported by a nightly import script and overwrites the record in koha.

15:56 kf to sekjal: I am not sure how your table of relationships can be maintained if you are not cataloging in koha

15:57 jcamins: Parse out 7xx fields?

15:58 kf: the import scripts need to learn to do that

15:58 kf: in that case but as you said, the records will get too big we have records for traced series too

15:59 jcamins: Yeah, savitra (I think) wanted to add that feature to mulkmarcimport. bulkmarcimport, even

15:59 kf: I had not really time to read all the rfcs :(

15:59 wizzyrea: is more interested in hulkmarcimiport, tee hee hee's

16:00 kf: :)

16:00 wizzyrea: scurries away again

16:00 jcamins: HULK IMPORT!

16:01 sekjal to kf: we'd have to make the triggering of adding a new relationshop to the table be flexible so, when a MARC record comes in with some field, the importer would either add, modify or remove the corresponding entry in the relationships table

16:03 sekjal to kf: depending on configs

16:03 jcamins: What would the overhead on that be for kf? (just throwing out whatever thoughts come to mind to clarify things for myself)

16:04 sekjal: I suppose that would depend on what config options were avaialble

16:04 kf to sekjal: we would need that as an option for the staged marc import

16:05 sekjal: we do matching by 001

16:05 sekjal to kf: yes! so we'd add lines on what to do about analytics, just like there are options for what to do with items

16:05 kf: I am not against a relationship table - but opposed to storing the information in the marc21 records

16:06 sekjal to kf: would the information be coming in from the MARC initially?

16:06 sekjal to kf: are you only looking for analytics or other relationships too? afaik the mother does not know her child records

16:07 jcamins: I'm pretty sure MARC specifies that parent->child relationships are optional.

16:07 sekjal: you'd configure whatever relationships you want in the system, and tie them to MARC if appropriate

16:08 kf to jcamins: which fields do you use in the parent?

16:08 sekjal: then the importer would look for relationships, and parse them as appropriate

16:08 kf: we have a lot of relationships in our data and we need to make them show - it's a big problem now.

16:09 kf: I started some work on $w relationships, but on a different level - just wanting to make them show

16:09 jcamins to kf: you _can_ use 774, or 787, but I'm 99% sure that it's not required, or even recommended.

16:09 kf: not thinking so much about import and cataloging, because that's not important to us

16:09 jcamins: I think it's not required

16:10 jcamins: Yeah, here it is. Definitely not required.

16:10 jcamins: http://www.loc.gov/marc/biblio[…]hic/bd76x78x.html

16:10 jcamins: About a third of the way down under "Component Parts/Constituent Units."

16:10 kf: we have separate records a work as parent and it's volumes as separate records, traced series as records with relationships, serials with former/later etc., parallel title, a lot of relationhsops

16:11 kf: relationships electronic to print version

16:13 jcamins: wishes that his library's bibliographic database was as nice as kf's.

16:13 kf: :)

16:13 kf: the work of a lot of busy librarians


16:15 kf to jcamins: "This bibliographic database [SWB] references all kinds of media of more than 1000 libraries in Baden-Wuerttemberg, Saxony, Saarland, and Rhineland-Palatinate. It contains 47 million holding records for about 12 million titles of mainly scientific literature. These comprise 1.2 million holding records of 350.000 journals."

16:16 kf: And I am hugely jealous. ;)

16:16 kf: ;)