Bug 11043 - rename biblioitems.itemtype
Summary: rename biblioitems.itemtype
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Database (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-12 07:26 UTC by Mathieu Saby
Modified: 2020-11-30 21:45 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Saby 2013-10-12 07:26:53 UTC
I find biblioitems.itemtype confusing.
In discussions about itemtypes, I often had to ask which kind of itemtype it was about : "biblioitems.itemtype" or "items.itype".

It is an other issue, but zebra conf is confusing too, as in MARC21 the fields mapped with "biblioitems.itemtype" and "items.itype" are mapped with the same zebra index, whereas in UNIMARC 2 different indexes are used (biblioitems.itemtype = 099t = ccode index ; items.itype = 995r = itype index)
I think it is not normal, and should be fixed in an other bug.

biblioitems.itemtype is not about item, but about document, so what I would propose here is to rename biblioitems.itemtype to biblioitems.doctype
or maybe biblioitems.kohadoctype (as document type can also be retreived from MARC fields non specific to Koha, like 210$b in UNIMARC)

Any opinions?
Comment 1 Katrin Fischer 2013-10-20 18:17:05 UTC
I think not every library is treating the biblio level itemtype as a document type currently, so there might be different ideas and workflows involved here. What I always thought was that item-level itypes was being used as a different way to define circulation rules. Our libraries don't use the biblio level itype at all, apart from it being set to a default value, as the itemtype being picked in the item form will then preset to this.
Comment 2 Mathieu Saby 2013-10-20 18:22:07 UTC
There may be different way of using those fields, but in some templates, biblioitems.itemtype is translated as "document type". In reports maybe.

I suspect the name biblioitems.itemtype dates back to the old days of pre-marc Koha, when you could have 1 biblio for x biblioitems.
This is no longer the case, so in a bibliographic point of view, biblioitems table is used to describe documents (FRBR Manifestation), never items.
So documenttype may be more accurate.

Mathieu
Comment 3 Mathieu Saby 2013-10-20 18:26:43 UTC
In my library, in biblioitems.itemtype we put 'book', 'cd' etc
and in items.itype 'long loan', 'normal loan'
And we use items.itype for circulation rules.

Mathieu
Comment 4 Katrin Fischer 2013-10-20 18:32:30 UTC
I think you can only do that, when you change the mapping? So that you are not using the itemtypes authorised value list for both (like it is the default for MARC21 at least).
Comment 5 Mathieu Saby 2013-10-20 18:59:37 UTC
Yes, 2 different lists.
Because our vendor tell us it was possible I presume.
For circulation rules, if the rules are the same for DVD and CD, we did not want to duplicate them. So we can have
biblioitems.itemtype = DVD
items.itype = SHORT
and
biblioitems.itemtype = CD
items.itype = SHORT

Mathieu
Comment 6 Katrin Fischer 2013-10-20 19:01:49 UTC
It is totally possible, but I think this is the kind of customizations that we will have to be really careful about when we change how this works.
Comment 7 Mathieu Saby 2013-10-20 19:03:51 UTC
(In reply to Katrin Fischer from comment #4)
> I think you can only do that, when you change the mapping? So that you are
> not using the itemtypes authorised value list for both (like it is the
> default for MARC21 at least).

HMM I understand now why in Zebra, Marc21 is indexing both information in the same index, while in UNIMARC we use ccode for biblioitems.itemytpe (ccode seems quite a bad choice).
Making this more uniform could be interesting I think. Because some changes could be unseen for Marc21 ppl, while they will break configs of unimarc ppl.
And as the concept of "type of documents" and "type of items" are easily understandable by everone, and not specific to a marcflavor, I don't see why the indexing should be different.

I would appreciate to have the opinion of unimarc ppl, for example from Biblibre.

Mathieu
Comment 8 Katrin Fischer 2020-01-05 10:49:46 UTC
Discussion here boiled down to the fact, that UNIMARC users have not mapped biblioitems.itemtype to the itemtypes authorised value.

I believe this needs a different fix than suggested and is much more complex. We rely on items.itype and bilbioitems.itemtype to be the same list of itemtypes in more and more spots. Some I know of:

- Suggesting the itemtype for the item when cataloguing
- Search: In MARC21 both are indexed as itemtype, allowing to easily search for records without items too (only MARC21?)
- Article requests on records without items
- Hold limit checking

If UNIMARC uses the field differently, there is a bigger discussion to be had on how to handle this to give both MARC formats the same behaviour in circ etc. I believe if necessary document type should be a separate thing.