RDS Blog

Lately we’ve focused an awful lot on Summon when talking about all things resource discovery. Summon is the new kid on the block, after all, and we’ve needed to try to get a handle on it. It’s changing the way people use our resources, and there are still a lot of open questions about how it’s used and how it should be used.

But what about the catalog? We haven’t really been talking much about the catalog. Not that there hasn’t been any interest from my colleagues: on the contrary, I’ve heard loud and clear the desire for a catalog that can do faceted browsing and the discussions about possibly loading our catalog data into Summon. Unfortunately, as a III shop, we’ve always been at a disadvantage in this area. We’ve never had an easy time of getting our catalog data out of the catalog because our system hasn’t really supported it.

What if I told you that had changed? What if we suddenly had a way to load data from our ILS into other systems of our choosing in data formats of our choosing? And what if we could automate it, to the point that a record saved in the ILS would get extracted minutes later with no muss, no fuss into the formats and systems that we specify? If we had this, what sorts of things could we build? What new discovery tools and methods could we support?

My big project over the past five months has been exactly this. It’s all still in development and probably will be for a few more months—but it’s creeping ever closer to being production-ready. The problem—my problem—is that this thing I’m building is infrastructure. It’s invisible. There’s not really an end-user interface that I can point you to so you can look and get a feel for what it does. But it will enable things that we couldn’t have done before. It will enable us to do the things we’ve planned in our RDS Phase 2 Action Plan—and much more.

So this is the first in a series of blog posts that I wanted to write to introduce this thing in a way that might make it interesting and accessible. I’ll start out by laying some of the groundwork, examining why having control of our data is so important for the things we want to do.

The Importance of Data

Astute readers might now be thinking, “Wasn’t moving to Sierra supposed to help open up our data?” Yes—yes it was. With Sierra, III promised much. III billed the system as “open”—built on open technologies using a “service-oriented architecture.” Listening to their marketing, Sierra sounded almost as though it would provide an extensible ILS framework that we would be free to build upon. We were promised open APIs that would allow us to build new software components that would consume data from Sierra and be able to interact directly with Sierra.

But wait, let’s take a step back. I know we throw around terminology like “open architecture” and “open data” and “API,” but these are all kind of buzzword-y, aren’t they? We talk about these things like they’re important—but we’ve never stopped to explain why.

So What Use is Data, Anyway?

At its most basic, a computer program comprises a set of instructions that a computer follows to perform some task. Useful programs contain generalized instructions that can be reused in different contexts. Data is what a program uses to do stuff.

Say I want to program something that displays a formatted list of titles and authors for a set of books that I own. One approach would be to write a separate command to display each individual piece of information—each title and each author, like this (where “\n” is a new line):

    print "Title: Hamlet\n"
    print "Author: William Shakespeare\n"
    print "\n"
    print "Title: The Sun Also Rises\n"
    print "Author: Earnest Hemingway\n"
    print "\n"
    print "Title: The Great Gatsby\n"
    print "Author: F. Scott Fitzgerald\n"
    print "\n"

I hope you see that this approach is pretty useless. It displays exactly what we told it to display and nothing more. What happens if we want to change the label “Title” to “The Title?” What happens if we want to change what displays between each book? We have to go through and change each instance in our code. This is clearly a very inefficient way to program, fraught with potential errors.

But we can write a more generalized program that does the same thing using fewer actual instructions. All we need to do is to store the title/author information for our book list in some sort of data construct. Then we can code a loop that will repeat one set of instructions for each item in the data.

    my_data = [{
        "t": "Hamlet",
        "a": "William Shakespeare"
    }, {
        "t": "The Sun Also Rises",
        "a": "Earnest Hemingway"
    }, {
        "t": "The Great Gatsby",
        "a": "F. Sott Fitzgerald"
    }]

    for book in my_data:
        print "Title: " + book['t'] + "\n"
        print "Author: " + book['a'] + "\n"
        print "\n"

