How to create your own Libapps in LibX 2.0

 Posted by on February 11, 2014
Feb 112014
 

In LibX 2.0, all code that runs in pages (for autolinking, etc.) is based on LibApps. You can see the LibApps running in your edition by selecting the “LibApps” tab in the Preferences.

It is possible to create your own LibApps via the LibApp Builder. The LibApp builder is a web interface, similar to the edition builder, that allows anyone to create modules, libapps, and packages. It uses a separate sign up than the edition builder, so you have to create a separate account.

To build your own Libapps, you’ll need to learn about packages, libapps, modules, and feeds. The best and most comprehensive documentation we have is Sony Vijay’s MS thesis. Sony is the primary author of the Libapp Builder.

Put briefly, a module is a small piece of JavaScript code that runs in a page. Multiple modules operate together in tandem to perform a function, this is called a LibApp. Packages are collections of LibApps (as well as other packages). Packages, libapps, and modules form a hierarchy – a tree, in CS terminology. Each package, LibApp, or module is describe by a unique URL at which it can be found. Here are some examples:

The LibApp that links ISBNs can be found here. It is really just a description of the modules it contains, for instance, this one. This LibApp is part of a package, which is found here.

The LibApp builder allows you to create, share, modify, and publish package, LibApps, and modules, without needing to understand the internal (XML) format you find in the links above.

What, then, are feeds? Feeds are a vehicle to serve packages, LibApps, and modules. Each of them is stored inside a feed, based on the AtomPub specification. That’s why we refer to them collectively as ‘entries’ (see atom:entry). A feed may contain multiple entries. But note that a package or LibApp may be composed of entries from multiple, different feeds. So for instance, you can create a new LibApp in a new feed you create, but it can refer to (and thus use) modules contained in other feeds (such as the LibX core feed, which we maintain).

To use the LibApp builder, you thus need to create a feed, and at least one package, one LibApp inside the package, and then you can add modules to it. It also includes a search interface so you can include modules others have created. For more information, read Sony’s thesis.

LibApps can be tested right from the LibApp builder. If you have LibX installed, it’ll tell LibX to temporarily download your LibApp code and run it. Once you’re satisfied, you can “publish” it, which freezes it and puts it at its final location.

If you’re an edition maintainer, you can subscribe your users to packages you trust. Since LibApps can do things that are potentially sensitive, we do not offer a search interface for LibApps and package that were created by just anyone (though anyone can create any LibApps), but rather only by users we trust. Nonetheless, as an edition maintainer, you can subscribe your users by specifying the URL of the package you want them to subscribe. Note that you need to specify the package URL, not the location of the feed. For instance, the LibX core feed is at libx.org/libx2/libapps/, but the LibX core feed is at http://libx.org/libx2/libapps/libxcore.

We’d love for people to give it a try.

I’ll close with a small concern of mine. While we believe in the power of LibApps and the opportunities they provide, we are a little concerned that the programming model of packages, LibApps, and modules may be a bit confusing to novices. I do note, however, that it is possible to create single-module LibApps, in which all JavaScript code resides in a single module. These are, in essence, similar to Greasemonkey scripts.

Enhancing Search Engines with Summon

 Posted by on February 27, 2013
Feb 272013
 

The very first version of LibX provided a cue on the google.com page that, when clicked, led to the user’s library catalog. While this cue is no longer shown, we now have an even cooler feature for those LibX editions that use Summon as their primary catalog.

LibX users have the option of viewing results from their Summon instance simultaneously when they search in  Google, Yahoo or Bing. Whenever a user searches for content in these popular search engines, the search is repeated in Summon so that the user can have Summon results, which includes carefully selected and licensed resources, at their fingertips. To avoid directing unnecessary traffic to Summon, the user can turn this feature off and on using a ‘research mode’ slider (use a single click on the slider).

If results are found, a popup appears with how many results were found; clicking on the popup leads the user to the results found, as shown below for Google, Yahoo, and Bing. As for other LibX Libapps that incorporate Summon, editions may use either the Summon Widget service or the Summon API (via proxy), as described here and here.

