Bug 15500 - Add FRBRized view to OPAC & staff interface results
Summary: Add FRBRized view to OPAC & staff interface results
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL: http://devs.bywatersolutions.com/wp-c...
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-06 16:40 UTC by Nicole C. Engard
Modified: 2024-03-07 17:42 UTC (History)
19 users (show)

See Also:
Change sponsored?: Seeking cosponsors
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 Nicole C. Engard 2016-01-06 16:40:13 UTC
Full Spec: http://devs.bywatersolutions.com/wp-content/uploads/2015/09/FRBR.pdf

This development will be modeled after a VuFind variation named Pika.


Seeking Co-sponsors: http://devs.bywatersolutions.com/projects/add-frbrized-view-to-opac-results/
Comment 1 Joy Nelson 2019-08-13 14:50:15 UTC
Closing and reviewing FRBR specs.  Will resubmit later.
Comment 2 Jessie Zairo 2022-09-22 19:11:48 UTC
Here are some ideas we are sharing about possibilities for development of FRBR in Koha. 

This aims to bring basic FRBR functionality to the Koha OPAC. To achieve this goal we plan to break the development into several steps.

We envision the initial implementation to be built using the Koha plugin system so that code can be adapted as necessary. Once the initial functionality is working the code can then be integrated into the Koha codebase.

Groups are ISBN, Title, and Author. 
DVD matches: Title,  (brainstorm other match points)
Serials: ISSN, title,  other???

Eresources - pull the indexes into a place (side index) that we can use these when searching.  
Display - ‘overdrive/not in koha’ provide the path
Group id? Assigned at the time it is ingested.
Have a unique ‘reindexer’ that will pull in the records and index them.


1 - Add a "group ID" to the bibliographic record.
	a - The groupID will be stored in the koha database for use in grouping and fetching records
	b - The groupID will be stored in the MARC record as well
	c - The gorupID will also contain a 'source' field, this way multiple group IDs can use different sources of truth
2 - Build a system for entering the groupID
	a - The initial method will allow for adding/grouping manually
3 - Records containing a group ID will display the other records containing the same group ID on the results or details page
	a - Provide an API to retrieve records by GroupID
	b - Develop UI functionality using React or similar framework
4 - Search results will combine records with the same groupID as a single result using the most relevant record as the main display, other records will be accessible via a dropdown menu/view
	a - This development will be targeted at the Elasticsearch engine
5 - Develop a system for storing the group ID and allowing lookup by ISBN
	a - This may use the MANA system in development for Koha
	b - This may use an outside source such as 'Bookbrainz' as it mastures
	c - This will be exapandable to allow for multiple future linkings
Comment 3 Jason Robb 2022-10-05 15:09:23 UTC
Would love to see this working both in the staff client and OPAC, and would *really* love to see hold capability added to increase patron ease of access to resources with multiple editions living on different bib records.

I wonder if Koha's existing authorities architecture could be leveraged as a jumping off point for this? There are some parallels.

FRBR organizes things from the top-down - Work > Expression > Manifestation > Item

Generally we're only handling Manifestations (at the bib level) and Items (at the item level) in Koha.

We could potentially create a collection of "records" for Works similar to an authority file by pulling the general attributes out of existing bib records then merging them into singular "records" for each Work.

The Work "record" could store the groupID along with other relevant information, including matchpoints like author, ISBNs and eventually links to external records of the work (LibraryThing, OpenLibrary, Wikidata, etc.)

The identifier of the Work could then be added into relevant bib records (maybe the 775?) to create a horizontal link between multiple bib records.

Ideally this would all be automated, where, if you bring in a bib record for new edition of an existing Work it gets linked to the existing Work automatically. And if that Work doesn't exist yet, a new Work "record" is generated.

Authorities can do some of this type of thing already, just with different parts of the record. And some of the tools in the authorities module would also be useful for managing Works as far as editing, merging, etc.

Just a thought!
Comment 4 Heather 2022-10-05 19:44:15 UTC
Oh, Jason, your thoughts are so cataloging-tastic!!

(Please note, all my remarks are MARC21-centric.)

Authority records have long had a role in this sort of clustering, e.g., see this authority record for The Hobbit by Tolkien:
https://lccn.loc.gov/n79102640