What’s happening here is that we’re storing all of the authors and titles in a nested data structure that we’re putting in a variable called my_data. Our program loops over each element in that data structure, temporarily assigns it to the variable book, and then displays the title (book[‘t’]) and author (book[‘a’]). This is much better than the last version of our code. If we want to change how anything is displayed we only have one place to change it.

In addition, now that the data is actually defined in a data structure, we can reuse it later in our program and do other things with it besides display it. We could write code to let us search it, for example, which we couldn’t do at all with the first version.

But this still isn’t as good as we can make it. We’re still storing our data structure inside our program, and it’s still a little bit cumbersome to have to get the brackets and curly braces and the formatting all right when we’re editing the data. The next step might be to store the data in a separate file that’s a little more compact and little easier to edit—say, a comma-delimited (CSV) file, like this:

    title,author
    Hamlet,William Shakespeare
    The Sun Also Rises,Earnest Hemingway
    The Great Gatsby,F. Scott Fitzgerald

Now to use this, we’d have to code instructions in our program first to access the file, parse the contents, create a data structure like the one in the last version, and load the data into memory. But if the resulting data structure is identical, the rest of the code works without modification.

Show Me the Data!

Once I have my data stored somewhere, like in a CSV file that I’ve saved on my computer, I can write programs all day long that use it to do different things, and I don’t have to re-enter it anywhere. In a nutshell, that is one of the primary uses of opening up data: it allows anyone that has the necessary skills to write programs that can do new things with it.

In contrast, our data in Millennium was locked away—it was both physically inaccessible to us (except what we could access through the Millennium user interface) and stored in a data format that was Millennium-specific, that we couldn’t make sense of even if we could access it. To be fair, we could export data in a few ways: as MARC via Data Exchange, as MARC via Z39.50, or as delimited data via Create Lists. But these methods were too limited or too manual to be of much real use.

With Sierra, although the reality has unsurprisingly fallen somewhat short of the marketing promises, III has cracked open the door for us. Sierra is built on open-source database and indexing software, unlike Millennium. III has given us direct read access to the database. With this little bit of extra freedom that we didn’t have with Millennium, they have opened the door to allow us to take control of our data.

But is direct database access enough?

Storing, Using, and Extracting Data

Turning back to our earlier example: as we use this program we’ve created, there might be more and more that we want it to be able to do. Say we want to be able to track the date that we added a book, the number of times each person in our family has read a book, the amount we spent on a book, and the person in the family that bought a book. Say we notice that we have multiple books by the same author and we want to start recording information about authors somewhere so that we don’t have to replicate it for each book. As we want to do more with our program, we need the data that supports that functionality, and we need our program to be able to read that data in order to work with it. And, as our data grows—both in size and in complexity—the format in which the data is physically stored begins to impact how smoothly and efficiently the program runs.

How a program stores data and what it stores are highly individual to that program. It has to be able to read stored data into variables as appropriate, use those variables to carry out its tasks, and then update the data in storage as needed. It’s best to store data in a way that requires as little processing as possible to translate to internal data structures—if your data access methods are inefficient, it can slow down your program and make your code harder to understand and extend. 

The upshot is that one system’s internal data store isn’t going to translate 1:1 to any other system or program—nor should it.

Let’s consider the ILS again and what I want to be able to accomplish. I don’t necessarily want to use the exact data as its stored in the ILS database. Each of the applications I want to write needs a different subset of data from the ILS; for each application I may need to store similar (or the same!) data quite differently.

At the moment Sierra allows us direct access to its internal database using SQL. SQL is the standard language used for querying relational databases: most programming languages have functionality that will let you query a database using SQL and pull data into internal programming structures with relative ease. With this, we can actually write programs that can read Sierra’s internal data.

But you know what? As nice at that is, it isn’t good enough. Sierra’s database is designed to support the Sierra ILS—it wasn’t written to support my applications. III made design decisions when it built the database that make it work okay for some purposes and not others. Let me give you an example that illustrates what I mean.

An Example: A Shelflist Application