We can include this feature in other pages where cosearching Summon would make sense – let us know what these are!

Google.com


Bing.com

Yahoo.com
This feature has been developed by Anand Swaminathan (anand12100@gmail.com).

Enhancing Autolinking with Summon

 Posted by on February 27, 2013
Feb 272013
 

LibX has always supported autolinking for identifiers such as ISBNs, ISSNs, DOIs, and others.  When LibX believes that a page contains such identifiers, it will place a link where they are located on the page. Clicking on the link will lead the user to a search using that identifier in the edition’s primary catalog.  (The primary catalog is the one listed first in the list of catalogs by the edition maintainer.)

In addition, if the user hovers over the link, a tooltip appears that displays additional information about the item to which the identifier refers. LibX uses services such as xISBN, xISSN, or CrossRef’s and Pubmed’s APIs to retrieve metadata about the item, such as the title, author, publication year, and others.

LibX editions in which Summon is configured as the primary catalog will go even further: when the user hovers over the link, LibX will contact that library’s Summon instance to search for the item in Summon. The results of this search are directly displayed in the tooltip, as shown below.

To contact Summon, LibX has two options, which we call “Summon Widget” and “Summon API (via proxy)”.  The Summon Widget service is less detailed and does not show circulation information, but can be used immediately by any Summon customer.  The Summon API (via proxy) requires an API key and it requires that you run our proxy on your machines where the API key is located, but it provides more detailed information. The Summon API also requires that the URL of the Summon proxy be included in the edition configuration.

Please note that the enhanced autolinking feature is available only if Summon is configured as an edition’s primary (i.e., first) catalog. (Otherwise, the autolink would lead to a different location than what appears in the tooltip, misleading the user).

The enhanced autolinking feature was developed by Anand Swaminathan (anand12100@gmail.com).

Below are screenshots for autolinks around ISBN, ISSN, DOIs, and Pubmed Ids found on different pages. Note that for ISBNs, LibX searches Summon for all editions listed by the xISBN service, not just the one hyperlinked. The screenshots show the results when the Summon Widget service is used.

Autolinks for ISBN

Autolinks for ISSN

Autolinks for DOI

Autolinks for PubMed

Aug 062012
 

Update 10/4/2012: LibX is now in the Chrome Webstore!

If a user installs directly from the webstore, they won’t have an edition activated.

To ensure that your users will activate your edition upon install, follow these instructions.
___

Update 10/3/2012: We are really close to making LibX for Chrome comply with manifest v2, expect it to appear in the web store soon. Ironically, after we were 90% done with the necessary changes – converting from the eval-based JsPlate to the eval-free AngularJS framework, Google reneged on their prohibition of eval() – it will be reallowed in future versions of Chrome.

___

LibX for Chrome is currently broken, and it’ll take a long time to fix it. Use LibX for Firefox instead.

Google really took us by surprise. The changes to LibX to conform to Chrome’s expectation would be tremendous, and at this point we cannot say how/if we can make them.

___

As of 7/31, Google changed how to install extensions in Google Chrome.  Previously, LibX users could click on a link with a .crx file and the extension would be downloaded and installed. According to the new policy, users can no longer simply click. If a user clicks, they will see this instead:

Users then have to download the .crx file, save it into a folder, and then drag-and-drop it into the extension tab, as described under “Steps on adding extensions from other websites“.

Obviously, this is an unsatisfactory situation. We are currently investigating whether it is possible to make LibX available via the Chrome Web Store.

Edition Recommendation System

 Posted by on July 6, 2012
Jul 062012
 

We are now introducing the edition recommendation system to LibX to make it even easier to find the correct edition for your university. Whenever you visit the LibX home page, a list of editions will be automatically generated based on your IP address that are linked to your university. You can click a link to load the LibX edition inside the page, and from there you can install it with the install button.

The libx.org home page with the edition recommendations (in this case, just Virginia Tech) shown.

This system is also present inside the LibX plugin. Clicking on the “change edition” link inside the plugin shows the recommended editions in addition to the standard search box. Again, this works based on your IP address.

