Print

Print


> 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.
-- What you are seeing is us (LC, Zepheira, the EEs) testing the feasibility of that high-level model.  We are fairly pleased with those tests to date.  We dove deep and straight into translations in the interest of taking the model out for a test drive.  Now, it is time to turn our attention to fine-tuning precisely *how* to represent library things in BIBFRAME while ensuring we can represent our current bibliographic data.


> 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).
-- This is a result of two things:  1) two different code bases that take MARC Bib records and model them as BIBFRAME resources differently (one by LC, one by Zepheira) and 2) incomplete mapping.  With regard to point 1, the two different code bases represent LC and Zepheira experimentations with the model and slightly different interpretations (though, they're actually fairly close in terms of "splitting" MARC records).  With regard to point 2, we weren't aiming for comprehensive.  Suffice it to say, there's a lot more than genre missing.  (LCCN's are a separate issue.  As every MARC Bib record can be split into 1 BIBFRAME Work and 1 or more Instances, where to assign the LCCN, and its meaning moving forward, is tricky.)


> Should there not be a clearer picture at some intermediate level?
-- We're working on this presently.  We hope to publish a website soon that will provide a view of the proposed BIBFRAME vocabulary (classes, properties, etc).  We view the website as complementary to the high-level model document.  I think - if I understand correctly - that this is the intermediate step you feel is missing.  That said, it won't be complete vocabulary (nor has a complete vocabulary been our aim).  In fact, I expect you'll see we still have a lot of ground to cover.  But, we want to make it available, to open it up to constructive discussion to ensure that the vocabulary captures the semantics and structure we need to represent our data.


> By focusing so much on translating MARC to Bibframe early on, I fear
> that we may repeat the mistakes of the past.
-- This concern is understandable.  There are a couple of things at play that keep MARC in the picture: we have to migrate our data from MARC (which, a constant reminder, keeps bringing us back to MARC) and we have an awful lot of MARC with which to experiment (which makes it handy and means that, in order to test the feasibility, that mapping is inevitable).  On the other hand, instead of discussing ideas and solutions in the abstract, we can work directly with the model.  Have we wanted to turn our attention to other mappings:  yes.  Has there been time for that, yet: no.  Have we wanted to look at specific classes of material (such as your film example): yes.  Has there been time for that, yet: no.  We want to, and the time you spent detailing the film example has been illustrative for us (and I imagine others).

All that said, we are very cognizant that BIBFRAME is *not* MARC and that it shouldn't be a rote translation from MARC.  I don't think any of us want to carry over mistakes from the past.

Yours,
Kevin



> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of Kelley McGrath
> Sent: Thursday, January 24, 2013 12:01 AM
> To: [log in to unmask]
> Subject: [BIBFRAME] Bibframe and translations from MARC
> 
> 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