One of the applications I started working on back in August is a simple shelflist builder to help with doing inventory. It lets you enter a location code and a call number range and pull back a list of items, sorted by call number, that you can then browse. You can search for call numbers and barcodes. You can mark items as on or not on the shelf.

The shelflist itself is a table of items, like this:

When you click on a row, it expands to show you the title, author, bib and item record number, and a link to the record in the WebPAC.

This data of course all comes from Sierra initially. When you first create a shelflist, my application submits an SQL query to Sierra, gets the information, and then stores it as a flat file so that my code can access the data quickly and efficiently. But the data as stored in Sierra is anything but flat. The database structure is quite complex, with item information and bib information being stored in separate tables and variable length fields stored in yet a separate table. Once I convert the data to the flat structure, access is instantaneous—but the initial query to build the shelflist takes 4 to 5 minutes, and sometimes even longer, to run. The SQL query is as efficient as I can make it—but, based on the database structure and what fields III has and has not indexed, the query still takes forever. And waiting 4 to 5 minutes for this query to run is unacceptable.

So even though we have direct access to the Sierra database, we still don’t have control of our data. To have control, we need to be able to pull the data out of Sierra. We need to be able to extract it and put it into other storage mediums that we do control, ones that we can configure to support fast, efficient access to the data that our applications need. The direct access we have to the database allows us to do this, but we’ve had to build the functionality ourselves.

What About APIs?

When one system shares data with other systems, there are at least two potential gotchas. One we saw in the last section: a system’s internal data won’t necessarily translate well to a system for which it wasn’t designed and optimized. Another is that a system has to maintain the integrity of its data. If we allow multiple programs—even ones that we’ve written—to access and write to the same data store, we risk that one of the programs might write data that renders the store (or parts of it) unreadable or invalid for other programs. This is why even open systems don’t generally allow write access to their internal data.

One way to take care of these problems is to enable access to your system via an API, or Application Programming Interface. If someone has created an API for their system, it means that they have defined a set of commands that I, for example, could use in my own programs that allows mine to interact with theirs in predefined ways. Maybe this allows my program to submit a query to their system to get back data that it can then use to do something. Or maybe it submits a call to their API with a data value and their API performs some calculation on the value and returns the result. Having access to APIs helps me extend the capabilities of my program so I don’t have to reinvent something that someone else has done. And APIs allow my programs to interact with other systems in a controlled, predetermined way—i.e., so that they don’t have to give me carte blanche access to everything in their systems and I don’t have to care about their internals.

APIs can be read-only or read-write. A read-only API only allows other programs to send commands for reading data, whereas a read-write API allows other programs to send commands that write data to the system as well.

In a way, you can think of an API as being a counterpart to a UI (User Interface). A UI allows a person to input commands, enter data, and work with a system to accomplish some task. An API is the same, but for a computer program. It’s just as important to design an API well so that they’re easy to understand and use for the same reasons that its important to design a UI well.

The work I’ve been doing the past five months initially began as a desire to create an API for our catalog data. In fact, that’s still the major component. Having a “programming interface” built on top of our catalog data that can serve up different views of that data on request will make application development easier. (And I will come back to this in a later post.) 

At the same time, you may have seen recent announcements from III about their own “Sierra API,” which has been in the works for a long time. They’ve finally announced that they will be releasing the initial version of their API in April.

So you might be wondering: how does III’s API affect mine? Have I just wasted five months of work building something that’s now redundant?

