Builder ‐ the DIY guide

This article was downloaded by: [The University of Manchester Library]On: 17 October 2014, At: 06:35Publisher: RoutledgeInforma Ltd Registered in England and Wales Registered Number: 1072954Registered office: Mortimer House, 37-41 Mortimer Street, London W1T3JH, UK

New Review of AcademicLibrarianshipPublication details, including instructions forauthors and subscription information:http://www.tandfonline.com/loi/racl20

Builder ‐ the DIY guideIan Upton aa Technical Development Officer, BUILDER,Information Services , The University ofBirmingham , Main Library, Edgbaston, Birmingham,BI5 2TT, UK E-mail:Published online: 15 Oct 2009.

To cite this article: Ian Upton (1999) Builder ‐ the DIY guide, New Review ofAcademic Librarianship, 5:1, 41-59, DOI: 10.1080/13614539909516789

To link to this article: http://dx.doi.org/10.1080/13614539909516789

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all theinformation (the “Content”) contained in the publications on our platform.However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness,or suitability for any purpose of the Content. Any opinions and viewsexpressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of theContent should not be relied upon and should be independently verifiedwith primary sources of information. Taylor and Francis shall not be liablefor any losses, actions, claims, proceedings, demands, costs, expenses,damages, and other liabilities whatsoever or howsoever caused arisingdirectly or indirectly in connection with, in relation to or arising out of theuse of the Content.

This article may be used for research, teaching, and private study purposes.Any substantial or systematic reproduction, redistribution, reselling, loan,

http://www.tandfonline.com/loi/racl20

http://www.tandfonline.com/action/showCitFormats?doi=10.1080/13614539909516789

http://dx.doi.org/10.1080/13614539909516789

sub-licensing, systematic supply, or distribution in any form to anyone isexpressly forbidden. Terms & Conditions of access and use can be found athttp://www.tandfonline.com/page/terms-and-conditions

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

http://www.tandfonline.com/page/terms-and-conditions

BUILDER - The DIY GuideIan UptonTechnical Development Officer, BUILDER, Information Services,Main Library, The University of Birmingham, Edgbaston,Birmingham BI5 2TT, UKe-mail: [email protected]

So how practical is it to implement the hybrid Library? This 'nuts and bolts' paper looks at someof the technologies developed and used by BUILDER and how they can be implemented on yoursystems today. Topics covered are infrastructure, authentication, seamlessness and research enginetechnologies.

INTRODUCTION

This paper is not about what we have done but how we have doneit. Hopefully when you have read this paper you will feel youcan do it too!

Divided into four sections, the paper covers concepts, infrastructure andimplementation. The first section looks at concepts, the BUILDERvision of a hybrid library. The second section looks at infrastructure, akey element for realising the BUILDER hybrid library. The thirdsection provides three case studies, covering authentication, secure filedelivery and search engine technologies. The final section lists a range,of the BUILDER developed products with a focus on how the case-study methods have been applied.

CONCEPTSVision

The BUILDER vision of the hybrid library is simple. Imagine walkinginto your library today. If I imagine the Main Library at the Universityof Birmingham, I first enter by swiping my University ID card througha reader to let me through the barrier. Once in, I can wander around andaccess a range of services. There are terminals providing access to theLibrary Catalogue. I can take books from the shelves; I can search CDROMs. I can browse the World Wide Web. I have access to periodicals.

The New Review of Academic Librarianship 1999 41

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

To help me there are lots of signs and leaflets. If I am really stuck I cango and talk to someone at the Help Desk.

The BUILDER vision of the hybrid library seeks to reproduce thisexperience for anyone anywhere with an Internet connection and a webbrowser. Not only does it seek to reproduce this experience, in someways it hopes to improve the experience. For example, in the real worldthe user has to access a number of different terminals and interfaces toaccess electronic resources. In the BUILDER vision there would beonly one interface. In the real world, processes can take time as, forexample, paper forms are passed from person to person. In theBUILDER vision transactions would be instant. You request adocument and there it is - available to read on screen or to print out.

Of course realising this vision is an impossible task for a three-yearproject but what BUILDER has attempted to do is provide examplesand experiences. BUILDER hopes to provide little glimpses of what ispossible and what is needed to support such a service.

Iterative developmentsAt the beginning of the project BUILDER decided to adopt an iterativeapproach towards development. What do we mean by this?

One development approach is to sit down and create a detailedspecification for a product. The document is circulated and amendedand circulated and amended and circulated and amended until theproduct described meets everyone's needs. The actual product isdeveloped from the specification and released. The first release is thefirst point anyone actually sees a working entity. It is at this point wediscover if we got things right or wrong.

