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