1. Consider my earlier point about why having direct access to Sierra’s database isn’t good enough. Just like the Sierra database, III has designed their APIs for some purpose. I haven’t seen them yet, so I can’t yet say how well-designed they are or how applicable they will be to the types of things we want to do. But they’re still their APIs. They are in control of what data they serve up and how that data is modeled. I want our applications to be built on top of our own APIs, because I want the option to serve data to our applications in a way that’s custom-tailored to what we need. The applications I build this way will be more fully functional and will perform better.
2. Speaking of performance—if API access is slow, all the applications that use that API will be slow. I can ensure that our APIs are fast and responsive; I can’t ensure that III’s will be.
3. Let’s think of our catalog data as separate from Sierra. III is building an API for Sierra. I’m building an API for our catalog data. Now that we can extract data from Sierra, and as we build more and more of our own applications, that distinction will become more and more meaningful. For instance: data in Sierra isn’t FRBRized. The data extraction process I’ve built would allow us to write an extraction routine that would analyze and FRBRize our catalog data as it gets extracted, loading it into a system as separate Work, Manifestation, Expression, and Item entities. Our API would then serve up this data as such to applications we build to use it. Sierra’s API couldn’t do this, because that’s not how Sierra stores data.
4. I’m almost certain that there will be ways that my API will be able to use III’s. For instance, one thing mine won’t be able to do on its own is write data to Sierra, whereas some of III’s APIs will be read-write. The systems underlying my APIs could make calls to III’s to enable us to write to Sierra while still letting us retain all the advantages of controlling our own APIs.

Ultimately, building an API lets you give other programs access to data using standardized queries and commands. From the consuming program’s perspective it’s not too different than storing data on the filesystem or in a database and using commands to read it into an in-memory data structure. Just as with every method for storing and accessing data, there are practical implications and considerations that affect how you build and design your API depending on the needs of the application that uses the data. Building and maintaining our own API for catalog data means that these factors are under our control—it means we can build better applications and generally do more than we could otherwise.

Hopefully now why we’re building what we’re building is a little bit clearer. But I still haven’t given you a great idea of what exactly it is we’re building. In the next installment we’ll take a closer look, specifically at how the extraction process I’ve developed works and how it will run in a production environment. There are a lot of practical implications—like, how do we keep extracted data fresh and in-synch with Sierra? Will it require any extra work from library staff to maintain? Stay tuned!

User Interfaces is continually working on improving resource discovery interfaces, and of course an integral part of improvement is always evaluation. One major element we want to evaluate is our changes’ impact on patrons’ library use. Near-term plans for discovery hinge on Summon, so we’re especially interested in how Summon and our Find Articles search have affected e-resource use. But this is really tough to characterize and quantify. For one thing, the difficulty of getting meaningful usage stats for library electronic resources is notorious. Our e-resources are spread out among many different databases from many different vendors, where each vendor manages its own interfaces and its own content and collects its own stats its own way. We have meta-interfaces that are supposed to help funnel our users to the correct resources in the correct databases, and these systems collect stats as well. Although we can compile stats from each of these sources, little of it is unified. Stats from different sources measure different things differently.

Summon landed right smack in the middle of an already complex situation when we launched the beta in 2012. According to Karen Harker, the library’s Collection Assessment Librarian (and e-resource stats guru), Summon has played havoc with the stats we get from database vendors. Some vendors have shown a steep increase in usage while others have shown a steep decrease, and it’s impossible to tell from the data what traffic comes from Summon and what doesn’t.

However, one set of statistics we have that has remained pretty consistent over the years is what we get from Serials Solutions about our “360” services we have through them: 360 Core (our e-resource knowledgebase), 360 Link (our link resolver), and our e-journal portal. This includes “click-through” stats, which measure users’ requests to get resources’ full text.

What’s convenient for our purposes is that:

1. Summon uses the link resolver to link out to many (but not all) full-text resources, so the 360 stats include some Summon usage.
2. Our 360 services predate Summon.
3. Summon implementation did not change anything about our 360 services that would affect click-through stats other than the effect Summon itself has on full-text downloads.

So, if nothing else, the 360 click-through stats seem to provide a good way to compare pre-Summon e-resource usage to post-Summon e-resource usage. Although they can’t give us the whole picture, they can help us determine whether or not Summon is having an impact and maybe partially characterize that impact.

Click-through Stats, 2006-2013