The BUILDER approach is different. Instead of trying to create theproduct first time, BUILDER quickly mocks something up. We wouldnot expect this mock up to meet everyone's needs but it would providesomething functioning that people could actually see. We would thentake feedback on this demonstrator and develop version two. We loopagain for version three and so on. This kind of iterative developmenthas enabled BUILDER to move quickly forward and, with constantfeedback, produce focused and useable product.

To be fair, BUILDER suits this kind of iterative development process. It

The New Review of Academic Librarianship 199942

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

comprises many small products wrapped up into a single entity. Clearlythis approach would not be suitable for many developments but itcertainly suited us. As well as enabling quick, focused, developments,actually being able to see and use a product is a great way to cut out thefrippery. The little things that are argued about for hours when writingmore formal specifications just disappear. Similarly those little thingsthat get taken for granted suddenly can take on a significance that couldnever be revealed in an asbstract specification.

INFRASTRUCTUREThe big lesson we learned from BUILDER is that the hybrid library isabout infrastructure. When we started the project we had a long list ofdeliverables. We started off viewing these things as separate entitiesalbeit with a common look and feel. In looking at how we were going tomove forward and how we were actually going to deliver these thingscommon strands began to appear. Similar functionality and needsappeared in many of the products. Common features, such asauthentication and Acrobat Document Delivery were going to berequired again and again.

So our view turned on its head. Rather than developing a number ofproducts individually we concentrated on building a single, well-connected, web environment that supported and facilitated the kinds ofproducts we needed to create.

BUILDER hardware and software

PII233

128mb RAM

4gb Disk (mirrored)

Windows NT 4.0 (SP5)

/

^ * - IIS

SiteServer

DAT

UPS

X2 IIS Components(HTTP/SOCKET)

Handles: 2 million hits f 100000 sessions pern


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

BUILDER lives on a dedicated server box. This box, purchased at thebeginning of the project, is about two years old and comprises an IntelPentium II 233 processor, 128mb memory and two 4gb SCSI drivesyielding 4mb of mirrored disk space. The box also has a DAT tape fordaily backups and an uninterruptible power supply (UPS) to enable theserver to close down elegantly in the face of power failure.

By today's standards this server is obsolete. How could we dream ofsetting up anything on less than a state of the art box? It is worthconsidering this for a moment. A very practical lesson can be learnedwhen it comes to web serving is that you do not need particularlypowerful boxes to do it on.

The BUILDER web site supports about 100 user sessions a day. Inaddition it hosts the exam paper database - a heavily used BUILDERservice that delivers between 100 and 1000 Adobe Acrobat documents aday. In addition to BUILDER, the server supports the University ofBirmingham Information Services Web Guide. This site generates about100,000 user sessions a month (or between one and two million hits amonth). All in all, the BUILDER server supports a significant amountof web traffic.

So how is the server coping? Easily! The BUILDER server is takingthis load in its stride, averaging between 10 and 20% resource usage. Itcould handle much more. If BUILDER were to develop a new server tosupport similar services it would not need anything state of the art. Infact something with the specification of a typical administrationdesktop, perhaps with some additional memory and fast drives, wouldbe more than sufficient. We would certainly not need to invest in a stateof the art box.

BUILDER software is Microsoft Windows NT-based, comprisingMicrosoft Windows NT server 4.0 (Service Pack Five); MicrosoftOption Pack, providing the Internet Information Server (IIS) webserver; Microsoft SiteServer 3.0, providing search capabilities; and twoServerObjects IIS components providing HTTP and SOCKET internetconnectivity.

Why Windows NT? The BUILDER team already had extensiveexperience with NT and many of the features we felt we would need touse were 'built in'. Straightforward and high level development tools -


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

such as Microsoft FrontPage - were readily and cheaply available alongwith a University department (Information Services) which already hadthe skills to use them. Given these factors NT was the logical choice.

There are issues. BUILDER has trodden a very careful path in relationto the Microsoft features it has exploited. Only those features which wefelt would be straightforward to implement on other platforms, such asUnix, were considered. For example, session tracking, knowing whosomeone is from page to page, is essential in an authenticated model.IIS, the Microsoft Web Server has session tracking facilities built in. Wedecided to exploit this feature knowing, despite requiring some coding,a similar feature could easily be added to a Unix Apache installation.Similarly, Microsoft SiteServer provides a range of 'personalisation'features. Although potentially useful, we decided not to use thesefeatures, as they would be difficult to implement on other platformswithout significant application development.

