Integrated system By: The Free Encyclopedia

An integrated library system (ILS), also known as a library management system (LMS) is an enterprise resource planning system for alibrary, used to track items owned, orders made, bills paid, and patrons who have borrowed. An ILS usually comprises a relational database, software to interact with that database, and two graphical user interfaces (one for patrons, one for staff). Most ILSes separate software functions into discrete programs called modules, each of them integrated with a unified interface. Examples of modules might include:

• Acquisitions (ordering, receiving, and invoicing materials) • Cataloging (classifying and indexing materials) • Circulation (lending materials to patrons and receiving them back) • Serials (tracking magazine and newspaper holdings) • OPAC (public interface for users) Each patron and item has a unique ID in the database that allows the ILS to track its activity. Larger libraries use an ILS to order and acquire, receive and invoice, catalog, circulate, track and shelve materials. Smaller libraries, such as those in private homes or non-profit organizations (like churches or synagogues, for instance), often forgo the expense and maintenance required to run an ILS, and instead use a library computer system.

Cataloging:

Library catalog (or library catalogue) is a register of all bibliographic items found in a library or group of libraries, such as a network of libraries at several locations. A bibliographic item can be any information entity (e.g., books, computer files, graphics, realia, cartographic materials, etc.) that is considered library material (e.g., a single novel in an anthology), or a group of library materials (e.g., a trilogy), or linked from the catalog (e.g., a webpage) as far as it is relevant to the catalog and to the users (patrons) of the library. The card catalog was a familiar sight to library users for generations, but it has been effectively replaced by the online public access catalog (OPAC). Some still refer to the online catalog as a "card catalog". Some libraries with OPAC access still have card catalogs on site, but these are now strictly a secondary resource and are seldom updated. Many of the libraries that have retained their physical card catalog post a sign advising the last year that the card catalog was updated. Some libraries have eliminated their card catalog in favour of the OPAC for the purpose of saving space for other use, such as additional shelving.

Goal

Charles Ammi Cutter made the first explicit statement regarding the objectives of a bibliographic system in his Rules for a Printed Dictionary Catalog in 1876. According to Cutter, those objectives were 1. To enable a person to find a book of which either (Identifying objective)

• the author • the title • the subject • the category Is known. 2. To show what the library has (Collocating objective)

• by a given author • on a given subject • in a given kind of literature 3. To assist in the choice of a book (Evaluating objective)

• as to its edition (bibliographically) • as to its character (literary or topical) These objectives can still be recognized in more modern definitions formulated throughout the 20th century. 1960/61 Cutter's objectives were revised by Lubetzky and the Conference on Cataloging Principles (CCP) in Paris. The latest attempt to describe a library catalog's goals and functions was made in 1998 with Functional Requirements for Bibliographic Records (FRBR) which defines four user tasks: find, identify, select, and obtain. A catalog also serves as an inventory or bookkeeping of the library's contents. If an item (a book) is not found in the catalog, the user may continue her search at another library. Library thieves, who may be staff or regular visitors of the library, risk discovery if an item listed in the catalog is missing from the shelves. To reduce this risk, a thief may also steal the catalog card describing the item.

Catalog card:

Catalog card is an individual entry in a library catalog. The first cards used may have been French playing cards, which, in the 1700s, were blank on one side.[3] In the mid- 1800s, Natale Battezzati, an Italian publisher, developed a card system for booksellers in which cards represented authors, titles and subjects. Very shortly afterward, Melvil Dewey and other American librarians began to champion the card catalog because of its great expandability. One of the first acts of the newly formed American Library Association in 1876 was to set standards for the size of the cards used in American libraries, thus making their manufacture and the manufacture of cabinets, uniform. In a physical catalog the information about an each item is on a separate card, which is placed in order in the catalog drawer depending on the type of record. Here's an example of a catalog card, which would be filed alphabetically in the Author section:

Types

Traditionally, there are the following types of catalog:

• Author catalog: a formal catalog, sorted alphabetically according to the authors' or editors' names of the entries. • Title catalog: a formal catalog, sorted alphabetically according to the article of the entries. • Dictionary catalog: a catalog in which all entries (author, title, subject, series) are interfiled in a single alphabetical order. This was the primary form of card catalog in North American libraries just prior to the introduction of the computer-based catalog • Keyword catalog: a subject catalog, sorted alphabetically according to some system of keywords. • Mixed alphabetic catalog forms: sometimes, one finds a mixed author / title, or an author / title / keyword catalog. • Systematic catalog: a subject catalog, sorted according to some systematic subdivision of subjects. Also called a classified catalog. • Shelf list catalog: a formal catalog with entries sorted in the same order as bibliographic items are shelved. This catalog may also serve as the primary inventory for the library.

