On Wed, Jan 9, 2013 at 12:26 PM, Eric Miller <[log in to unmask]> wrote:
> Agreed. And that is why the translation from MARC is only one of several of the factors that went into the BIBFRAME design. For BIBFRAME we tried to balance the following:
>
> [[
> * Flexibility to accommodate future cataloguing domains, and entirely new use scenarios and sources of information
> * The Web as an architectural model for expressing and connecting decentralized information
> * Social and technical adoption outside the Library community
> * Social and technical deployment within the Library community
> * Previous efforts in expressing bibliographic material as Linked Data
> * Application of machine technology for mechanical tasks while amply accommodating the subject matter expert (the librarian) as the explicit brain behind the mechanics.
> * Previous efforts for modeling bibliographic information in the library, publishing, archival and museum communities
> * The robust and beneficial history and aspects of a common method of bibliographic information transfer
> ]]
> - http://www.loc.gov/marc/transition/pdf/marcld-report-11-21-2012.pdf
>
> The current BIBFRAME list discussion as focused on the translation to MARC (i believe) simply because sample translation code has been made available. As cataloging use-cases, end-user scenarios (very important), vocabulary browsers, more tools, more examples, etc. are made available i anticipate a shift in the dialog.

I am feeling a little slow here. At least from the outside looking in, I still don't see how we got from the very general, high level information in the November report to tinkering with different potential translations from MARC in what seems to be a trial and error approach without something in the middle.

Is there a theory beyond the mappings? In this example (http://kcoyle.net/bibframe/BFbook.html), the LCCN is mapped to the work and the genre has disappeared entirely. Here the statement of responsibility is mapped to the work (http://kcoyle.net/bibframe/BFpope.html) and here it disappears entirely (http://kcoyle.net/bibframe/pope.rdf.xml). But my point is not that the typical cataloger would do much of this differently. Rather it just seems premature to me to be discussing this at all without having a more detailed conception of what the content of the different classes should look like and how they interrelate.

Should there not be a clearer picture at some intermediate level? I still feel like I cannot discern the overall shape of Bibframe in a useful way. It seems to me that we would benefit from a more thorough analysis of what MARC is doing now as Karen Coyle has suggested. I would like to know how Bibframe plans to deal with some of today's more intractable problems, such as multi-work manifestations (and for media, this means much more than just the title of the work) or multiple manifestations of ebooks. Might it not be better to start by crafting a vision for how we want the data to look and then find a way to fit the legacy data to that model as best we can?

By focusing so much on translating MARC to Bibframe early on, I fear that we may repeat the mistakes of the past. The transition from cards to MARC was all about taking the existing framework of printing cards and doing it more efficiently with a computer. It's hard to see a way around that outcome as Henriette Avram was constrained by the limits of technology at the time. However, we now need to do more than just pour MARC wine into a new bottle. In times of radical transition, we have the opportunity for a fundamental re-think. Will our successors curse our lack of foresight? I hope that I am wrong to be worried.

Kelley