Active Server PagesINTERACTIVE

ASP

variable

componentsoOO

variablevariable

session tracking

IIS provides an environment called ASP (Active Server Pages).Normally web pages are served dumb. A browser requests a page andthe server delivers it as is. In the ASP model, the server opens thedocument and scans the HTML before delivery. Any script contained inthe document is processed. The web server delivers a file containingHTML along with the processed results of any scripting.

For example here is an ASP file that includes today's date:


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

Stored on the server: Sent to the user:

<HTML> <HTML><HEAD> <HEAD><Tm.E>ASPDEMO</TrriH> <nTLE>ASPDEMCXTrrLE></HEAD> </HEAD><BODY> <BODY><P>The date today is <% • dateO %>.</P> <P>TJie date today Is 1/4»9.</P></BODY> </BODY></HTML> </HTML>

Notice the script enclosed in '<%...%> tags.

A real advantage of this approach is that all the work happens on theserver. The resulting code, however complex, is browser independent.You can be running the latest version of Netscape Navigator or an earlyversion of Microsoft Internet Explorer. The results will look the same.

The most common use for ASP is to embed it in web pages as theexample above shows. This is what most people imagine the ASPenvironment to be. Although titled Active Server Pages, the ASPenvironment is capable of much more than this. For example, you canrun scripts in their own right. You do not need to embed dynamicelements in traditional HTML. For example:

Stored on the server: Sent to the user:

<script language="VBSaipf nmat="seivei"> <HTML>Response.write"<HTML>" <HEAD>Response.write-<HEAD>" <TITLE>ASP DEMONSTRATION<mTLE>Response.write"<TITl£>ASP DEMO<nm£>' </HEAD>Response.write"</HEAD>- <BOOY>Response.write"<BODY>" <P>TT>e date today is 1W99.</P>Response.write"<P>The date today V & dateO & "<P>" </BODY>Response.wnte"</BOOY>' </HTMl>Response.write'</HTML>'<script>

As before, a dynamically generated HTML document is delivered to theuser. This time a script creates the entire HTML.

An object rich environment

Another key aspect of the IIS environment is the provided suite ofobjects. As well as giving authors the ability to generate dates and otherscripted elements, IIS provides a number of functional objects thatscripts can talk to and operate.


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

Built in objects provide functionality such as session tracking - theability to identify a user as they move from page to page and associateinformation with them (such as their name and course for example).Built in objects are always available. They do not have to bedeliberately instantiated.

IIS also provides a range of objects that can be instantiated as needed.The Database Access Component is a crucial object enabling scripts tointeract with all manner of databases. Anything that can be accessed viaODBC can be accessed through this object and scripted to generatedatabase driven HTML.

You can buy in objects. BUILDER has invested in two ServerObjectobjects. These $100 components enable scripts to talk HTTP andSockets to other remote servers on the Internet.

Finally you can write your own objects. Objects can be written in avariety of different languages; Visual basic, C++ and Java to name afew. BUILDER has not needed to take this final step as everything wehave needed has already been developed. The $200 spent on bought incomponents would fund very little BUILDER development time andcertainly not enough to develop our own objects to the same level ofsophistication.

ScriptingAnother common misconception about ASP is that it is Visual Basic(VB) and that all coding must be scripted using VBScript, the scriptingversion of VB. In reality ASP is an environment. VBScript is thedefault scripting language but you can actually script in anything youwant. For example, JavaScript is provided along with VBScript. Perlcan also be loaded and used.

To conclude, ASP is a powerful and extensible environment enablingthe development of sophisticated web applications - ideal for the kindsof things BUILDER wanted to do.

IMPLEMENTATIONAuthenticationIdentifying users is crucial in the hybrid library. Landscape presentationand seamless access to restricted resources relies on the systemknowing who you are.


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

In the opening session, I described how I get into our physical library. Ihave an ID card, which I swipe though a reader that opens a gate to letme in. By interfacing with the same system, BUILDER allows peopleinto the hybrid library by asking them to enter a name and number offthe same ID Card. But is this approach secure enough? It is secureenough for our physical library. If a user drops a card and someone elsepicks it up that someone else can get into the library and access prettymuch all it has to offer. Given that BUILDER was at best going toreproduce this library experience virtually, ID card authentication wasfelt more than secure enough.

