[Koha] Simple MARC or Simple Acquisitions?
Joann Ransom
jransom at library.org.nz
Fri Dec 19 09:36:14 NZDT 2008
Hi all,
I am starting to feel really quite positive about acquisitions again!
Really love the idea of thinking about a range of cataloguing 'levels',
including one for non-marc cataloguers (like me!).
I wondered if we could consider FRBR too (or maybe that is what RDA is?
- I don't know sorry).
We designed Koha 1.0 with BIBLIOS, GROUPS and ITEMS to achieve a
similar result to FRBR, in that ITEMS inherit all of the attributes of
the GROUP record they are attached to, and GROUPS inherit all the
attributes of the BIBLIO they were attached to. This mean reserves could
be placed at a BIBLIO level if you didn't care which ITEM you got, or at
GROUP level (if you wanted the first ITEm available of a particular
edition) or at an ITEM level (when you wanted a specific issue of a
periodical or a specific video to send away for cleaning etc).
In planning our move to Koha 3.0 I am reconciled to the fact that we
have to run a scripty-thing over our database creating new bibios for
each group, but our way did make it very easy for patrons to place
reserves.
Cheers Jo.
BWS Johnson wrote:
> Salve!
>
> Cataloguing in general has been stewing in my brain for many years,
> and cataloguing on Koha in particular. I started on a DRA system years
> back, and I could hear a game show buzzer in my head when I saw the
> interface. Then I remember colleagues getting all excited to look at
> Dynix Horizon new cataloguing module. We just kind of looked at one
> another after the sales guys had gone away. That wasn't it either, but
> it wasn't game show buzzer bad. III was kind of nice, and as I became
> a dork and would ask people I didn't know to view their cataloguing
> systems as the years swam by I came to the conclusion that some were
> better than others but none were particularly well liked. I've long
> hated the one that's come bundled with Koha, and I've long though "Oh
> come on, I know we can do this in a sexy way!" If we put together a
> module that was better than everyone else's, that would be the
> proprietary nail in the coffin, and I don't think it's terribly
> difficult to do since everyone else's bar is so low. I arrived at the
> inevitable conclusion that this was one of many areas where it was
> going to be hard or nearly impossible to get fellow Librarians to be
> very specific in terms of what they would like to use and not just
> what was in front of them. I feel like it's the aesthetics and
> interface of things more than anything else. Big warning: I'm not
> properly a cataloguer, but gosh over the years my cataloguing disguise
> seems to be getting very good.
>
> The time to think about a major overhaul is *now* since the RDA
> proposal is on the table.
>
>
> >Hopefully starting on a new thread. Just in the last few weeks we've had
> >a couple of clients who would really benefit from an easier way to do
> >their own cataloging.
> >
> >They don't (Sadly) find their specialist materials being well serviced
> >via the various z39.50 servers etc, often because they are doing
> >cataloging of materials they are producing themselves, or from other
> >government departmens/private publishers essentially.
> >
>
>
> Yeah. There are an absolute tonne of special Libraries that simply
> *can't* find records that would match their own since they're drummed
> up in house or are so rarely held that there aren't records to be
> found to match. Engineering, transportation, medical, and legal come
> to my mind, just to name a few. I shudder to think about folks not
> having someone around that could do original cataloguing, but after a
> number of years on this project, I know from some of the cataloguing
> questions that I get that folks can't afford someone or just don't
> want someone that can do original cataloguing.
> Many times in this sort of environment, folks want a simple text box
> for Author, Title, and I think they ought to have subject just to
> round things off for the big three. I'd argue that a URL needs be in
> there for electronic organisation of data.
>
>
> >As alluded to we (Katipo) did have an interface to do this in the very
> >early versions of Koha, and I still have essentially the spec for it in
> >the form of a working version, and screen shots/manual type stuff - we
> >called it simple acquisitions, and in the current version of Koha you
> >can see that there is a preference for either simple or normal
> >acquisitions - of which only normal is really there.
> >
>
> Find another chump for acquisitions, cause I've not got mah head
> around that. ;)
>
>
> >I've been toying with the idea of seeing what's involved in essentially
> >adding a simple acquisitions module back in again - but saw that Galen I
> >think is planning something similar sounding as a simple MARC module.
> >
> >So I'm wondering if the two ideas are close enough to be the same thing?
>
>
> No, at least not from where I think. Again, I'm not expecting this any
> time soon, but I'd like to see it as a road map goal, even if it's a
> couple of releases out. (As in 4 or 5.)
>
> I think that we have several different approaches to cataloguing
> itself, and I think this is the root cause of why all interfaces suck.
> Something that programmers might want to consider is having
> permissions tied in to the different approaches, so that an amateur
> would be able to use the simple module, but not the pro version.
>
> I think there ought to be about 4 ways to handle a record in Koha, 2
> of them are close enough that they can live under the same roof. We
> should have what Rachel is asking after.
>
> Simple Cataloguing (since it's simple and she's got screenshots of
> what it used to look like, there's not really much more work in
> bringing this one back.)
>
> then I think we definitely need a new version of
>
> Pro Cataloguing
>
> I still don't totally like what I see with other products in terms of
> interface, but both Biblios and current cataloguing aren't it. I've
> seen people whip up an original MARC record in minutes tops. They want
> a blank playbox (that's a big old textbox, as for email) that will
> recognise MARC fields.
> I think we can go one better than that simple of an approach by making
> that textbox operate more like Dreamweaver. Why not have those fields
> change colour, and then have the tooltip display the name of the MARC
> field in question and perhaps a R for repeatable and a N for non
> repeatable. I think that would be a neat way of catching the
> cataloguer before they've had their java, since you'd be able to just
> hover over a blue 110 and think "Oh! Of course that's not Additional
> Author! Duh!"
> So, mostly graphical. Mostly blank. Mostly leave the professional
> cataloguer the heck alone and let them do their thing. The comment I
> hear the most on any ILS cataloguing interface is something on the
> order of "Maybe this is because I'm a little older than you, but I
> just want my typewriter and card back. It was easier. I'm not opposed
> to technology, but man, I could just do that in a few minutes."
>
> Copy Cataloguing
>
> Same approach as above, only a z39.50 button someplace on that same
> page that would let you very simply import a record by ISBN or Title.
> Here's the twist. eXtensible Catalog right now has The Thing that I
> was talking about with authorities. It goes through and finds
> Evanovich, Janet and Evanovich Janet. and Evanovich, Janet. and
> possibly even Evanogich, Janit, and asks record by record if they need
> to be deduplicated. But here's how The Thing would be applied to copy
> cataloguing.
> Disagree with me here if I'm getting out on a limb, cataloguers, but
> in general, when I was copy cataloguing with style, the longer the
> record I found via z39.50, the better the record was. The exception to
> this was the odd occasions where someone would apparently have copied
> and pasted into a record multiple times. We should be able to tell how
> long that record is before we import it. I don't know whether that's a
> constraint of z39.50 or no. The system should check internally how
> many characters are in a given record in the databases we point to and
> report a little summary back.
> I'd even love to have ratings creep into this, a la digg, though that
> may well ruffle some feathers. Is MaineInfoNet good on local stuff,
> cool, comment and mark em up. Does AccessPenn not do so great a job
> with children's records, comment and mark em down.
> A lot of people in rural Libraries end up using Delicious Library.
> That's the sort of ease to strive for on the first page of copy
> cataloguing. We could always just have a prompt if someone wanted to
> edit further after the initial ISBN scan.
>
>
> Guided Cataloguing
>
> A long time ago when animals could talk, I had an AIM discussion with
> Nicole about cataloguing. Why is all of this still a one way street
> that starts with my brain? Aren't I essentially taking different paths
> down a big flowchart in my head? When I hold an item in my hand and
> sit down to catalogue, aren't I going through pretty much the same
> thought process time in and time out? Yes, it's very complex. Yes, it
> varies per item. BUT there are questions in common. This is why those
> veteran cataloguers can whip up a very high quality record in no time
> flat. They've mental muscle memory for cataloguing. And we have them. >:)
> Why can't a programme ask the questions that I have in my head in a
> series and formulate a MARC record from it? Why can't it show me what
> the verso is in the process? Why aren't we leveraging linking when
> there's a world wide web?
> This is the hardest part since no one's tried doing it before that I
> know of.
>
>
> >Anyways, if anyone has strong views one way or the other let me know.
> >I'm a bit biased against the current MARC interface - we get people
> >being intimidated by it (me included :-) but I'm prepared to work
> >through it.
> >
>
> I think that's from too much text and boxes on the page, plus all of
> those tabs, like my long winded emails. You're not alone in being
> intimidated. I wasn't but I know a bunch of people that saw that and
> said "You're joking! That's a lot of fields!"
>
> Cheers,
> Brooke
> ------------------------------------------------------------------------
>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jransom.vcf
Type: text/x-vcard
Size: 290 bytes
Desc: not available
Url : http://lists.katipo.co.nz/pipermail/koha/attachments/20081219/3e1b553f/attachment.vcf
More information about the Koha
mailing list