LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


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: Thoughts on the direction of Bibframe

From:

Laurence Creider <[log in to unmask]>

Reply-To:

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

Date:

Mon, 7 Jan 2013 16:13:16 -0700

Content-Type:

MULTIPART/MIXED

Parts/Attachments:

Parts/Attachments

TEXT/PLAIN (203 lines)

I thought that Kelley's posts were excellent, but I did not have anything 
to add.  What I am waiting for is some response from people more involved 
with the Bibframe initiative.  We seem to have to go through this issue of 
communication and transparency every time rules or formats are changed.  A 
small group of people is needed to carry things out, but the best results 
are obtained by wide and patient consultation.  This is especially true 
when dealing with a revision of the foundations of the last 40+ years of 
work.

--
Laurence S. Creider
Interim Head,
Archives and Special Collections Dept.
New Mexico State University
Las Cruces, NM  88003
Work: 575-646-4756
Fax: 575-646-7477
[log in to unmask]



On Mon, 7 Jan 2013, Karen Coyle wrote:

> Kelley,
> 
> When I saw your posts (both excellent, BTW) I was hoping that these would
> stir discussion. I must admit that the lack of response is puzzling. I
> whole-heartedly agree that the lack of discussion and the vagueness of the
> direction of BIBFRAME make it very hard to get a mental foot-hold on the
> whole thing.
> 
> I would be willing to give comments on the examples, or to create more
> examples, if the interest is there. In absence of that it doesn't make much
> sense to spend time on this. I would say something pithy about beating a
> dead horse, but at the moment I can't even find the horse!
> 
> kc
> 
> On 1/6/13 4:50 PM, Kelley McGrath wrote:
>
>       I thought I would share some thoughts I've had about the recent
>       exchanges (or lack thereof) on the Bibframe list in case they're
>       helpful to someone else. In another thread someone asked, "What
>       is the point of the current exercise?" That question wasn't
>       really satisfactorily answered that I can see.
>
>        
>
>       In the month since the "early experimentation code" to translate
>       MARC to Bibframe was made available, there has been little
>       substantive discussion. It seems to me that the biggest reason
>       is that this process has effectively disenfranchised a huge
>       percentage of the potential audience who lack the time or skills
>       or inclination to set up their own tool. I would like to give a
>       shout out to Karen Coyle for putting up a few examples for the
>       rest of us. It seems to me that putting up even 10 or 12
>       well-chosen examples could have stimulated a lot of discussion.
>       There's also the question of making the display accessible. I
>       can more-or-less follow what Karen put up, but I suspect it will
>       be harder for many catalogers. Just as the end user needs a
>       pretty display so too will there need to be a human-friendly
>       display of Bibframe for the cataloger. Sample records in such a
>       display would probably be reassuring to many.
>
>        
>
>       Alternatively, catalogers would get a lot from a plain table
>       showing what's mapped from MARC and to where, as well as what's
>       not being mapped. Something like what RDA did:
>       http://access.rdatoolkit.org/document.php?id=jscmap2.
>
>        
>
>       On a more fundamental level, I wonder why we are not only
>       starting by testing transformation tools (which would seem to me
>       to come near the end), but why we are starting with
>       transformations at all. Of course, it's essential that MARC
>       translate into Bibframe in some useful fashion, but it makes
>       more sense to me to start the discussion with questions like
>       "What should Bibframe do?" I find that with what I have seen so
>       far, I am somehow missing the big picture, the shape of
>       Bibframe. To me, the most important question is not "How do we
>       translate MARC to linked data/RDF?" but "What should Bibframe
>       look like to do as much as possible of what we want to do?" We
>       would benefit from a more thorough analysis of what MARC is
>       really doing now, such as the work that Karen Coyle describes in
>       her article MARC21 as Data: A Start
>       (http://journal.code4lib.org/articles/5468), as well as a list
>       of current complaints and desires. What is MARC doing and what
>       is it not doing that we want it to do—from the answers to these
>       questions we should decide what Bibframe will do.
>
>        
>
>       I am very interested in the potential of Bibframe to deal with
>       things that MARC doesn't handle well (like anthologies and other
>       items that include multiple works). How would you put data into
>       it if you were doing it from scratch? How can we make Bibframe
>       an improvement on MARC and what it can do? To take an easy
>       example, once we are freed from the constraints of letters and
>       numbers for subfields, we should do better than the woefully
>       inadequately tagged:
>
>        
>
>       245 00 $a Library = $b Bibliothek ; Every book its reader / $c
>       directed by John J. Smith.  Cataloging is fun : a short /
>       directed by J. Johnson, Jr. and Anna Allen ; produced by Jane
>       Jones.
>
>        
>
>       Something like this would seem better (clearly this it totally
>       not how you would construct this, but I think you can see the
>       point of this quick example):
>
>        
>
>       <first work>
>
>       <title> Library</title proper>
>
>       <parallel title> Bibliothek </parallel title>
>
>       <statement of responsibility> directed by John J. Smith
>       </statement of responsibility>
>
>       </first work>
>
>        
>
>       <second work>
>
>       <title> Every book its reader </title proper>
>
>       <statement of responsibility> directed by John J. Smith
>       </statement of responsibility>
>
>       </second work>
>
>        
>
>       <third work>
>
>       <title> Cataloging is fun </title proper>
>
>       <other title information> a short </other title information>
>
>       <statement of responsibility> directed by J. Johnson, Jr. and
>       Anna Allen </statement of responsibility>
>       <statement of responsibility> produced by Jane Jones </statement
>       of responsibility>
>
>       </third work>
>
>        
>
>       perhaps you could even have something like:
>
>        
>
>       <statement of responsibility>
>
>       <function statement> directed by </function statement>
>
>       <name statement> J. Johnson, Jr. </name statement>
>
>       <conjunction> and </conjunction>
>
>       <name statement> Anna Allen </name statement>
>
>       </statement of responsibility>
>
>        
>
>       Do we need parallel tracks where born-Bibframe records look a
>       little different from translated-from-MARC records? Since it is
>       unreasonable to expect a computer to reliably parse things like
>       the above 245 field on the necessary scale, we'll need something
>       to do with things like "$b Bibliothek ; Every book its reader."
>       Perhaps some intermediate step, such as labeling it "<additional
>       title info (other title info, parallel title; additional titles
>       by same authors)>" and then cleaning it up later (if at all),
>       would work. In most cases, a better job could be done with 245
>       $b conversion by taking into account punctuation, but I see
>       little hope for $c.
>
>        
>
>       I am also interested in the extensibility and hospitality of
>       Bibframe. Despite all the complaints about the complexity of
>       MARC, there are still areas where it lacks desirable
>       granularity. In addition to the above lack of subfields in 245,
>       there was recently a discussion on the OLAC list about the
>       conflation of subtitles, captions and intertitles in $j. The
>       sense was that at least that last should be coded separately and
>       I think a case could be made for the first two as well. I
>       suspect there are many such things lurking.
>
>        
>
>       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

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