It is probably worth mentioning that the ID card is not enough to signup for services such as email or web space. In our physical world wewould need the ID card and some other personal information to registerfor these facilities. As BUILDER was not attempting to provide accessto these additional services, the soft authentication, as provided by theID card, was again deemed secure enough.

So how do you create web pages that can only be viewed by anauthenticated individual? Traditionally authenticated web pages arestored in a special directory. The web server secures this directory,requiring a username and password to provide access. Although aneffective approach, it is reliant on generating a separate user list,separate to those provided by the central management systems.Maintenance becomes more and more of an issue as individual usernumbers grow.

BUILDER has taken a different approach. First BUILDER pages aregenerated dynamically. Rather than just being a simple character dump(as for traditional served pages), ASP is used to generate the final pagethe user sees. Depending on the attributes associated (or not associated)with the user, different parts of a page can be displayed. In the case ofan unauthenticated user the page does not display at all but simplyredirects to the log in page.

Including this code at the top of each page ensures authenticated accessonly:

<% if isempty(session("USER")) then response.redirect "authenticate .asp' %><HTML>rest of web page here...


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

How do we get at the information on the users ID card? One approachwould be to create a database and dump user details into it. This is afairly typical approach and a common practice here at the University.The approach does have problems. First, you are replicating a lot ofdata. How do you ensure all of these data sources are kept insynchronization? Also how do you handle errors and omissions? Waitfor next year's dump or provide your own administrative procedures tomaintain your private database? Rather than rely on dumps, BUILDERhas looked into tapping into central databases directly. Advantages hereare that we do not need a database and that someone else looks after theadministration.

For ID Card authentication we have developed an interface into Talis,our library management system.

session

Are you a member of the Library?

BUILDER has developed a socket based interface to Talis called TalisTools. Using this range of tools we can access information stored withinthe Talis database, including information stored on the University IDCard. Using our installed ServerObjects socket object we can talk overthe internet to Talis, passing a user entered name and number off theircard. Talis responds to the name and number, either by identifying theuser by properly formatted name, department and status (student,postgraduate etc.) or responding 'unknown'. If the user is identified wecan consider them authenticated and allow them to access pages. Wealso associate the name, department and status with the session for use


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

by other parts of the web site. If the user is unknown we ask them toauthenticate again.

Using this simple interfacing process, BUILDER is able to authenticateall members of the institution with no maintenance overhead. Wherestudents are wrongly registered there already exist mechanisms toupdate records. BUILDER has successfully used this authenticationmechanism to support our Electronic Short loan service and morerecently to allow off-campus access to the exam paper database.BUILDER has also investigated linking to other institution datasets,including the campus NDS (Novell Directory Services). Although lessdeveloped and not in formal use, these approaches seem equally viableusing similar socket based interfaces.

Secure file delivery

Many of the BUILDER products require a mechanism by which AdobeAcrobat Documents (or other files) are delivered only to authenticatedusers. Delivering this kind of file over the web is easy to implement.You just create a link. Ensuring that only an authenticated user receivesthe file is a different matter.

We have already shown how we can make web pages only available toauthenticated users. Files need a different approach, as they have nodynamic element into which we can hook.

PUBLICPRIVATE

IP and password required


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

BUILDER has developed a 'gatekeeper' script. This script does anumber of things:

• The script checks the user is authenticated. Like the web pagesdescribed above, the script does this by checking that the USERsession variable exists. If it does the user is authenticated andthe script progresses to the next task. If it does not the user isnot authenticated and the script redirects the user to the log inpage.

• The script now accesses the file required. Files are stored in aplace only accessible to the script. This could be a local filestore or, as we have done in BUILDER, another secure webserver that will only accept requests from this routine. We talkto this server using our bought in HTTP object. The file isloaded into memory.

• The script now repackages the file stored in memory.Appropriate headers are added and the file is transmitted back tothe user's browser. Headers are important as they tell thebrowser what to do with the file data. For example, if we aredelivering an Adobe Acrobat file then we need to alert thebrowser so it can display it for the user with an appropriatebrowser plug-in.

• Finally the script logs the access including the name of theperson who accessed the resource.

BUILDER has used this delivery mechanism in a number of productsincluding Midland History and the Exam Paper Database. We havefound this mechanism to be robust and reliable even under extreme use.

Search engine technologies

Indexing and search facilities are an essential element of manyBUILDER products.

Research during the project showed that we could adapt search enginetechnologies to provide our products with the functionality theyrequired.

Microsoft SiteServer is a sophisticated product that sits on top of IISand provides personalisation, analysis and indexing facilities.BUILDER has focused on SiteServer's indexing facilities as it can


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

