There's an apparent flaw in the structure of the biblio_field record structure.
It's not uncommon to have a biblio with repeated tags containing the same numerical identifier (e.g. 710). If one of the repeated tags has multiple subfields, there's no way to associate the subfields with the appropriate tag. Grouping of subfields can be inferred from the record's fieldid order, but that's a fragile association and it stops working if subfields are added to the repeated tags.
This is a structural problem. Fixing it will have far-reaching consequences but I feel it should be corrected. It looks like subfields should have a separate table but perhaps it would work by adding a tag_group_id?
(I've tried to expand the Subject tag handling in my installation of OpenBiblio, which relies heavily on download--Z39.50--MARC records but cannot do it with the current record structure; the main subject headings gets decoupled from their relevant subfields.)
Did you have a look at this item in the bug tracker?
>> Did you have a look at this item in the bug tracker?
Thanks, I had looked through the feature requests but not the bugs so I missed that.
It's discouraging, though, that the bug was listed over 2 1/2 years ago. It doesn't appear as though any action has been taken on it. Am I missing something or is this not as serious as it appears?
It's all a matter of priorities.
Bug 844825 Broken Database Format
This is a serious problem if you want to do serious cataloging. I keep my records as simple as possible and try to live with current OpenBiblio limitations like not being 100% MARC compatible. I accept data loss when importing trough Z39.50 only because I don't expect the need for more complicated records in the future.
Speed of OpenBiblio development
Recently my library hired someone. We got what we needed very fast.
It's very serious, and you aren't missing anything. The problem is that I have very limited time for OpenBiblio work -- especially since I'm maintaining 2 very different versions of OpenBiblio. I fixed this particular bug before I filed that bug report, but at the time I couldn't integrate my fix with stock OpenBiblio. I was working on a custom version, and it seriously diverged from stock OpenBiblio during the time that I couldn't do integration work.
After 0.6.0 (which is almost complete in CVS), I will be pulling the stock OpenBiblio improvements since 0.4.0 into my custom version, and the custom version will become the official version. I have no timeframe on this, though. If you need this feature now, I can send you the custom version. Just be aware that it is quite different in a number of ways.
I have been trying to remove some of the fields from the system but have not managed. Anyone with a solution please help me. There are so many fields in the system which are not important like the LC control number DDC and many more. I am able to add fields and not to remove the unwanted ones. Please help
A How To has been added to the Documentation section of the project web site:
Hope that answers your question.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.