Hi Graham, do I know you from RHUL?
My thoughts on "merged records" would be:
1. don't do it - use separate IDs and just present links between related manifestations; thus avoiding potential confusions.
possible relationships - see http://www.editeur.org/ONIX/book/codelists/current.html - lists 51 (manifestation)and 164 (work).
2. c.f. the way Amazon displays rough and ready categories (paperback, hardback, audiobooks, *ahem* ebooks of some sort...)
On dissection and reconstitution of records - there is a lot of talk going on about RDFizing MaRC records and re-using in various ways, e.g.:
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of graham
Sent: 27 March 2012 11:06
To: [log in to unmask]
Subject: [CODE4LIB] presenting merged records?
There seems to be a general trend to presenting merged records to users, as part of the move towards FRBRization. If records need merging this generally means they weren't totally identical to start with, so you can end up with conflicting bibliographic data to display.
Two examples I've come across with this: Summon can merge print/electronic versions of texts, so uses a new 'merged' material type of 'book/ebook' (it doesn't yet seem to have all the other possible permutations, eg book/audiobook). Pazpar2 (which I'm working with at the
moment) has a merge option for publication dates which presents dates as a period eg 1997-2002.
The problem is not with the underlying data (the original unmerged values can still be there in the background) but how to present them to the user in an intuitive way. With the date example, presenting dates in this format sometimes throws people as it looks too much like the author birth/death dates you might see with a record.
I guess people must generally be starting to run into this kind of display problem, so it has maybe been discussed to death on ... wherever it is people talk about FRBRIzation. Any suggestions? Any mailing lists, blogs etc any can recommend for me to look at?
Thanks for any ideas