Talk:Analytic Record support

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:

Individual photographs in a collection
Articles in a Serials issue

MARC representation of relationships

In 773/774, do we use $w to store the control number of the related biblio?
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:

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.
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: ;)