I totally agree here! I'm headed to ALA right now and hope to write more later but let me give one example of where Bibframe makes huge strides for users. Music has been very I'll served by MARC, the combination of complex data, multiple works contained in a single resource, and a flat file structure makes discovery extremely difficult.
Bibframe allows you to include information such as performers, subject headings, timings, etc. in the individual bf:work areas for each individual resource in a multiple-resource collection( I.e. Sound recording). All those false drops in searching that are pervasive in discovery systems now that are based on MARC can be eliminated. This is a HUGE win for us music folks. A brilliant solution and directly user focused.
Sent from my iPhone
> On Jun 25, 2014, at 8:45 AM, "[log in to unmask]" <[log in to unmask]> wrote:
> I'll add my own thought: the notions of "use case" and "functional requirement" are most powerful and meaningful when they are centered on _patron_ uses and requirements for functions exercised by _patrons_ (as opposed to _librarians_, using the term broadly: I mean to distinguish between those who are served and those who serve). It is not very clear to me by what process ideas about patron uses and requirements have informed the construction of Bibframe.
> A. Soroka
> The University of Virginia Library
>> On Jun 25, 2014, at 10:34 AM, Karen Coyle <[log in to unmask]> wrote:
>> Nowhere, however, do a see a serious discussion in the library data creation community of use cases and functional requirements. (And, believe me, FRBR does not provide this.) Many of the elements that have been added to MARC over the years (after taking many hours of discussion within the MARC committee) rarely appear in actual library data. Yet more continue to be added. Where are we headed? Why? What is the result we seek?