[Koha] Adding a field to an existing record
We're using Koha version 3.16.04.000. Sometimes we want to edit a MARC record in Koha and add a field that is not already in the record - for example, a 910 field. The 910 field is listed in the framework set up for that record type, but when we go to the editing interface the field is not present. How can we make sure a field that is in a framework is available for editing? It's not a mandatory field, and we don't wish to make it one. There are various empty fields available, but this particular one is not. What controls the presence or absence of a particular field in Koha's record editing module? (I know we can add this field prior to importing it into the catalog. This is for those occasions when we want to add it after import.) Stacy -- Stacy Pober Information Alchemist Manhattan College Library Riverdale, NY 10471 stacy.po...@manhattan.edu ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Adding a field to an existing record
Worked like a charm. Thanks so much! Stacy Date: Thu, 13 Nov 2014 13:49:35 +1300 From: Liz Rea l...@catalyst.net.nz To: koha@lists.katipo.co.nz Subject: Re: [Koha] Adding a field to an existing record Message-ID: 5464001f.4060...@catalyst.net.nz Content-Type: text/plain; charset=windows-1252 Hi Stacy, Try this: Go to More - Administration - MARC Bibliographic Framework Click MARC Structure next to the framework you'd like to edit Search for 910 in the Search for Tag box Click Subfields next to the 910 Click Edit next to subfield a (or whichever subfield you are wanting to show in the editor) Click Advanced constraints Tick the box for editor Click Save Cheers, Liz On 13/11/14 13:15, Stacy Pober wrote: We're using Koha version 3.16.04.000. Sometimes we want to edit a MARC record in Koha and add a field that is not already in the record - for example, a 910 field. The 910 field is listed in the framework set up for that record type, but when we go to the editing interface the field is not present. How can we make sure a field that is in a framework is available for editing? It's not a mandatory field, and we don't wish to make it one. There are various empty fields available, but this particular one is not. What controls the presence or absence of a particular field in Koha's record editing module? (I know we can add this field prior to importing it into the catalog. This is for those occasions when we want to add it after import.) Stacy -- -- Liz Rea Catalyst.Net Limited Level 6, Catalyst House, 150 Willis Street, Wellington. P.O Box 11053, Manners Street, Wellington 6142 GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7 -- Stacy Pober Information Alchemist Manhattan College Library Riverdale, NY 10471 stacy.po...@manhattan.edu ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha Digest, Vol 86, Issue 38
Haik, I think you are trying to make one 856 do more than it was intended to do. The Library of Congress MARC guidelines say this about $u subfields: *Subfield $u (URI) repeatability.* Subfield $u may be repeated only if both a URN and a URL or more than one URN are recorded. Field 856 is repeated if more than one URL needs to be recorded. Some institutions may wish to record a persistent name (URN) as well as a resolvable HTTP URL in field 856. http://www.loc.gov/marc/856guide.html#subfield_$u So, unless you are using a different form of MARC (and I realize that this is an international list, so this may be the case) you should not put more than one URL per 856 instance. You can have a second $u field only if there is a URN in that field. Since most URNs are not clickable, it makes sense that OPACs generally display only the first $u, which contains the URL. In short, multiple URLs would require multiple 856 fields. The usual construction of an 856 field that links to the resource itself is: =856 40$3[materials specified - optional]$u[url]$y[link text -optional]$z[public note - optional] In practice, most records have either a $y or a $z, though you can have both of those in one 856. Both $y and $z show up in Koha as link text. The only required subfield in an 856 is the $u. You need not have any other text, and if you don't put in a $y or $z, Koha will supply a default link text. An example of a typical 856 would be: =856 40$3Ebrary$uhttp://ebrary.com/somebook$yAn online ebook. Click here for access. It sounds as if you may have constructed your 856 fields this way: =85640$[URL1]$y[Link text 1]$uURL2$y[Link text 2]$uURL3$y[Link text 3] You need to edit these to change them into multiple 856 fields, each with only one $u and one $y: =856 40$u[URL1]$y[Link text1] =856 40$u[URL2]$y[Link text2] etc. Hope this helps. -- Stacy Pober Information Alchemist Manhattan College Library Riverdale, NY 10471 stacy.po...@manhattan.edu Date: Sun, 23 Dec 2012 21:59:41 -0800 (PST) From: Haik Zargaryan haikzargar...@yahoo.com To: koha@lists.katipo.co.nz koha@lists.katipo.co.nz Subject: [Koha] cloning 856 $u Message-ID: 1356328781.45563.yahoomail...@web163803.mail.gq1.yahoo.com Content-Type: text/plain; charset=iso-8859-1 Dear friends, We want to attach several URLs to the MARC record. Since the 856 $u field is repeatable, we have decided to clone the?subfield?several times. Yet, when we search for the record in the OPAC, only the first link is displayed in the results' page, meanwhile the other ones are not visible at all.? We have a similar problem with the 856 $y field as well. All subfields are?concatenated in one field and are displayed as a one text.? We want to have all links?each?one?with its appropriate text value, and of course, displayed separately. Is it possible? Thank you in advance, Haik. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Solr
Does anyone know if switching from Zebra to Solr will let Koha libraries use a stopwords list? Also, will Solr have any effect on fuzzy searching defaults? Lastly, is there anyone sponsoring or working on a did you mean... opac response to zero retrieval searches? At our library, we'd probably choose a did you mean... spelling suggestion choice over the automatic fuzzy spelling assumptions that are currently in the system. I realize this would probably be listed in bugzilla, but I'm not sure exactly how to search for this. -- Stacy Pober Information Alchemist Manhattan College Library Riverdale, NY 10471 stacy.po...@manhattan.edu ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha Digest, Vol 80, Issue 38
How is it that no one has added this kind of searching to the community version of Koha? It's a major omission. People are so used to using quote marks and those operators in search strings that they often try to use them in Koha even though they don't work as expected. One of the features in an easy to use OPAC is that the searching conforms to expected norms that the public knows from other common search interfaces. This feature was commissioned from the vendor our library uses, PTFS, but it doesn't work properly. (It kind of works, but if you turn this feature on, the boolean searching in Advanced Search stops working correctly. As a result, many of the libraries that have it as an option don't use it.) I'm astonished that no one in the world has added properly working code that would make the most widely understood phrase searching method (quotation marks) available in community Koha. As for the + and - operators, if anyone tries adding that, they have to code it as a two-character string (space+ or space-) to prevent confusion when users are looking for hyphenated words. Is anyone in the Koha-verse working on adding a search mode that uses quotation marks and + - operators? I mean, aside from the buggy version we have in Liblime's LAK. -- Stacy Pober Information Alchemist [speaking for myself, not representing any institution or group] Riverdale, NY 10471 stacy.po...@manhattan.edu On Mon, Jun 25, 2012 at 9:18 AM, koha-requ...@lists.katipo.co.nz wrote: From: Robin Sheat ro...@catalyst.net.nz To: koha@lists.katipo.co.nz Subject: Re: [Koha] Spell-check/ Did you mean Message-ID: 4fe8322c.5050...@catalyst.net.nz Content-Type: text/plain; charset=UTF-8 Op 22-06-12 21:29, Paul schreef: Searching for nature defecit *with* the double quotes fails -- this I expect, as the quotes eliminate fuzziness. Searching for nature defecit (no quotes) works perfectly. Searching for nature-deficit (with quotes) fails; I am only semi-surprised as the logic of the - (minus sign) is to search for the phrase without the term after the minus. However +nature -deficit also finds that title alone and in my opinion should not (but my opinion is not definitive.) Koha doesn't understand phrase searching and +with -without operators by default. It's possible to construct queries that will, but in general it doesn't. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Excel to MARC - Marcedit 5.8
There's an excellent support list for MARCEDIT called MARCEDIT-L. Terry Reese, the author of the program monitors the list, and he will often offer solutions along with some of the other list subscribers. http://metis3.gmu.edu/cgi-bin/wa?A0=MARCEDIT-L It's also a good way to give input on features you'd like to see or to find out whether someone already has solved a particular problem you're having. Stacy On Mon, Jun 25, 2012 at 9:18 AM, koha-requ...@lists.katipo.co.nz wrote: As marcedit is proprietary software, unfortunately the only person who is likely to be able to help is the marcedit author, unless someone else has seen and solved it before. -- Stacy Pober Information Alchemist Riverdale, NY 10471 stacy.po...@manhattan.edu ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Computers in Libraries
Anyone going to this year's Computers in Libraries conference? -- Stacy Pober Information Alchemist Manhattan College Library Riverdale, NY 10471 stacy.po...@manhattan.edu ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha Digest, Vol 75, Issue 58
Sue McMillan wrote: Hi Anne, I don't believe there is a bulk biblio delete built into Koha. It certainly would be a good development though. Perhaps she's on one of the PTFS/Liblime versions of their Koha-based ILS? At least one of the Liblime sporks has a batch item deletion and editing tool. I have not found it to be very useful and instead do all the batch record editing with MarcEdit (free, though not open-source). When there are a large number of deletions, I use Undo Import if at all possible. I have wondered why the process of deleting records is so tedious in Koha generally. You cannot delete the biblio without first deleting the items attached, and that adds quite a few steps to the process. It's a lot of clicks and it's a slow process. One of our ebook vendors deleted a few thousand books last year from our subscription. The amount of staff time needed to go through all the steps of deleting those records was unreasonable, so we just suppressed the records in the OPAC. We would have preferred to delete the records entirely. In some library systems, they have a batch deletion method that allows you to delete records by batch uploading the MARC records with a deletion flag in one of the fields. Since our major ebook subscription vendor does provide MARC records when they delete books, it would be simple to change one field to have a deletion flag with MarcEdit and then upload those. It would certainly be quicker than thousands of iterations of the rather tedious individual delete item/delete biblio procedure. I'm just mentioning it here because you might want to consider incorporating something like that into Koha. There is no quick and easy delete method other than undo-ing entire batches in any version of Koha, as far as I know. If you are working on a tool that allows the deletion based on biblionumber or biblioitemnumber, consider including an interface that allows users to enter a range of continuous numbers, so you could specify deletion of record 132000-132600 or whatever, rather having to list each number individually. Having an input box that allowed thta kind of range of records would have made the Liblime tool much more useful, and would have provided an viable alternative to the batch undo method, which doesn't always work perfectly. As with the bulk edit/delet tool, there have been other features added to the proprietary Liblime version of Koha that sounded useful when planned, but turned out to either not have the functionality expected or else broke some other important feature when activated. For example, there is a simple search feature which was highly anticipated because it was supposed to offer a more user-friendly search syntax. The feature exists, but if you turn it on, Advanced Search no longer works properly. As a consequence, I don't think many libraries are using that feature. I've sometimes wondered whether the people active in software new feature development process need to explicitly include the phrase should not interfere with any existing functionality when they're writing specifications. It's kind of like the medical principle of First, do no harm. I think end-users assume this is implicit in their proposals but designers sometimes fail to preserve the full functionality of the program in the design process. . -- Stacy Pober Information Alchemist Riverdale, NY 10471 stacy.po...@manhattan.edu From: Sue McMillan sue.mcmil...@stdc.govt.nz Hi Anne, I don't believe there is a bulk biblio delete built into Koha. It certainly would be a good development though. Regards Susan McMillan Cataloguing and Systems Librarian| South Taranaki District Council 105-111 Albion St, Private Bag 902, Hawera 4610, NZ Phone: +64 6 278 0555 | www.southtaranaki.com ? -Original Message- From: koha-boun...@lists.katipo.co.nz [mailto:koha-boun...@lists.katipo.co.nz] On Behalf Of library Sent: Friday, 27 January 2012 12:52 p.m. To: koha@lists.katipo.co.nz Subject: Re: [Koha] Biblio deletion When I try to import the file into the Batch Item Delete tool I get the following message. I'm not sure I have understood the function of the tool as it seems to be asking for a barcode not the biblio numbers that I am trying to load. Software error: Can't call method as_usmarc on an undefined value at /koha/lib/C4/Items.pm line 589. Regards Ann Murphy ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Fwd: Library Journal: Rate Your Satisfaction with Your ILS
-- Forwarded message -- From: David Rapp dr...@mediasourceinc.com Date: Wed, Jan 18, 2012 at 5:59 PM Subject: Library Journal: Rate Your Satisfaction with Your ILS Library Journal is conducting a snap survey to determine library and patron satisfaction with integrated library systems (ILS) in both public and academic libraries. Are you in charge of technology, collections, or reference at your library? We are eager to hear your thoughts about the systems that you and your patrons use every day. Please click on this link to take a very brief survey (which will only take a few minutes to answer): http://app.fluidsurveys.com/s/ILS/?link=listserv Results of this study will appear in an upcoming LJ article in Spring 2012. Thanks for supporting our research efforts! -- David Rapp Associate Editor, Technology Library Journal ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