index a number of document types (HTML, MS Word, MS PowerPointand Adobe Acrobat) and exposes itself as a number of objects withinthe ASP environment. These objects can then be interrogated forinformation and used to present HTML results in any form we choose.

web resource web resourceweb resource

A good way to visualise this technology is as a database that goes offand populates itself. You tell the technology where to look and the nextday you have a database you can use.

Initially, we used SiteServer in a very traditional way to produceindexes for our journal products Forensic Linguistics and MidlandHistory. Both of these products contain Adobe Acrobat files that can beindexed by SiteServer if installed with the Adobe PDF I-filter. We theninvestigated developing products that indexed multiple sources, such asall the web servers on the University of Birmingham campus to providea true 'campus wide' search engine. In terms of complexity this simplyinvolved giving SiteServer multiple start points and a single cataloguein which to store the results. Using SiteServer 'crawl' technology ratherthan the existing University file scan approach meant we could accessall web servers regardless of platform. To SiteServer Windows, Macand Unix web servers all look exactly the same.


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

Finally we have started to experiment with producing unique searchengine products. The first of these, The Hybrid Library Search (HLS),creates a search interface on to all five Hybrid Library projects.Although the projects are separate entities operating from differentplaces in the country, the HLS provides a single searchable interface.

Using search engine technologies such as SiteServer has been one ofthe surprising elements of BUILDER. Initially we thought we would beproviding indexing and searching using databases. Our thinking shiftedfrom this model to a system where we have software that goes off andcreates these databases for us. SiteServer has saved us time and moneyand provided a far more flexible solution than we had originallyenvisaged.

BUILDER PRODUCTSThe final section of this paper lists a number of BUILDER products. Aswell as an opportunity to showcase our wares, each product contains asmall commentary describing the features of the BUILDERinfrastructure used to support its development. All these products canbe accessed through the 'Other Products developed by BUILDER'section of the BUILDER Web Site.

Electronic Short Loan

p . [ « V— Favtxo loo. jj*> Q

Bads " " SBV Rah** Hon» S**di f*vt»l«* Huttoi M*rf ftrt Ed* Dacua

B l Electronic ShortLogin

1

fstewt'j

Visitors

JiEmOHBMMuQCHHiB23Loan

tf you would like la view the Elections Short Lo*n but are not a memberplease use the user name: visitor and ths password: 00000000 (i.e. 8

Go to BUILDFR Home Pane

Maiimua

of the university•ros)


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

The BUILDER Electronic Short Loan (ESL) enables access to shortloan materials specified by lecturers to support their course.

The ESL exploits Talis Authentication and the Gatekeeper file deliveryroutine. The service has been available for 18 months and can beaccessed both on and off the campus

Exam Paper Database

aI] WpAWw t**h* bhannc

TIlKt.MMiRSlTYOl- «IKMINGH\M

Exam Paper DatabaseDepartment Search

Choose a tchool of <%putmmt and cSck the Search Bitten

| Select a deportment.. j

Ac comitinf turf f inance