The LibX plugin showing the same recommendation list.

How to set up LibX with the Summon API

 Posted by on June 25, 2012
Jun 252012
 

A key goal of LibX 2.0 is to integrate with services such as Summon, which provides an API. Whereas LibX 1.5 mostly provided links a user could click on to initiate a search, LibX 2.0 aims to provide the resulting information directly to the user.

To contact Summon, LibX has two options, which we call “Summon Widget” and “Summon API (via proxy)”.  The Summon Widget service is less detailed and does not show circulation information, but can be used immediately by any Summon customer.  The Summon API (via proxy) requires an API key and it requires that you run our proxy on your machines where the API key is located, but it provides more detailed information. The Summon API also requires that the URL of the Summon proxy be included in the edition configuration.

An example is shown in this short screencast (0:47) which demonstrates live how Summon is contacted when the user hovers over an autolinked ISBN, as shown below:

 

If your institution subscribes to Summon, your edition can make use of these services as well.

As pointed out above, nothing needs to be done if you’re content with using the Summon Widget API, except you must make sure that Summon appears in the first position in the list of catalogs.

If you wish to use the more detailed Summon API (via proxy), you are required to install a proxy service that LibX can contact to search Summon via the API. Unfortunately, such a proxy is necessary because accessing Summon via the API requires a key, and this key must be hosted securely on a server belonging to your institution. Fortunately, it is very easy to set up. All you need is an Apache server that can run PhP scripts, and you’re good to go. All you need to do is to drop the PhP scripts provided into some directory, add the key. Full  instructions are on this page.

Then, you’ll have to tell LibX where to find the service. This is also described there.

If anything isn’t working, don’t hesitate to contact us at libx.org@gmail.com

If you have ideas where to include Summon results, let us know!

Reading New York Times articles with LibX

 Posted by on June 21, 2012
Jun 212012
 

Stephen Francoeur asked on the LibX mailing list about the New York Times Libapp that allows users to read NY Times articles through their institutional subscription.  Here’s what it currently does. When a user visits a NY Times page and the paywall goes up, a display appears offering the user to look for this article in Lexis Nexis. This idea is based on work by James Van Mil at U Cincinnati Libraries.

It looks like this for this article. Note the gray box on the top.

When the user clicks on this box, a search is issued against Lexis Nexis using the byline, the heading, and the date of the article.

If the activated edition has a proxy, the provided link is proxied, else a direct link is provided.

LibX tries its best to follow the specification provided by Lexis Nexis for how to create URLs. For instance, it strips out “unsearchable” words such as “the”, “this”, “a”, “not”.

The notification will not appear unless the page refers to an in-print article or editorial of the New York Times. (You can check this for yourselves by looking at the source code – it must contains a tag <h6 class="metaFootnote">A version of this article appeared in.... As future extension, we could implement looking up articles in other papers with whom the Times has a partnership or owns, such as IHT.)

Readers are invited to relay their experiences with searching for the New York Times in Lexis-Nexis (what works, what doesn’t), as well as with other sources that index NY Times articles and how to use them. Note that this LibApp doesn’t rely on any edition maintainer information, it simply displays a link to Lexis-Nexis. We could add other providers to which a portion of LibX users is likely to have access.

Here are some URLs I’ve tested this application on:

How The Deficit Got This Big, July 24, 2011.

Wooing the First Dresser, February 12, 2012.

PS: the name “Paywall Buster” is of course misleading since this LibApp, unlike some rogue user scripts, doesn’t actually restore the page content for users without subscriptions.

New LibX Blog

 Posted by on January 17, 2012
Jan 172012
 

In this blog, we’ll be reporting about our work on LibX. Each post will highlight a feature and/or development. The purpose of the blog is to create a record of our work on LibX and share it with the public (our users and maintainers), but also to provide an area for references and discussion. Each blog post will allow the posting of comments.

© 2012 LibX Project
LibX is a joint project of the University Libraries and the Department of Computer Science at Virginia Tech.
Generous funding for LibX is provided by the Institute of Museum and Library Services.
Suffusion theme by Sayontan Sinha