Serial (literature)

literature, a serial is a publishing format by which a single large work, most often a work of narrative fiction, is presented in contiguous (typically chronological) installments—also known as numbers, parts, or fascicles—either issued as separate publications or appearing in sequential issues of a single periodical publication.[1] More generally, serial is applied in library and information science to materials "in any medium issued under the same title in a succession of discrete parts, usually numbered (or dated) and appearing at regular or irregular intervals with no predetermined conclusion

OPAC

An online public access catalog (often abbreviated as OPAC or simply library catalog) is an online database of materials held by a library or group of libraries. Users search a library catalog principally to locate books and other material available at a library.

Library (computing) By: The Free Encyclopedia

Not to be confused with integrated library system.

In computer science, a library is a collection of non-volatile resources used by computer programs, often to develop software. These may include configuration data, documentation, help data, message templates, pre-written code and subroutines, classes, values or type specifications. In IBM's OS/360 and its successors they are referred to as partitioned data sets. In computer science, a library is a collection of implementations of behavior, written in terms of a language, that has a well-defined interface by which the behavior is invoked. This means that as long as a higher level program uses a library to make system calls, it does not need to be re-written to implement those system calls over and over again. In addition, the behavior is provided for reuse by multiple independent programs. A program invokes the library-provided behavior via a mechanism of the language. For example, in a simple imperative language such as C, the behavior in a library is invoked by using C's normal function-call. What distinguishes the call as being to a library, versus being to another function in the same program, is the way that the code is organized in the system. Library code is organized in such a way that it can be used by multiple programs that have no connection to each other, while code that is part of a program is organized to only be used within that one program. This distinction can gain a hierarchical notion when a program grows large, such as a multi-million-line program. In that case, there may be internal libraries that are reused by independent sub-portions of the large program. The distinguishing feature is that a library is organized for the purposes of being reused by independent programs or sub-programs, and the user only needs to know the interface, and not the internal details of the library. The value of a library is the reuse of the behavior. When a program invokes a library, it gains the behavior implemented inside that library without having to implement that behavior itself. Libraries encourage the sharing of code in a modular fashion, and ease the distribution of the code. The behavior implemented by a library can be connected to the invoking program at different program lifecycle phases. If the code of the library is accessed during the build of the invoking program, then the library is called a . An alternative is to build the of the invoking program and distribute that, independently from the library implementation. The library behavior is connected after the executable has been invoked to be executed, either as part of the process of starting the execution, or in the middle of execution. In this case the library is called a dynamic library. A dynamic library can be loaded and linked as part of preparing a program for execution, by the . Alternatively, in the middle of execution, an application may explicitly request that a module be loaded. Most compiled languages have a standard library although programmers can also create their own custom libraries. Most modern software systems provide libraries that implement the majority of system services. Such libraries have commoditized the services which a modern application requires. As such, most code used by modern applications is provided in these system libraries.

Linking

Libraries are important in the program linking or binding process, which resolves references known as links or symbols to library modules. The linking process is usually automatically done by a linker or binder program that searches a set of libraries and other modules in a given order. Usually it is not considered an error if a link target can be found multiple times in a given set of libraries. Linking may be done when an executable file is created, or whenever the program is used at run time. The references being resolved may be addresses for jumps and other routine calls. They may be in the main program, or in one module depending upon another. They are resolved into fixed or relocatable addresses (from a common base) by allocating runtime memory for thememory segments of each module referenced. Some programming languages may use a feature called smart linking wherein the linker is aware of or integrated with the , such that the linker knows how external references are used, and code in a library that is never actually used, even though internally referenced, can be discarded from the compiled application. For example, a program that only uses integers for arithmetic, or does no arithmetic operations at all, can exclude floating-point library routines. This smart-linking feature can lead to smaller application file sizes and reduced memory usage

Relocation

Some references in a program or library module are stored in a relative or symbolic form which cannot be resolved until all code and libraries are assigned final static addresses. is the process of adjusting these references, and is done either by the linker or the loader. In general, relocation cannot be done to individual libraries themselves because the addresses in memory may vary depending on the program using them and other libraries they are combined with. Position-independent code avoids references to absolute addresses and therefore does not require relocation

Static libraries

When linking is performed during the creation of an executable or another object file, it is known as static linking or early binding. In this case, the linking is usually done by a linker, but may also be done by the compiler. A static library, also known as an archive, is one intended to be statically linked. Originally, only static libraries existed. Static linking must be performed when any modules are recompiled. All of the modules required by a program are sometimes statically linked and copied into the executable file. This process, and the resulting stand-alone file, is known as a static build of the program. A static build may not need any further relocation if virtual memory is used and no address space layout randomization is desired.

Shared libraries

