Bug 39326 - package-dependant title information should be managed at resource level
Summary: package-dependant title information should be managed at resource level
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: ERM (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-03-13 17:46 UTC by Mathieu Saby
Modified: 2025-03-17 12:54 UTC (History)
6 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Saby 2025-03-13 17:46:13 UTC
In ERM we can have an title, say /erm/eholdings/local/titles/8 which belong to 2 packages. For each package I understand Koha will create a "resource" (a rather vague term...) , say /erm/eholdings/local/resources/11 and /erm/eholdings/local/titles/12

Currently the "title" contains bibliographical information (that will never change : the title, publisher, isbn for a book, issn, etc), but also information that depends on the package (the URL, the coverage dates for a serial, a note about access, etc)

I believe all those package-level information should be managed at the "resource" level. Other ERM have something like "resource" and use it that way.

Clarifying this point could help resolve other difficulties like the management of the kbart or the "biblio list" (some fields will be imported as component of "title", other as components of "resource")

What do you think of this proposal ?
Comment 1 Michaela Sieber 2025-03-17 12:54:06 UTC
(In reply to Mathieu Saby from comment #0)
> In ERM we can have an title, say /erm/eholdings/local/titles/8 which belong
> to 2 packages. For each package I understand Koha will create a "resource"
> (a rather vague term...) , say /erm/eholdings/local/resources/11 and
> /erm/eholdings/local/titles/12
> 
> Currently the "title" contains bibliographical information (that will never
> change : the title, publisher, isbn for a book, issn, etc), but also
> information that depends on the package (the URL, the coverage dates for a
> serial, a note about access, etc)
> 
> I believe all those package-level information should be managed at the
> "resource" level. Other ERM have something like "resource" and use it that
> way.
> 
> Clarifying this point could help resolve other difficulties like the
> management of the kbart or the "biblio list" (some fields will be imported
> as component of "title", other as components of "resource")
> 
> What do you think of this proposal ?

Generally I agree. 
But this would be a change of the existing data model because today a title record can exist without a resource record. Today the resource only exists if there is a link to at least one package.

I think all attributes in title records match to the KBART format. These are:

- publication_title
- print_identifier
- online_identifier
- date_first_issue_online 
- num_first_vol_online
- num_first_issue_online
- date_last_issue_online
- num_last_vol_online
- num_last_issue_online
- title_url
- first_author
- title_id
- embargo_info
- coverage_depth
- notes
- publisher_name
- publication_type
- date_monograph_published_print
- date_monograph_published_online
- monograph_volume
- monograph_edition
- first_editor
- parent_publication_title_id
- preceding_publication_title_id
- access_type


As far as I can see the upload of a KBART file (E-resource management>eHoldings>
Local>Titles>Import from a KBART file) 
requires the choice of an existing package.
In this case there will be resource records for all the uploaded titles from the KBART list.

In my opinion it would be consistent to always create a resource record (even if you enter data manually) and keep the access data (like url, coverage, embargo,..) on the resource level.

But as I said, this is not a small change.
Maybe we should discuss that in Marseille ;-)