On 03/27/12 11:50, Michael Hopwood wrote:
> Hi Graham, do I know you from RHUL?
Yes indeed :-)
> 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.
In my case, I can't avoid it as it's a specific requirement: I'm doing a
federated search across a large number of libraries, and if closely
similar items aren't merged, the results become excessively large and
repetitive. I'm merging all the similar items, displaying a summary of
the merged bibliographic data, and providing links to each of the
libraries with a copy. So it's not really FRBRization in the normal
sense, I just thought that FRBRization would lead to similar problems,
so that there might be some well-known discussion of the issues
around... The merger of the records does have advantages, especially if
some libraries have very underpopulated records (eg subject fields).
> 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.:
> -----Original Message-----
> 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