LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  January 2013

BIBFRAME January 2013

Subject:

Re: Bibframe and translations from MARC

From:

"Ford, Kevin" <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Thu, 24 Jan 2013 11:05:35 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (107 lines)

> 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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager