Print

Print


Lack of response may be due to other commitments this time of year perhaps?

Although, my primary interest and concern is the internationalisation
architecture that will underly Bibframe.

Andrew
On 08/01/2013 6:55 AM, "Karen Coyle" <[log in to unmask]> 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
>
>
> --
> Karen [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
>