In truth, I’ve been keeping an eye on these stats for a while, as they are quick and easy to obtain. Last spring I put together a visualization that shows a comparison of the years 2006 through the present, and I have been updating the graph with new data on a regular basis. Last week, in preparation for a Liaison’s meeting on the topic, I updated the graph with complete data for Fall 2013. Now that our Find Articles service has been live for over a year, I thought this would be a good time to share what we’re seeing.

The visualization I created is located here. Note that I built this using the D3.js JavaScript library, so it works best in Chrome and Firefox.

Here’s a screenshot showing the relevant data.

We implemented Summon as a “beta” at the very end of January 2012, so the post-Summon lines are the red and green ones, and the pre-Summon ones are the brown, blue, and light grey ones. Here are the features I want to point out.

• Pre-Summon lines are grouped together at the bottom and are startlingly consistent in terms of data values and line shape.
• The first month of our Summon beta click-throughs were almost double the previous February peak from 2011. The months following consistently show much higher usage compared with previous months. (Except July/August 2013, which I’ll discuss in a minute.)
• September 2012 is when we launched Summon as “live” in conjunction with the launch of our new website, and Spring 2013 (live) shows a nice increase compared to Spring 2012 (beta).
• Fall 2012 and Fall 2013 both show “live” usage and are pretty consistent.
• Summers are still low, which is to be expected. But most striking is Summer 2013. In 2013, the difference between summer and spring and summer and fall looks proportionally much greater than the difference between summer and spring/fall during pre-Summon years.

So based on this data, what conclusions might we draw about Summon and the impact that Summon has had on e-resource use?

First, I think we can safely say that the leap in numbers of click-throughs that we see from 2011 to 2012 and 2013 was caused directly by Summon. The data corresponds perfectly with our Summon implementation timeline. Nothing else happened in 2012 and 2013 to explain the change any other way. We always have fluctuations in enrollment and database subscriptions, and, despite these, 2006-2011 numbers are relatively consistent.

Second, the magnitude of the leap in click-throughs after Summon implementation and the levels that are being sustained suggests that Summon is well-used and that people are continuing to find it at least somewhat useful. If people were not finding what they needed through Summon, I’d expect the click-through rates to drop off. (Of course, the question is: well-used and useful compared to what?)

Third, there’s the matter of Summer 2013. I checked the figures and found that there’s an average difference of -61.3% in 2013 between summer and spring/fall. Comparatively, 2010 and 2011 only have average summer and spring/fall differences of -39.1% and -35.1%, respectively. I also checked enrollment figures and found that there was a comparatively larger dip in enrollment between summer and spring/fall in 2013 than previous years—but still not large enough to explain the large difference in click-throughs by itself. My guess? I think this data may show what we have heard anecdotally about Summon: that students use it, while faculty (overall) tend to stick with their tried-and-true methods of research. If Summon’s impact on click-throughs is disproportionally weighted toward times of the year when students are around, then it seems reasonable to assume students are using it more than faculty.

What about Summer 2012? Click-throughs were a bit higher than in 2013. Unfortunately 2012 is a little difficult to generalize about, since we were in beta in spring and summer and then went live in the fall. It’s possible that a lot of faculty members were giving Summon a test run during the summer and decided it was not too useful for them, boosting its stats in 2012 and leading to a drop-off in 2013. It’s tempting to think that enrollment numbers probably play a role (15743 in 2012 and 13866 in 2013), but if we look at Summer 2010 and Summer 2011, we had a big drop in enrollment (17259 in 2010 and 15909 in 2011) while the overall number of clickthroughs is higher in 2011. The forces at work here may simply be more complex than we can determine based on the numbers we have available. It will be interesting to see what happens this summer.

To summarize, here’s what I think we can say based on these statistics.

• People are using Summon to get access to the library’s full-text e-resources.
• With Summon, we’ve seen a big increase in requests being passed through the link resolver.
• People continue to find Summon useful and continue to use Summon to access full-text e-resources.
• We think that, overall, students are using Summon more than faculty members and that most faculty members are sticking with their tried-and-true methods of research.

And here are a few things that we most assuredly can’t say anything about based solely on these statistics.

• If or to what extent Summon use is cannibalizing direct database usage.
• If Summon is just shifting usage of e-resources or if it’s actually increasing use.
• Summon’s effect on use of A&I resources.
• If Summon is causing a decline in use of resources not indexed in Summon.
• If people are finding better, more relevant resources through Summon compared to other sources (such as direct database searches).
• What impact our Summon setup and the defaults we use for our Find Online Articles search has on e-resource use.

Sequels to successful Hollywood movies (not to mention prequels) are notoriously hit and miss. For every The Empire Strikes Back, Aliens, and Wrath of Kahn you have The Phantom Menace, Alien Resurrection, and The Final Frontier. (Yes, I do watch a lot of sci-fi. Why do you ask?)

User Interfaces has just produced our very own sequel, a companion to our thrilling 2011 debut, Resource Discovery Systems at the UNT Libraries. We call this one: Resource Discovery Systems at the UNT Libraries: Phase Two Action Plan. 

Think of it as more of a continuation than a full-blown sequel. The original outlined a grand, multi-phased RDS implementation vision and then detailed an action plan for just the first phase. After Phase One, we said that we would revisit our vision, update it based on our experiences, and develop a concrete action plan for Phase Two. As astute readers may have already guessed, this is that plan. We hope that you find it worthy of its predecessor—something like, Part 2: The Users Strike Back, rather than Part 2: Discovery Boogaloo.

• Download the Phase Two Action Plan Now!
  
  
• Go ahead—download it, read it! It’s only about 10 pages of actual content, with some pictures. Or, at least read the Executive Summary if you’re short on time. 
• Although we are pleased with it and feel comfortable presenting it to you as a finished product, this is still in draft form! Before finalizing it, we wanted to put it forward to library employees for comment. So after you’ve read through it, please tell us your thoughts in the comments. (I’ve started off the discussion by addressing a few comments and questions that we’ve already gotten.)
• If you haven’t read the original RDS Report—or if you just want to brush up on it before tackling Phase Two—you can get it here. (We have a publicly accessible version here, but it omits the Phase One Action Plan at the end.)

1)      Will blog authors be allowed to create their own tags?

Absolutely! All authors will have the ability to freely create two type of tags via Drupal’s  Taxonomy option by default:

• Tags (free keyword tagging)
• Categories (a dropdown list of controlled vocabulary)

2)      Will moderated comments from readers of the blog be allowed?

By default, the comments function for each blog is disabled.  The comment function can be turned on per blog author(s) request.  It is important to point out that:

• Blog author(s) will be solely responsible for moderating, approving pending comments,  and deleting inappropriate comments
• All incoming comments will be in pending stage, and will need to be moderated by the blog owner(s) before they will be made available to the public
• Spam prevention means have been implemented to help preventing spam. However, UI and Lib-Taco can not guarantee that pending comments for approval will be spam-free.
• To reduce user management overhead, we will not require the visitors who want to create comment to create a user account before a comment can be submitted.  However, reCapture Form + email address will be required to fill out before a comment can be submitted. Please see example: http://blogs.library.unt.edu/example/post/1

3)      How will the statistics on the number of individuals viewing the blog be calculated?

Our libraries have chosen Piwik (http://piwik.org/ ) to replace Google Analytic (due to Google’s SLA issue) as the software for collecting libraries websites usage statistics.

Each blog comes automatically with its usage statistic tracking installed, and the stats will be made available to all blog authors to view via https://pw.library.unt.edu.

4)      Will statistics on the blog usage be accessible to the blog authors?  If not, what would the expected turnaround to get those numbers from UI be?

The statistics of UNTL blogs will be make available to all blog authors via https://pw.library.unt.edu after the requested and approved blog is installed.

5)      Can the blog author of a side bar profile section with their picture and a brief bio?

The author profile (with picture and bio) feature  will be made available by default with each blog installation.

The author’s full name (not euid) and the link to view this author’s profile will be accessible through each post. Please see example here: http://blogs.library.unt.edu/example/post/3. You can see the full name of the post’s author, and access to the profile is right beneath the post title.  Each author will be able to create and update his/her own bio and profile picture freely.

6)      Will the blogs be indexed by Google?

Yes. In addition, UI will actively help each established blog with blog marketing via the library website, and promote discoverability through all means that it may deems necessary.

7)      Can we allow guest writers not affiliated with UNT?

At this point, it is beyond the scope of this blog service.

8)      Can we customize the side bars?

Majority of the typical blogs features, such as archive, search, related links, latest post, and social network sharing are already made available at  the installation by default. For keeping consistent branding and providing familiar user interfaces across the blogs, blog author/owner by default will not be able to customize the side bar. However, after each blog is installed, it will be in ready condition without the need of any customization. Blog author/owner will be able to:

• Edit “About” page
• Edit “Contact” Page
• Create/update Posts
• Add/Maintain Related links
• Create taxonomy (free tagging, and controlled vocabulary)

9)      The web form mentions storage limits are subject to change.  What are the storage limits currently?

Per image/document upload size limited is set at 2 MB per upload, and there is no limit so far on how many files can be uploaded per author for each blog.

Lastly, here is an example blog we have set up for everybody who is interested in requesting a blog to preview https://blogs.library.unt.edu/example, pretty much this is what each blog author/owner should expect from the default blog installation.

Please contact Ui.library@unt.edu for acquairing Guest logim access for a test drive. 

It has been a year since we revealed the Summon web-scale discovery service as our libraries’ designated search tool for discovering online full-text articles. 

How is the Summon faring with the public so far?

The folks at the User Interfaces Units are the firm believers in Data speaking for themselves. Let’s us show you what the usage data we have collected are telling us.  

Please visit our online presentation here: http://tinyurl.com/c5clafc

For background on Sierra and the migration project, please see this PowerPoint presentation file.

1. What system downtime will be associated with the migration, and what exactly will the “downtime” entail?
2. How will logins and authorizations in Sierra work? Can some areas retain generic logins (e.g., generic Circ logins for students) that can then be overridden with specific authorizations?
3. Diacritics in Millennium aren’t easy to type in. We have to type them in by their codes, but we can’t see what the codes are. Is this improved in Sierra?
4. Will we be getting the Sierra Dashboard product? (Is it a separate piece?)
5. How will Sierra affect printing templates/options?
6. Will SQL mean faster Create List completion?
7. Will there be formal training/tutorials available when we launch?
8. For how long will we still be able to use the Millennium client on top of Sierra after Sierra goes live? What about the telnet version of III?
9. Is there a date by which we need to stop making changes to Millennium?
10. Will patron loads work the same with Sierra?
11. Will the Music Special Collections database that contains, e.g., the WFAA/WBAP collections continue to work in Sierra?
12. Will the Output Vouchers and PVE system still work in Sierra?
13. Will LDAP / single sign-on features still work in the WebPAC in Sierra?
14. Will the self-checkout stations continue to work in Sierra?

Q: What system downtime will be associated with the migration, and what exactly will the “downtime” entail?

A: There are three dates that will involve system downtime:

• November 8th, ~8AM to 4 or 5PM, for installation of two new servers.
• November 18th, ~1-4 hours at the most in the late morning, for upgrading Millennium to version 2011.
• January 23rd, ~10AM to 6 or 7PM, for switchover to Sierra.

“Downtime” means that the staff-side Millennium client is unavailable, the telnet application is unavailable, and the WebPAC is unavailable. For the first two dates, this will have no effect on electronic resources–the IR Services page and all databases will be available even though the catalog is down. For January 23rd, since we will have migrated the electronic resource front-end into the catalog by that time, the databases/e-journals A-Z lists and search interface will be down, but individual databases and e-journals will not be affected (e.g., if you have them bookmarked).

During the downtime, circulation functions will be performed–depending on the area–either using the Millennium offline circulation program or a paper process. If you work in a circulation capacity and aren’t sure what your area will be doing, please check with your Circulation Work Group representative to find out.