And the work record here:
http://experiment.worldcat.org/entity/work/data/449428
Every expression of this work will have the authorized 100 field for Tolkien and a 240 10 Hobbit
With the 245 field reflecting the transcribed title of the expression.  The 100/240 pairing is used (with the cross references in the authority record to facilitate searching) to cluster the expressions (and manifestations) under the work record.  (With the 1XX in the bib having the $9 containing the record number of the author/title authority record?  And/or the 240 having this $9?  I'm not sure how it's currently working--I could look into it & experiment if it's helpful.)

But not all works have authority records, and authorities can be a big learning curve.  And not all bibs with a 1XX/240 pairing have authority records.

If Koha could use the pre-RDA (and early RDA) 1XX/240 pairings to cluster, that would be fabulous.  If this could be a simple matter of developer magic, that would be lovely!

But, yes, 7XX Linking Entry Fields are wonderful and can also be used!!!  It's what they are there for, and where RDA is going--they're going to be used more and m ore.  All linking entry links in Koha would have to be functional, but that's another bug(s) and soapbox...:)  A 775 is perfect for actual other editions (you cataloger, you, Jason!), but you would sometimes have a 776 ("Additional Physical Form Entry") for ebooks of a book, audiobooks of a book, etc.--that is, e.g., an audiobook would have the 776 linking back to the print book from which it was read, and also a 775 back to the work record--so a bib record would have to be created for the work.  This is really easy to do, and I think it would be easier for a lot of libraries to do than to wade into authorities.  Because you have to have something to put into the $w of the 775--a record number (for OCLC libraries, its typically an OCLC record number in the corresponding 001 bib record).

It would be very possible to automate this--once a bib record set is created of the expressions, and a work bib record is created, the identical 775 could be placed in all the manifestations of the bib.

But, then again, wouldn't it be nice if there could be some developer magic that would allow the library to set the matching threshold, and then a search would just cluster the similar bibs together, based on matching 1XX and/or 24X fields?  (And absolutely clustering those bibs that have an authority record with corresponding 1XX/240, or 130, or those bibs with 1000% matching 775s?)

Cheerio!
h2
Comment 5 Jonathan Field 2022-10-06 16:28:11 UTC
These are great ideas and authority records give the consistency (although many libraries have now stopped using authorities; at least here). The biggest UK MARC record supplier has recently changed from supplying LC headings to FAST heading - https://www.oclc.org/research/areas/data-science/fast.html. I think this is the direction LC are going as they are involved? As well as Subject Headings this also includes Authors and Uniform Titles. 

They are also supplying ISNI numbers - https://isni.org/ which, if widely adopted, could improve data consistency across multiple systems (I'm thinking print, ebook, audiobook etc. here).

Although not directly related to the FRBR issue, data consistency is the key to good grouping. So the more consistent/accurate the data, the better FRBR experience.

To implement it as suggested would be a great start though, sorting out poor data could potentially be ironed out and improved upon later on.
Comment 6 Katrin Fischer 2022-10-14 18:51:53 UTC
If you decide that there will be information added to the MARC records automatically, could we make the field configurable maybe or use a field that is not used in standard MARC?

In our situation records are automatically overwritten/overlaid with a new version of the record from the union catalog every time someone changes/updates the records in the union catalog. In the past, all features altering the MARC record were quite problematic for us. But: we do have MARC overlay rules now :)

Maybe a subfield of 942 could be used? This already lends itself to being write-protected having the OPAC suppression and item type as subfields.
Comment 7 Heather 2022-10-21 21:27:58 UTC
(In reply to Jonathan Field from comment #5)

Hi, Jonathan!

FAST is only a project of OCLC, based on Library of Congress Subject Headings:
https://fast.oclc.org/
I haven't heard anything about Library of Congress being involved, and their application and use of authorized terms based on their authority records/file is, well, essential to the project.:)  Library of Congress is definitely not moving away from authorities, and most academic and research libraries aren't moving away from them, at least here!  Authorities are even essential when moving to using URIs--the URI has to point to something.:)


Cheerio!
h2
Comment 8 Jonathan Field 2022-10-25 06:13:16 UTC
Thanks Heather, that's interesting. The communication we had was:-

"In line with the British Library and in order to future proof our records, BDS plans to move to include FAST and ISNI in our records as of the 1st of October 2022.". 

BDS are the largest supplier of MARC records in the UK. The British Library ... well .. they're the British Library! It will be interesting to see where this goes. Sorry, slightly off-topic now if this isn't directly related to FRBR.
Comment 9 Heather 2022-10-25 14:28:43 UTC
Hi, Jonathan!  That's great that FAST & ISNI will be included with other data (I hope *with* the other metadata!)--they would be valuable additions to the rest of the metadata.  And this is kind of on topic--all identifying metadata is potentially useful if the FRBR clustering does end up operating like a profiled weighted search-match-cluster (rather than depending on one human-added control number field).  And we're back on topic!  The crowd goes wild!!:)

--h2