A shared library or shared object is a file that is intended to be shared by executable files and further shared objects files. Modules used by a program are loaded from individual shared objects into memory at load time or run time, rather than being copied by a linker when it creates a single monolithic executable file for the program. Shared libraries can be statically linked, meaning that references to the library modules are resolved and the modules are allocated memory when the executable file is created. But often linking of shared libraries is postponed until they are loaded.[dubious – discuss] Most modern operating systems[NB 2] can have shared library files of the same format as the executable files. This offers two main advantages: first, it requires making only one loader for both of them, rather than two (having the single loader is considered well worth its added complexity). Secondly, it allows the also to be used as shared libraries, if they have a symbol table. Typical combined executable and shared library formats are ELF and Mach-O (both in Unix) and PE (Windows). In some older environments such as 16-bit Windows or MPE for the HP 3000 only stack based data (local) was allowed in shared library code, or other significant restrictions were placed on shared library code.

Locating libraries at run time

Loaders for shared libraries vary widely in functionality. Some depend on the executable storing explicit paths to the libraries. Any change to the library naming or layout of the file system will cause these systems to fail. More commonly, only the name of the library (and not the path) is stored in the executable, with the supplying a method to find the library on-disk based on some algorithm. If a shared library that an executable depends on is deleted, moved, or renamed, or if an incompatible version of the library is copied to a place that is earlier in the search, the executable would fail to load. This is called Dependency hell existing on many platforms. The (infamous) Windows variant is commonly known as DLL hell. This problem cannot occur if each version of each library is uniquely identified and each program references libraries only by their full unique identifiers. The "DLL hell" problems with earlier Windows versions arose from using only the names of libraries, which were not guaranteed to be unique, to resolve dynamic links in programs. (To avoid "DLL hell", later versions of Windows rely largely on options for programs to install private DLLs—essentially a partial retreat from the use of shared libraries—along with mechanisms to prevent replacement of shared system DLLs with earlier versions of them.)

Object and class libraries