Back to top

Q: How will logins and authorizations in Sierra work? Can some areas retain generic logins (e.g., generic Circ logins for students) that can then be overridden with specific authorizations?

A: The situation with logins in Millennium is a little complex. In Millennium, there are two separate components: logins and initials. Certain settings are tied to your login, while authorizations are tied to your initials. Some areas have group logins and group initials; other areas have individual logins and individual initials; still other areas have some mixture of group and individual logins and initials.

Sierra combines logins and initials into one single “user.” Once you log into Sierra, you inherit whatever authorizations are tied to that user. It will be possible to set up “context users,” which will function similarly to Millennium logins–you log in with the context user’s name/password, then you log in with your username/password to set your permissions. It will also be possible to override permissions if you’ve logged in with a user that has a more restrictive set of permissions and need to perform a particular function that the regular user is not authorized to perform. And our system could use both single-user and context-user access.

For more information, please see the Sierra Knowledgebase article, Migrating Users from your Millennium System.

Back to top

Q: Diacritics in Millennium aren’t easy to type in. Is this improved in Sierra?

A: Unfortunately diacritics in Sierra appear to behave exactly the same way as in Millennium.

Back to top

Q: Will we be getting the Sierra Dashboard product? (Is it a separate piece?)

A: We will be getting the Sierra Dashboard product–it is not something we have to purchase separately.

For more information about the Sierra Dashboard, please see the CS Direct Knowledgebase FAQ on the topic.

Back to top

Q: How will Sierra affect printing templates/options?

A: Not at all. Print templates and options will be the same in Sierra.

Back to top

Q: Will SQL mean faster Create List completion?

A: Yes. Create List jobs will just be running SQL queries in the background, so they should run very quickly in Sierra.

Back to top

Q: Will there be formal training/tutorials available when we launch?

A: Yes. The Sierra page on CS Direct has the Sierra Knowledgebase which has video tutorials and articles. You can also access the Sierra manual (Sierra Web Help).

Back to top

Q: For how long will we still be able to use the Millennium client on top of Sierra after Sierra goes live? What about the telnet version of III?

A: Officially there is no date yet by which the Millennium client will stop working with Sierra. However, we would like to phase out Millennium entirely by June 1st.

In Sierra, there is still a significantly stripped-down version of the telnet interface (called the “Admin Corner”) that contains the functionality that they just haven’t yet moved into Sierra–things like system options and certain circulation settings. They will begin moving those things into Sierra starting with phase 2 of Sierra development with the intent to eventually completely remove the telnet interface.

But, there will still be a full working version of the telnet interface tied to the Millennium client.

Back to top

Q: Is there a date by which we need to stop making changes to Millennium?

A: No. Even though the Sierra database will start building on December 14th, it will remain in synch with Millennium until the time Millennium is taken down on January 23rd for the final switchover.

Back to top

Q: Will patron loads work the same with Sierra?

A: Yes. We’ll need to start using Data Exchange instead of telnet for patron loads, but there’s not much difference.

Back to top

Q: Will the Music Special Collections database that contains, e.g., the WFAA/WBAP collections continue to work in Sierra?

A: It will still be available as it is now for the foreseeable future. The web interface will still be up on port 81. The telnet interface will still be available via the Millennium client that runs on top of Sierra. We will just need to make sure there is a workstation in music that’s set up with the Millennium client so it can be kept up-to-date.

Back to top

Q: Will the Output Vouchers and PVE system still work in Sierra?

A: The “Output vouchers” feature will also transfer to Sierra as-is, so the PVE system should work the same way in Sierra. We will discuss this with Lib TACO before the migration to make sure.

Back to top

Q: Will LDAP / single sign-on features still work in the WebPAC in Sierra?

A: Yes. Users will still be able to log into their accounts in the WebPAC using their EUIDs via LDAP.

Back to top

Q: Will the self-checkout stations continue to work in Sierra?

A: Yes. There will be small configuration change needed, but they will continue to work.

Back to top