- A social networking site where the society members are libraries, not individuals.
- The ability to capture copy cataloging from other libraries or create cataloging on the site itself.
- Full Unicode support, both for the interface and for the data.
- The ability to capture and create records using a MARC-compatible format.
- The ability to export the library catalog records in MARC format.
- A reports function that could print off the results of searches or even the library's inventory, so it could be used off-line.
- The creation of groups of "library friends," that is other libraries whose data should be included in searches and displays. This will facilitate sharing and also will serve users in areas where resources are scarce and scattered.
- A search and display interface that looks like a modern library catalog
- It all has to be easy to use with no training required, and not require any technical support on the part of the library.
There are many people encouraging libraries to use Open Source systems like Koha, but the libraries I'm talking about here have no capability to run software, much less Unix-based software. They may have only one computer, and it has to be used for everything: Internet access, office applications like document creation, and, if they have the capability, the library catalog. For those that do have at least part-time Internet access, the ideal system would be run online, with no technical requirements on the library's part.
The MARC requirement is an important one. The system does not need to support the full MARC record, but support for a standard minimum record means that the libraries can use each other's data for copy cataloging, and that some time in the future they may be able to contribute their records to library systems or to regional union catalogs. The ability to form networks between libraries is essential to overcome the incredible scarcity that exists for people living in rural and under-developed areas.
We already have many of the parts of this system, and I'm confident that the technology is no problem. We need the organization and the sustainability. Please send along any suggestions you have for how we can get this done.
If they really have a working net connection, then Koha is fine, with Libraries as branches, hosted on some donated/used hardware, running in their national library or in a middle-sized library.
ReplyDeleteNo, what I'm saying is that even the national library has no means to run Koha, and it's the largest library around. I talked to one techie at the American University, which is the most advanced (by our standards) and they did not have experience with Linux. I've tried installing Koha (with my minimal unix skills) and have failed, so I cannot recommend it as a solution for anyone with limited expertise. I did send them a Koha link and hope that they will experiment with it, but a real solution must be much, much simpler for all involved.
ReplyDeleteI see... Then finding the right person (IT student, ...?) there, is the most important thing, not another new software. Maybe LibraryThing will be enought at the beginning. Maybe Tim Spalding will donate a few accounts to them.
ReplyDeleteThere are two reasons why LT isn't appropriate (well, probably more, but at least these two): 1) it is based around persons, not institutions. The libraries will not be interested to know that Joe Blow has this book. They need to know what other geographically or socially close libraries have the book, because they are trying to get resources into the hands of their users. 2) LT does not store nor output something that can be turned into a valid MARC record. I've struggled with this with the Open Library as well; storing fields and subfields rather than simple triples complicates your database design. Unfortunately, bib data *is* complex and we're going to have to find a way to make that palatable to folks who aren't used to working with this kind of data.
ReplyDeleteI've been thinking the same kind of thing for a while but personally do not have the skills to build one. I was just looking at Koha again yesterday, wondering if I could use it to get my cataloging students some basic experience with an ILS, but I don't want to set up a server and all of that. It seems like that is beyond the financial and technical means of many small libraries and other people/organizations that could use a basic catalog. For a smallish collection, really, all one should need is a computer, basic web and cataloging skills, and an internet connection. Sadly, I've got no programming expertise to offer, but I am very keen on this idea and if there is anything I can do to help out, lemme know. I'll also ask around--this could be a project ibiblio might be interested in being involved with and I've been working with them for a while.
ReplyDeleteWe can think of a (small) library as a person, and the other library as another. What's the difference on this level? Books on shelves. LT's export format can be converted to simple MARC. With a good union catalog (I'm working on one...), author+title+year is enough to identify the document and supply a "real MARC" record from another library. The problem is not the "MARC or not MARC" but how someone uses a tool. MARC-editor fields can also be misused.
ReplyDeletePS.: ...but Joe Blow will be interested if the library has that book. We drifted away from thir problem a little.
Any of the web based ILS systems such as Koha only need one server based anywhere in the world and one person based anywhere to set up the system and provide some occasional administration at a minimum. All communication with the server can be remote so the person setting up and administering the system does not need to be located in the same place. The person initially setting up the ILS should have experience setting up the particular ILS system used.
ReplyDeleteAs an example, in the case of LibLime's Koha administration services, many different unrelated libraries are administered remotely by LibLime using different directories and different instances of Koha on a single server. Separate servers are only needed when total usage of the server exceeds the capacity of one server, but that would not be the case for the libraries you have described. Koha can accommodate a hierarchy of strongly or weakly related member libraries using a common set of Koha preferences. Of course, different preferences may be used by different instances of Koha and the catalogues of multiple instances can be contributed to a common union catalogue instance.
There are also free software and inexpensive ILS systems which are designed for running on MS Windows or have particular packaged versions for running on Windows. In the case of Koha, Windows versions do not have the full attention of the larger Koha community and suffer accordingly. Furthermore, the skills for administering any ILS system server remotely would be more likely to be found in the Unix based community than the MS Windows based community.
I favour free software systems which can be freely modified and shared over non-free software at any price. My particular knowledge of Koha comes from working with Koha and contributing to its development in recent years.
I'm not sure if I understand all the facets of your problem, but I'll stick my neck out anyway. I'm wondering if libraryworld.net could be a solution. There is an annual fee and a limit of space, but it's supposed to be great for small libraries. I'm not sure about the sharing of resources, but you might want to check it out. www.libraryworld.net
ReplyDeleteJackie
Thomas, I wonder if Koha is easy enough to use (and would wonder less if I could get it running...). Essentially, people will need to log on and create their own accounts, like MySpace or LibraryThing. I suspect that Koha will need an accounts administrator. And does Koha allow you to create "consortia" -- that is to create a "library friends" group that is searched with your library?
ReplyDeleteI really do mean that the system has to be as easy to use as a social networking site designed for people with no training. The cataloger interface in Koha is much too complex. (Compare it to LibraryThing's input form.) Remember, these will be people who have never heard of MARC, have had no training in cataloging. Actually, they've had no training in librarianship.
It's a very different world out there than the one we take for granted.
Jackie, I'll look at LibraryWorld, but I suspect it works like a regular library catalog, and I am aiming at something different to that. However, I thank you because it is nice to know that this kind of solution exists for small libraries here in the US.
1. COMPLEXITY OF KOHA SETUP.
ReplyDeleteThe current default installation of Koha is aimed at supporting some rather complex library standards including full MARC standards. (Automation assistance for cataloguing some elements and record types is less complete than it would be with a little more support for development.) While Koha does provide web based administration interfaces for changing the defaults to suit the needs of a particular library, the assistance of someone experienced at customising Koha is essential for efficiently making large wholesale changes for simplification or other significant customisation.
Any need for experienced assistance may seem overly burdensome. However, the experienced assistance is only really needed at the point of initial set up when significant changes from the defaults are required or migrating data from a previous system. Customisations thought to be widely applied by others are added to the code base for sharing, although, they can certainly be shared independently from the code base.
1.1. DOCUMENTATION.
Good documentation is essential for installing and setting up Koha. As with many free software projects lacking the financial backing of any well endowed interests, Koha documentation has often been neglected. Yet, there is much more good documentation for Koha than most similarly situated projects. The version about to be released should also not have any empty contextual help files.
Stephen Hedges had done an excellent work on the Koha Documentation Site but he changed jobs and no longer had time to maintain it. Stephen's own Koha 2.2 Users Guide is very careful. although, it was left unfinished after his job change and has become somewhat out of date. (I never even submitted the corrections and substantial expansion of my own data migration documentation.) Sadly, somewhat out of date documentation seems to be a virtual requirement of free software projects. Completing and updating the Koha 2.2 Users Guide has been discussed but never funded.
The Koha Developer Wiki has some more current documentation including documentation for installation and migration to Koha 3.0.
1.2. COMPLEXITY OF MARC CATALOGUING DEFAULTS.
A significant focus of your attention is the complexity of the cataloguing interface.
1.2.1. DISTINGUISHING TERMS.
Coded forms: Coded labels do not display the meaning of fields, subfields, indicators, or coded values.
Semantic forms: Natural language labels display the meaning of fields, subfields, indicators, and coded values.
Free form entry: Entries are created by unaided typing.
Guided entry. Entries are selected from a list of valid values.
Automated entry: Entries are copied or calculated from other already specified entries.
1.2.2. EASE OF CHANGES.
The MARC bibliographic frameworks which control the guided semantic forms based MARC record editor and MARC display in the OPAC can be modified to work with an arbitrarily simple subset of MARC. The complexity of MARC can be reduced to the simplicity of Dubln Core or Library Thing record formats if actually desired. As the main editor of the Koha English MARC bibliographic frameworks, I can use regular expressions in very short order to modify an enormous file of SQL statements created to serve the needs of one Koha library and adapt the file or others like it to serve the needs of any other to whatever degree of complexity or simplicity is desired. Editing a file of SQL statements directly avoids the tedium of many many iterations of the web form administration interface for a large number of frameworks changes. The 'Simple Frameworks' are an example of frameworks which are used to create a record editor web page which is relatively complex when compared to Library Thing but could be altered to provide a comparably simple record editor.
Some further distinctions of Koha cataloguing are provided below with a modest explanation of why defaults of the guided semantic forms based record editor are more complex than they ought to be.
2. INSTALLATION DIFFICULTIES.
I do not know what version of Koha you attempted to install or when that was. Unless you chose a development version with a broken installation script you should have been able to install Koha with some modest effort and persistence.
Basic command line system administration skills for installing Perl modules, installing and setting up a webserver, etc. are presumed for installing Koha. Detailed instruction in the needed system administration tasks has mostly been considered outside the scope of Koha documentation.
There are currently no complete Koha packages for particular operating system distributions which would manage all the dependencies. The Perl module dependencies. webserver, any Index Data software dependencies.will not be installed by the Koha installation script.
The ease of installing Koha 3.0 from the Koha git code development repository has improved greatly in the past few months. Those changes may not have been added to the more easily accessed beta installation archive file.
3. USER ACCOUNTS.
Varying permissions may be set to create a hierarchy of account privileges . The basic design presumption is that a librarian administrator creates privileges for non-administrative librarians. Librarians with the appropriate permissions create patron privileges.
Some Koha libraries may allow patrons to create their own accounts like social networking websites do but there is no standard form for doing that to my knowledge. Such a form might be created if desired without exposing an immediate security risk for the permission level required.
Circulation and user account management may be the most regularly active areas of development attention but they do not hold especially high interest for me personally so I am not aware of feature developments relating to those areas to the same degree that I am of others.
4. CONSORTIA.
In my previous post, I tried to emphasise the flexibility of the relation between different libraries and branches for Koha such as may be found in the consortia model. The one significant limitation to having an entire consortia using a single instance of Koha with individual collections appropriately distinguished but searchable in the OPAC is the need for the entire consortia to agree on how to set the global preferences. Lack of agreement of consortia members on global settings might entail setting up a union catalogue for the consortia to be searched in the OPAC. Agreeing on the global preferences would be simpler.
The library hierarchy system is sufficiently flexible to allow separate collections or other types of distinctions for material in a single library to be distinguished as virtual branches of a particular physical library or branch. The documentation for various scenarios is limited to none and some of the features which have been created for supporting needs of particular consortia have not been properly regularised enough to be fully exposed for administration in the web interface. However, most of the possibilities can be imagined from a little knowledge of the holdings model and branch management feature which is documented.
My unpublished revised text about holdings migration treats some of these questions but offers an unorthodox recommendation for how to overcome a circulation management and holdings issue of MARC based Koha 2.X using virtual libraries.
5. CATALOGUING.
5.1. CATALOGUER AND USER PROFICIENCY.
I have a modest and briefly stated challenge to the degree to which you express what I take to be a presumption about the level of work many libraries may be able to create in the described situation before going on to show how easy it is to have what you assert would be preferred. I would agree with your presumption if the people doing the work are absolutely unable to find either the motivation or time to do otherwise.
I have worked with cataloguers lacking any previous professional level experience of cataloguing or library science or any training towards such experience. I am not persuaded that the consequence for people lacking such experience is that they would necessarily not come to learn, value, and apply a subset of cataloguing standards which is most important for information finding precision. Some recurring guidance, local exemplary practise, and encouragement is often needed for good practises to be maintained when the cataloguing background is lacking. Available cataloguing time is a limiting factor but fantastic time efficiencies could be achieved with much better automation to support parts of the cataloguing task than any cataloguing tools currently provide.
[I could explain at length how it would be possible to use automation to optimise the cataloguing process but this text is already too long. The development time required for such a system would be very high but the revolution in cataloguing which would be possible would be much more than worth the original effort.]
I have tried to encourage cataloguers who lack a sufficient background in cataloguing theory and practise to consider the long term benefits of creating sufficiently complete original cataloguing records when copy cataloguing from an adequate source record is not possible. If copy cataloguing from an adequate source can be done, then a stable unique identifier captured for the source record can be used to automatically merge data for maximise value of even the most primitive local record. Maximal interoperability of records is needed for effective record sharing outside of local systems. Coded fields are important for maximising the elements available for indexing but they have usually been neglected in the OPAC.
Using seldom indexed record elements to limit the scope of OPAC queries may provide unneeded precision when searching within a very small collection. However, when the records from individual small collections are aggregated into larger union catalogues the precision becomes invaluable to avoid result sets with an excessive number of irrelevant results.
Reliable record element matching for deduplication, FRBRisation, etc. can be difficult enough with fairly complete MARC records. Normalising a few human paresable record elements can work but greater reliability can be achieved to the degree to which appropriate human and machine readable elements are present in the records. The lack of standards or authority controlled guidance in much of the book trade data and user contributed data in the Library Thing database, for example, poses an enormous obstacle to maximising the value of that database. More machine readable records may be better than fewer, yet I hope the content of the records or linked records is sufficient to maximise their value wherever it can be made reasonable practical to provide or create such content.
The failure of current OPACs to index particular useful elements or provide a sufficiently accessible interface for constructing queries which include such elements is not in itself a sufficient reason to prevent the possibility in future by not cataloguing such elements. Nor should current OPACs failure to display the meaning of some record element be used as a reason to prevent such a future possibility. We should no longer tolerate the absence of cataloguing tools and OPAC interfaces which do not guide every level of user to efficiently create data and use precision in information finding when needed. My presumption is that the lack of good automation support which constrains what both non-professional and professionals are able to accomplish and not primarily the skill set of those creating data or constructing queries.
People failing to find proper motivation will do a poor job of cataloguing no matter how simple the format is. Even a record format with nothing more than a single element title field would too often be entered inaccurately when motivation is lacking.
5.2. DIFFERING LEVELS OF SIMPLICITY AND COMPLEXITY IN KOHA RECORD EDITORS.
Koha cataloguing tools are far from exemplifying the possible efficiencies which I described above. Yet, they include some truly innovative features for adding guided and automated entries for some parts of the cataloguing task which Paul Poulain developed, in addition to the simpler list boxes previously present in the record editor. The cataloguing tools also provide different interfaces for supporting different levels of cataloguing experience, and are readily modifiable and extendible.
5.2.1. SUBTLE FEATURE SIGNIFICATION,
The guided entry feature of the semantics forms based record editor have actuation points which are much too subtly signified by coloured ellipsis [...] in the interface. Automated entries require setting some preference values and entering the fields or subfields by tabbing or clicking through the form element. Such subtle signification allows such entry features to be easily overlooked by people who have not been informed how to identify them. A couple of changes to the CSS and templates can make the entry features more prominent. However, keeping templates and CSS up to date with the latest improvements in the underlying features can be a fair amount of work. Therefore, the inclusion of template and CSS choices in Koha other than those of the main template and CSS developer have tended to decline over time. Persuading the main template developer of the importance of maintaining some desired changes may be much easier than maintaining that change in a separate set of templates.
The reason that guided and automated entry feature identification is not better signified is previous historical neglect of the cataloguing module in Koha and the choice of libraries requiring efficient large volume cataloguing to use external cataloguing tools.
Thankfully, the neglect of the cataloguing module has been changing with the introduction an additional cataloguing tool, Biblios.
The guided semantic forms based interface would need to be rewritten to support efficient high volume use for creating very complete records but there is no funding for that work. Yet, some changes to the templates and CSS could greatly improve user efficiency for rapid keyboard centric use and make it a very good choice for the simple level of records which you have described.
5.2.2. EXAMLES OF VARIATIONS IN SIMPLICITY AND COMPLEXITY.
5.2.2.1. ABBREVIATED DEVELOPENT HISTORY.
The original non-MARC semantic forms based Koha record editor from 2000 was extremely simple and had a close resemblance to the basic Dublin Core fields.
When the MARC interface was added in 2002, neither the default frameworks nor the underlying code allowed the creation of standard MARC records. In 2005, as the underlying record editor code was being corrected, I extended the MARC 21 bibliographic frameworks to allow minimal level cataloguing I did similar work on the authorities frameworks in 2007.
The Biblios coded forms based record editor has now been integrated in the Koha 3.0 development code. Guided entry in Biblios is currently much more limited than the guided semantic forms based record editor.
5.2.2.2. DESIGN CONSTRAINTS.
5.2.2.2.1. GUIDED SEMANTIC FORMS BASED RECORD EDITOR.
Despite significant weaknesses in the design for the guided semantic forms based record editor, the great features outweigh the weakness except in the context of efficient high volume cataloguing.
The data for building the record editor web page in the client web browser is transmitted from the server only once for each record. Any elements which might be included in the record must be included as part of the web page even if initially minimised.
This design constraint prohibits arbitrarily adding fields and subfields not specified in the framework for use by the record editor or already present in a pre-existing record being edited. Providing quick accessibility of any record elements which might be used in standard cataloguing for creating a particular record without overburdening the complexity of the web page is a very tricky problem. I worked with Joshua Ferraro on a flexible specification to control field and subfield inclusion, minimisation, and maximisation that would prevent the user interface from being overwhelmed by the full MARC standard but allow whatever is needed from existing records to be edited Paul Poulain's otherwise excellent highly innovative design was like most computer interfaces in the world, the design of a programmer who had no practical real world experience with the problem of efficiently performing the particular task involved.
Even minimised fields and subfields need to be accessible in the user interface. The more steps required to maximise the minimised elements for entering data when needed, the longer it takes to complete a record.
The default English MARC frameworks attempt to provide for minimal level cataloguing as best they can within the constraint.
Providing the full MARC standard in this manner has a totally unacceptable performance and network overhead burden. The underlying code for traversing the document object model and building the web page is very brittle. The record editor would need to be completely rewritten for full MARC cataloguing to fix this and other problems.
If access to nothing more than an especially small number of record elements is all that is required, as you describe ; then this design constraint does not pose a great problem and other deficiencies may not be seen.
5.2.2.2.2. BIBLIOS RECORD EDITOR.
High network overhead to download the record editing program is only required at the beginning of a Biblios record editing session. The network overhead may only be a significant issue in places where libraries do not have access to high bandwidth connections.
Any arbitrary record elements can be added making full national level MARC cataloguing practical. The coded forms based interface may be problematic for people new to cataloguing but experienced cataloguers may find it very efficient.
5.2.2.3. DEMONSTRATIONS.
Use the login username and password provided in the prompt for the public demonstrations or the one given near the link provided in this message. The links provided below are links into parts of the administration interface not the OPAC.
Demonstrations should not be presumed to be updated to the current version of the code for the particular version demonstrated.
Records in the demonstrations conform to the particular practises of the libraries which contributed them and may not be standards compliant.
Fonts specified in the CSS may show multiple single byte glyphs instead of the correct glyphs for multibyte characters on your particular client system. This problem should have been solved long ago but has not had the simultaneous attention of enough testers to specify the best fonts or avoid specifying the problem fonts. This issue should not be a problem for clients using MS Windows.
Templates and CSS in the Koha 3.0 demonstrations are somewhat incomplete and fail to provide efficient keyboard centric access and ergonomic feedback to an especially high degree.
Other testers of the public demonstration system may change things significantly and may provide you with an unusual experience.
5.2.2.3.1. GUIDED SEMANTIC FORMS BASED RECORD EDITOR.
Use the drop down list box at the top of the page to change the framework for the Koha 3.0 guided semantic forms record editor.
The guided entry [...] links for fixed fields may only be set up for books. Adding other guided entry Perl scripts following the model of an existing script and specifying them in the frameworks requires only modest effort. Some possibilities for guided entry or automated entry scripts can be much more complex and require much more than modest effort.
Only the French 2.2 public demonstration is running any longer. The username is demo and the password is demo. I would not recommend using Koha 2.2 instead of 3.0 but the 2.2 demonstration shows some aspects missing from the 3.0 demonstration
A more finished set of templates and CSS are present than those in the 3.0 demonstration.
More importantly for your concern, the French demonstration uses a somewhat simpler set of frameworks than the English default frameworks. Remember that the frameworks can be as simple as you like and display the record editor on only one page if preferred.
The French demonstration also has the advantage of having a degree of authority control configured which can be used for guided entry. Remember to overlook the fact that the cataloguing records in the demonstration are not standards compliant. The authority records used are auto-generated from present catalogue records but that is not especially important for purposes of the demonstration.
An example of authority controlled guided entry can be seen in the record editor by clicking on the page tab 2 in the green list of page tabs, then the [...] link for UNIMARC subject field 606. A query window should pop up to allow searching against authorised values, and tracings, and references in authority records. A list of matching authority records are returned. Search for a content term known to be included in the authority records present such as 'communication'. Select the arrow next to the authorised form from a preferred authority record and the authorised form will be entered into the field along with the local system authority record identifier in the minimised local use subfield 9.
5.2.2.3.2. BIBLIOS RECORD EDITOR.
Google Gears must be installed in the web browser before using the Biblios record editor. The Biblios record editor functions independently of the Koha frameworks and can function independently of Koha itself.
Keyboard control of the interface currently has a few significant limitations.
5.2.2.4. SIMPLIFYING THE FRAMEWORKS.
Accomplishing your purpose of simplifying the guided semantic forms record editor can be accomplished most easily by using regular expressions to edit a frameworks file such as the 'Simple Frameworks' which I linked above.
The primary focus of attention for simplifying the frameworks, should be the values which control the appearance of fields and subfields. marc_subfield_structure.hidden uses the following value table which appears in the help file of the web administration interface for editing the frameworks. [In the table, intranet is the name Koha has used for the administrative interface. Collapsed (minimised) only has meaning for the record editor.]
# hidden : allows you to select from 19 possible visibility conditions, 17 of which are implemented. They are the following:
( ! means 'not visible' or in the case of Collapsed 'not Collapsed')
-9 => Future use
-8 => Flag
-7 => OPAC !Intranet !Editor Collapsed
-6 => OPAC Intranet !Editor !Collapsed
-5 => OPAC Intranet !Editor Collapsed
-4 => OPAC !Intranet !Editor !Collapsed
-3 => OPAC !Intranet Editor Collapsed
-2 => OPAC !Intranet Editor !Collapsed
-1 => OPAC Intranet Editor Collapsed
0 => OPAC Intranet Editor !Collapsed
1 => !OPAC Intranet Editor Collapsed
2 => !OPAC !Intranet Editor !Collapsed
3 => !OPAC !Intranet Editor Collapsed
4 => !OPAC Intranet Editor !Collapsed
5 => !OPAC !Intranet !Editor Collapsed
6 => !OPAC Intranet !Editor !Collapsed
7 => !OPAC Intranet !Editor Collapsed
8 => !OPAC !Intranet !Editor !Collapsed
9 => Future use
Reducing the number of record editor pages to as little as one can be accomplished by changing the values of marc_subfield_structure.hidden.tab .
While I tried to publicise easy to use scripts which I wrote with the intent of capturing modifications and adding more alternate Koha frameworks into the main code base, especially translations, and alternate format standards; no one has yet taken up my offer. Unfortunately, less effort would be required for me to create more frameworks for different format standards and languages myself than to encourage others to share what they had created.
Translating frameworks should not require editing the frameworks but there is no funding for creating a more flexible modular framework design or rewriting the guided semantic forms based record editor etc. to focus on efficiently creating any record. The Biblios record editor is the only alternative currently integrated in Koha.
6. DISINTEGRATING THE ILS.
As you have advocated yourself, I favour disintegrating the ILS. There may be a current trend in that direction. One should be able to mix and match the best functionality of major modules from the traditional ILS. In the case of Koha, a separate cataloguing program has been most frequently used with records imported in batches. I have my own code for external automated or manual capture and processing records for cataloguing which I have intended to port to Koha but have not had time.
Constraining oneself to a single prepackaged solution should not be necessary. Free software makes avoiding such constraints much easier.
OPALS-NA is an open source alternative which some small libraries overseas with Internet access may want to investigate. Many of their sites are hosted.
ReplyDeleteSee: http://www.opals-na.net
The company has already done a lot of work on union databases, particularly in their work with public and private schools in the State of New York. Bibliographic records are stored as XML MARC, allowing them to work with non-Roman alphabets. (They have been working with Hebrew language records for several years.) Z39.50 client and server are both part of the standard software package. The OPAC's bibliography features are especially strong.
OPALS' MARC cataloging data entry isn't particularly user-friendly for novices though it works quite well for downloaded records which need minimal editing. (I'd be interested in knowing how OPALS' MARC catalog compares with Koha's.)
Despite the complexities of good cataloging and correct use of MARC formats, I've seen some examples of special library sites using OPALS where their new catalog is working for them--yet it is obvious that the folks doing the data entry have little understanding of MARC. The records aren't of the quality we'd like to see in a union catalog, yet some of these small libraries' specialized titles might not be found anywhere else, or at least not in their area of the world.
For any small library--and especially for a library where staff have no experience with MARC records--locating z39.50 connections for sites with (a) good cataloging and (b) collections which mirror their holdings will be key in establishing a decent quality local database. Local staff in these small libraries are especially likely to need help from those of us in the field who can make use of our information resources and professional connections on their behalf.
PShufeldt,
ReplyDeleteThanks. That's an open source catalog I didn't know about.
It doesn't however meet my criteria. So I go back to the social network analogy and add: libraries need to discover it and use it without being part of any group or system. So you don't pre-define who can use it -- anyone can use it.
Also, the cataloging in your system uses MARC tags. MARC tags aren't terms in anyone's natural vocabulary. Look at how you fill in your user profile on Facebook: hobbies, religious beliefs, favorite foods... no training needed.
The edit pages on the Open Library are close to what I'd want, although I think for actual input you'd want the terms to be less terse because some of them aren't obvious.
http://openlibrary.org/b/OL6053246M?m=edit
The edit pages on Librarything are also easy to use and intuitive:
http://www.librarything.com/addnew.php
Nothing a normal human being wouldn't recognize. With no training.
Also note that anyone can essentially translate the Open Library into their own language, so one bilingual person can make the site available to everyone speaking that language.
And most of the libraries I'm thinking of will probably not be making much use of copy cataloging because what they have isn't easily available elsewhere. However, there is no reason why there couldn't be a search similar to the one done by LibraryThing to bring down target records.
http://www.librarything.com/organizations
ReplyDeleteWhat about just running your idea's by LibraryThing? They have a page where they describe their intent to move towards being more organization-friendly, so perhaps if you send in your suggestions it might just help shape their efforts somewhat and give them a new area to look into :) Worth a shot, maybe LibraryThing will do the work that needs to be done! :)