Although originally pioneered in the 1960s, dynamic linking did not reach operating systems used by consumers until the late 1980s. It was generally available in some form in most operating systems by the early 1990s. During this same period, object-oriented programming (OOP) was becoming a significant part of the programming landscape. OOP with runtime binding requires additional information that traditional libraries don't supply. In addition to the names and entry points of the code located within, they also require a list of the objects on which they depend. This is a side-effect of one of OOP's main advantages, inheritance, which means that parts of the complete definition of any method may be in different places. This is more than simply listing that one library requires the services of another: in a true OOP system, the libraries themselves may not be known at , and vary from system to system. At the same time many developers worked on the idea of multi-tier programs, in which a "display" running on a desktop computer would use the services of a mainframe or minicomputer for data storage or processing. For instance, a program on a GUI-based computer would send messages to a minicomputer to return small samples of a huge dataset for display. Remote procedure calls already handled these tasks, but there was no standard RPC system. Soon the majority of the minicomputer and mainframe vendors instigated projects to combine the two, producing an OOP library format that could be used anywhere. Such systems were known as object libraries, or distributed objects, if they supported remote access (not all did). Microsoft's COM is an example of such a system for local use, DCOM a modified version that supports remote access. For some time object libraries held the status of the "next big thing" in the programming world. There were a number of efforts to create systems that would run across platforms, and companies competed to try to get developers locked into their own system. Examples include IBM's System Object Model (SOM/DSOM), Sun Microsystems' Distributed Objects Everywhere (DOE), NeXT's Portable Distributed Objects (PDO), Digital's Object Broker, Microsoft's Component Object Model (COM/DCOM), and any number of CORBA-based systems. After the inevitable cooling of marketing hype, object libraries continue to be used in both object-oriented programming and distributed information systems. Class libraries are the rough OOP equivalent of older types of code libraries. They contain classes, which describe characteristics and define actions (methods) that involve objects. Class libraries are used to create instances, or objects with their characteristics set to specific values. In some OOP languages, like Java, the distinction is clear, with the classes often contained in library files (like Java's JAR file format) and the instantiated objects residing only in memory (although potentially able to be made persistent in separate files). In others, likeSmalltalk, the class libraries are merely the starting point for a system image that includes the entire state of the environment, classes and all instantiated objects

Remote libraries

Another solution to the library issue comes from using completely separate executables (often in some lightweight form) and calling them using aremote procedure call (RPC) over a network to another computer. This approach maximizes operating system re-use: the code needed to support the library is the same code being used to provide application support and security for every other program. Additionally, such systems do not require the library to exist on the same machine, but can forward the requests over the network. However, such an approach means that every library call requires a considerable amount of overhead. RPC calls are much more expensive than calling a shared library that has already been loaded on the same machine. This approach is commonly used in a distributed architecture that makes heavy use of such remote calls, notably client-server systems and application servers such as Enterprise JavaBeans.

Horizon “Library Automation Software” By: DYNIX

Horizon is a comprehensive library automation system developed and supported by Dynix (www.dynix.com). As a client/server system, Horizon lets you use client software to log in to a Horizon server, which hosts a database of your library’s records.

Your library can use the Horizon software to do a wide variety of tasks. For example, your library can:

*Maintain an online catalog of books, periodicals, and media items. *Keep track of the items borrowed from your library and the people who have borrowed them, as well as due dates and fines due. * Process information about the new items your library buys.

As a library staff user, you can log in to Horizon from any Microsoft Windowsbased PC where your system administrator has installed the Horizon client software. Once you log in, you can do your regular library tasks using the Horizon processes that you have security rights to access, or using the records for which you have ownership right

Horizon Processes:

The Horizon system consists of different features called “processes.” Each process lets your library staff do a certain type of library task. To help your library’s workflow, the default Horizon installation organizes the processes into categories (sometimes called “modules”). Each category has its own folder on the Launcher navigation bar. (For more information, see “Overview of the Launcher” on page 2-4.) Your system administrator determines which folders and processes you have access to in your Horizon environment. Horizon includes these main categories of processes:

• Cataloging. Let’s your library set up and maintain a library catalog. Horizon catalogs both MARC and non-MARC records. • Circulation. Let’s your library check items in and out. Circulation also lets you and track information about “borrowers” (the individuals who check out items from your library). (For example, for each borrower you can keep track of contact information, the items checked out, overdue fines, and hold requests.) • Acquisitions. Helps you acquire items for your library. You can create, track, and process purchase orders and maintain accurate purchasing records. You can customize Acquisitions to fit your library’s accounting system • Serials. Let’s you manage periodical subscriptions (magazines, newspapers, and journals). You can process newly arrived periodicals, predict receiving dates for future issues, and generate claims to vendors for late issues. Serials also lets you route specific copies to different people and departments. If your library chooses to bind serials issues together, your library may also use Serials Binding, which helps your library organize serials issues for shipment to the company who does the binding. • Administration. Let’s your library’s system administrator set up and maintain your library’s Horizon database and security

Horizon Security

Your Horizon system administrator manages the security for your library’s Horizon system. You can access a Horizon process only if your system administrator has granted your user ID the rights to access that process. Some processes or menu options that you do have access to may be protected by a password. While you are working in Horizon,

About the Horizon User Interface

The Horizon user interface is similar to the interface of other applications that run on a Microsoft Windows operating system. However, the Horizon interface has many features that are unique to Horizon. This chapter gives an overview of those unique Horizon features. It also helps you to understand how some standard Microsoft Windows features work within the Horizon interface. The basic framework of the Horizon interface is called “the Launcher.” The Launcher lets you open (or “launch”) the various processes that you use in Horizon, and navigate between those processes. It also lets you customize some areas of your Horizon interface. Once a process is open, you can work in various types of Horizon process windows. These windows let you view and edit information that is stored in your library’s database. For most processes, you view information in a “list” window, and then edit in an “edit” window. For a few processes, you work in a “grids and forms” interface that lets you complete records more quickly and use tools that help your data-entry efficiency. The windows that display depend on what process you are using and where that process fits in your library's workflow. Horizon also lets you use shortcuts and right-click menus to quickly access features and options.

Using Keyword Browse in Unicode

Unicode lets Horizon display international characters. When you do a keyword browse search to find a bib record, Horizon properly sorts and sequences the international characters in the list based on the index you choose. (For example, if you choose the Cyrillic index, Horizon sorts the entries according to Russian sorting rules

If the characters are romanized, western European sorting rules apply. If the characters remain in their native language, you choose the index for that language. The sorting rules for that language apply to the sorting and sequencing throughout Horizon To use keyword browse in Unicode, do a standard search, but choose the index that has been set up for the language you want to use.

Alphabetical Searching

Alphabetical searches show a list of all the records at your library in alphabetical order. If your main library branch shares items with other branches, an alphabetical search shows a list of items from all branches. An alphabetical search is useful for finding a title or authority record that begins with a certain word. It can also help you find records that are difficult to locate using a keyword search because of the large number of matches a keyword search can generate. You can enter all or the first part of a search term. (For example, enter “mar” or “marriage”.) During an alphabetical search, the system ignores initial articles such as “a,” “an,” and “the.” If you are searching for a heading that begins with an article, it is not necessary to enter the article. (For example, if you are searching for the series A Touchstone Book, enter “Touchstone Book”.) When you do an alphabetical search, Horizon displays a browse list of records that match your search. The selector arrow points to the title that most closely matches the spelling of your search term.