5e*swn 1993/19991U0O2398 (A0C0O1

S«swa 1997/19931U002497

Setnon 1993/19991U0024931A00004

ACCIO-S liftoAirnoit T» Coinnnting

Like the ESL, the Exam Paper Database provides access to previousyear's papers, which have been scanned in Adobe Acrobat format.

The Exam Paper Database exploits Talis Authentication and theGatekeeper file delivery routine. The service has been available for justover a year and can be accessed both on and off the campus.

The Exam Paper Database has been one of our most popular productswith over seventy thousand papers being downloaded in its fourteen-month lifetime.


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

Forensic Linguistics

Forensic Linguistics is the first BUILDER supported journal product.The product exploits Authentication and Gatekeeper document delivery.The site also exploits SiteServer to provide a search facility of AdobeAcrobat articles.

The web site is completely self-contained with all user access andadministration, such as adding users and new articles, being facilitatedthrough a single web interface.

Hybrid Library Search EngineThe Hybrid Library search Engine is a BUILDER Search engineproduct that cross-searches all of the Hybrid Library project web sites.

The product exploits SiteServer indexing using multiple start points anda single catalogue. The search engine indexes a number of differentdocument types.


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

I BUILDERHYBRID LIBRARY SEARCH

Search for information across Agora, BUILDER, Headline, Hyhfe and MAL18U project 'Mb

sites simultaneously'

This practical example demonstrates the potential of a seamless interface cross-Tearchmg a number of web servers and document types. Try these searches: hybnd andnot builder, broker and 'information landscape*. 'search engine*.

ISubmit |

Search for: hybrid ^SV- \f-r builder 444 records found.

^J* 1- MALIBU Homo Page

HOME BACKGROUND ACTIVITIES AND REPORTS CONTACT DETAILS Introduction toProject MAUBU The project will develop and implement prototype hybnd hbranes ineach of the three major partner institutions and in so doing denvt generalitableinstitutional models, which wid be tested first in a

O 2. Project AgQr.aHybnd Library Architecture and Hybnd Library Management System The diagramshows the tactical structure for the hybnd hbrary manaqement structure. It shows

Campus Search Demonstrator

The Campus Search demonstrator provides an index of all the majorweb servers on the University of Birmingham campus. It alsodemonstrates how external search engines such as Alta Vista andHotBot can be cross-searched with results being returned within aseamless interface.

The product exploits SiteServer indexing using multiple start points anda single catalogue. The search engine indexes a number of differentdocument types.

The product also exploits the ServerObject's HTTP object enablingsophisticated 'scrapes' of remote web sites.


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

Umdi I

E l

r«i« housed ott tit* Unlveisiiy of Bimtliigliain

> Submit I

S«atch Ion

School or Social So»nccs Tht Inisrt'jte for German Studies Inlsmel Se»rEngine3. There is no single or definilw index to th» World Wide Web. Us.vary naujie ntiktt this irrpottible Som* institution* and compares runtp*ci»l programs that teirch the W*t Thest pragtwnt.

1. Potufi >;<H,Mf Cp'tf** };T Lfttrtffl"* a t " < t h * t«'*"i^tNifamiauon on ih« English Department at Birmingham Unwetily

Forewoid Editots" Not* Inducting t1iKJ««ts *to Civil Engineering JohnAsh, School of CM[ Enqtn*eiin^ U«ng titmin^ journals in ttit School ofEducation Carol Gisy, School of Eduration D»wloping hey skills andlanguage \IIQ in foistgn language learning John

Thin Client Demonstrator

8 * * St«>fl iJ y -i- J A . d

Umdi F M M H Hm»y M«) Ptrt Edi Doeua

^ 1 BUILDERTHIN CLIENT DEMONSTRATOR

Farnell

Semiconductor data from nvmrSO major^mmnufMettmrt^„ ;«ur>*̂ *»


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

The Thin Client Demonstrator enables CD ROMs to be accessed overthe web.

Although not discussed in this paper, BUILDER has worked with ThinClient technologies to facilitate this demonstrator. The technologies arenow being used within the campus to enable access for all to thelibraries' collections of CD ROMs regardless of the platform the user isusing.

Midland History

3 3 H 8 JJ J J- J » . ilS R * * H S f c f t a H M i PM £ * Q

MIDLANDHISTORY

Electronic Edition

m

Midland History is the second BUILDER supported journal product.

The product exploits Authentication and Gatekeeper document delivery.Unlike Forensic Linguistics, all articles in Midland History have beenscanned and fed through Adobe Capture OCR (optical characterrecognition) to provide embedded text source for indexing. The site alsoexploits SiteServer to provide a search facility of Adobe Acrobatarticles.

Again, the web site is completely self-contained with all user access andadministration, such as adding users and new articles, being facilitatedthrough a single web interface.


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4

Tailis Toolbox DemonstratorThe Talis Toolbox Demonstrator demonstrates the kinds of things thatcan be done with the Talis Tools interface from within a web page. Thedemonstrator can be used to access bibliographic and user informationstored within the Talis Library Management system.

The product exploits the ServerObjects SOCKET object to facilitatecommunicating with remote systems over the Internet.

'«•"•« J o * M*

- '«3 J i3 5* 'Si 'J "

BUILDERTALIS TOOLBOX DEMONSTRATOR

Bibliographic Iitfomiation

This screen allows ynti to interrogate iho Talii D*tabase by ISBN or ISSN. At well as norm*!bibliographic in formation, the bibliographic tools provide additional information such as physicallocation and an indication o f popularity1)

Go to Other Products neveloned hy Rl 1T1 DFR

CONCLUSIONThis short paper has described how we have gone about developingBUILDER and has described the approaches and infrastructure we haveused to make it happen. We hope that we have conveyed a message that,although we have a grand vision, realizing it is not rocket science andelements can be easily achieved using straightforward and easilyavailable technology today.


Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

6:35

17

Oct

ober

201

4