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
|