blacklight 5.9.4 → 5.10.0

data/doc/Configuration---Solr-fields.md

@@ -1,106 +0,0 @@
-# Discovery configuration
-
-In this section, we will discuss some of the features available to control the discovery experience, including pagination, sorting, and fielded searches.
-
-## Per Page
-
-<img align="right" src="https://f.cloud.github.com/assets/111218/2491030/2ce8acc0-b1d7-11e3-8466-659a1759dde7.png" />
-
-Three configuration options control the behavior of the per-page and pagination controls.
-
-```ruby
-config.per_page # [10,20,50,100]
-config.default_per_page # the first per_page value, or the value given here
-config.max_per_page # 100
-```
-
-The options presented in the per-page dropdown are the values for the `per_page` configuration, in the order given. The `default_per_page` can  be used if you want to offer a default per-page value that isn't the smallest value. Finally, `max_per_page` is used as a sanity check for user-supplied values. 
-
-We can explicitly set the configuration in our `CatalogController` configuration:
-
-<img align="right" src="https://f.cloud.github.com/assets/111218/2491066/6cc93f38-b1d9-11e3-9047-f6beccbb93ff.png" />
-
-```ruby
-class CatalogController
-...
-  configure_blacklight do |config|
-    ...
-    config.per_page = [6,12,24,48]
-    config.default_per_page = 24
-  end
-end
-```
-
-## Sort Fields
-
-You can configure the available sort options. The sort parameter is passed through to Solr, so the value must be a supported [sort format](http://wiki.apache.org/solr/CommonQueryParameters#sort).
-
-```ruby
-config.add_sort_field 'score desc, pub_date_sort desc, title_sort asc', :label => 'relevance'
-config.add_sort_field 'pub_date_sort desc, title_sort asc', :label => 'year'
-config.add_sort_field 'author_sort asc, title_sort asc', :label => 'author'
-config.add_sort_field 'title_sort asc, pub_date_sort desc', :label => 'title'
-```
-
-#### An aside about Blacklight solr field configurations
-
-The Blacklight solr field configuration is very expressive, and supports several different flavors of configuration. These are all functionally equivalent:
-
-```ruby
-config.add_sort_field 'pub_date_sort desc, title_sort asc', :label => 'year'
-
-# for sort fields, the `sort` key contains the Solr sort information. For other fields, the `field` key is used.
-config.add_sort_field :sort => 'pub_date_sort desc, title_sort asc', :label => 'year'
-
-# the "key" (first argument) will be used in user-facing url parameters.
-config.add_sort_field 'year', :sort => 'pub_date_sort desc, title_sort asc', :label => 'year' 
-
-# The block format may be useful when using complex logic in the configuration settings
-config.add_sort_field 'year' do |field|
-  field.sort = 'pub_date_sort desc, title_sort asc'
-  field.label = field.key.humanize
-end
-
-# The array-format allows you to add multiple values at once.
-config.add_sort_field [
-  {sort: 'pub_date_sort desc, title_sort asc', label: 'year}, { sort: '....', ...}
-]
-```
-
-You may choose the format that is appropriately concise and legible in the context of your application and configuration.
-
-The `add_*_field` is appending values to a configuration hash. In some cases, it may be useful to modify that hash directly.
-
-```ruby
-config.sort_fields['year'].label = "Year Created"
-```
-
-## Targeting Search Queries at Configurable Fields
-
-Search queries can be targeted at configurable fields (or sets of fields) to return precise search results.
-
-<img src="https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/search_fields.png" />
-
-```ruby
-    config.add_search_field 'all_fields', :label => 'All Fields'
-```
-
-```ruby
-    # Now we see how to over-ride Solr request handler defaults, in this
-    # case for a BL "search field", which is really a dismax aggregate
-    # of Solr search fields. 
-    
-    config.add_search_field('title') do |field|
-      # solr_parameters hash are sent to Solr as ordinary url query params. 
-      field.solr_parameters = { :'spellcheck.dictionary' => 'title' }
-
-      # :solr_local_parameters will be sent using Solr LocalParams
-      # syntax, as eg {! qf=$title_qf }. This is neccesary to use
-      # Solr parameter de-referencing like $title_qf.
-      # See: http://wiki.apache.org/solr/LocalParams
-      field.solr_local_parameters = { 
-        :qf => '$title_qf',
-        :pf => '$title_pf'
-      }
-    end
-```

data/doc/Configuring-and-Customizing-Blacklight.md

@@ -1,257 +0,0 @@
-There are lots of ways to override specific behaviors and views in Blacklight. Blacklight is distributed as a Ruby gem with a Rails Engine framework built in. All customization of Blacklight behavior should be done within your application (partly as good practice, but also to not lose your changes with every new Blacklight release).
-
-If you find that there is no other way to make your customization, please describe your problem on the [[mailing list|http://groups.google.com/group/blacklight-development]] -- we'll do the best we can to help out, and even make changes to Blacklight as needed. If you are interested in contributing code to Blacklight, see the [[Contributing to Blacklight]] page.
-
-## Configuration
-
-
-Blacklight provides a Ruby on Rails -based interface to the Apache Solr Enterprise Search Server. More information about Solr is available at the [[Solr web site|http://lucene.apache.org/solr/]]. In order to fully understand this section, you should be familiar with Solr, ways to index data into Solr, how to configure request handlers, and how to change a Solr schema.  Those topics are covered in the official [Apache Solr Tutorial](http://lucene.apache.org/solr/tutorial.html).
-
-Although the out-of-the-box Blacklight application is configured to work with library MARC-based data, the configuration is easy to extend and modify to meet other needs.  **All of these configurations for facet fields, index fields, solr search params logic, etc. go in your CatalogController**.  By default, this will be located at *app/controllers/catalog_controller.rb*  
-
-**Note:** While it is sufficient to have just one CatalogController, You can actually create multiple variations of the catalog controller (ie. MusicCatalog, DvdCatalog), each with its own configuration settings and URL routing.
-
-Once you have your Solr fields, you can then configure your Blacklight application to display arbitrary fields in different contexts
-
-### Choose which Fields to Display in Search Results
-
-* Displayed fields and labels can be customized on both the search results and document views.
-Note that these must be STORED fields in the Solr index.
-
-```ruby
-    # [from app/controllers/catalog_controller.rb]
-    # solr fields to be displayed in the index (search results) view
-    #   The ordering of the field names is the order of the display 
-    config.add_index_field 'title_display', :label => 'Title:' 
-    config.add_index_field 'title_vern_display', :label => 'Title:' 
-    config.add_index_field 'author_display', :label => 'Author:' 
-    config.add_index_field 'author_vern_display', :label => 'Author:'    
-```
-
-### Targeting Search Queries at Configurable Fields
-
-* Search queries can be targeted at configurable fields (or sets of fields) to return precise search results. Advanced search capabilities are provided through the [[Advanced Search Add-On|https://github.com/projectblacklight/blacklight_advanced_search]] 
-[[https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/search_fields.png|frame|alt=Search fields in action]]
-
-```ruby
-    # [from app/controllers/catalog_controller.rb]
-    # Now we see how to over-ride Solr request handler defaults, in this
-    # case for a BL "search field", which is really a dismax aggregate
-    # of Solr search fields. 
-    
-    config.add_search_field('title') do |field|
-      # solr_parameters hash are sent to Solr as ordinary url query params. 
-      field.solr_parameters = { :'spellcheck.dictionary' => 'title' }
-
-      # :solr_local_parameters will be sent using Solr LocalParams
-      # syntax, as eg {! qf=$title_qf }. This is neccesary to use
-      # Solr parameter de-referencing like $title_qf.
-      # See: http://wiki.apache.org/solr/LocalParams
-      field.solr_local_parameters = { 
-        :qf => '$title_qf',
-        :pf => '$title_pf'
-      }
-    end
-```
-
-### Choosing & Configuring Facets
-
-- Faceted search allows users to constrain searches by controlled vocabulary items
-[[https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/search_facets.png|frame|alt=Search facets in action]]
-Note that these must be INDEXED fields in the Solr index, and are generally a single token (e.g. a string).
-
-```ruby
-    # [from app/controllers/catalog_controller.rb]
-    # solr fields that will be treated as facets by the blacklight application
-    #   The ordering of the field names is the order of the display
-    config.add_facet_field 'format', :label => 'Format' 
-    config.add_facet_field 'pub_date', :label => 'Publication Year' 
-    config.add_facet_field 'subject_topic_facet', :label => 'Topic', :limit => 20 
-    config.add_facet_field 'language_facet', :label => 'Language', :limit => true 
-```
-
-Blacklight also supports Solr facet queries:
-
-```ruby
-    config.add_facet_field 'pub_date_query', :label => 'Publication Year', :query => {
-      :last_5_years => { :label => 'Last 5 Years', :fq => "[#{Time.now.year-5} TO *]"}
-    } 
-```
-
-You can also tell Solr how to sort facets (either by count or index):
-Note: setting 'index' causes Blacklight to sort by count and then by index. If your data is strings, you can use this to perform an alphabetical sort of the facets.
-```ruby
-   config.add_facet_field :my_count_sorted_field, :sort => 'count'
-   config.add_facet_field :my_index_sorted_field, :sort => 'index'
-```
-
-
-If you want Solr to add the configured facets and facet queries to the Solr query it sends, you should also add:
-
-```ruby
-    config.add_facet_fields_to_solr_request!
-```
-
-If you have date facets in Solr, you should add a hint to the Blacklight configuration:
-
-```ruby
-   config.add_facet_field :my_date_field, :date => true
-```
-
-This will trigger special date querying logic, and also use a localized date format when displaying the facet value. If you want to use a particular localization format, you can provide that as well:
-
-```ruby
-   config.add_facet_field :my_date_field, :date => { :format => :short }
-```
-
-### Map from User Queries to Solr Parameters
-
-* Blacklight provides flexible mapping from user queries to solr parameters, which are easily overridden in local applications (see [[Extending or Modifying Blacklight Search Behavior]]).
-
-```ruby
-    # [from app/controllers/catalog_controller.rb]
-    # Each symbol identifies a _method_ that must be in
-    # this class, taking two parameters (solr_parameters, user_parameters)
-    # Can be changed in local apps or by plugins, eg:
-    # CatalogController.include ModuleDefiningNewMethod
-    # CatalogController.solr_search_params_logic << :new_method
-    # CatalogController.solr_search_params_logic.delete(:we_dont_want)
-    self.solr_search_params_logic = [:default_solr_parameters , :add_query_to_solr, :add_facet_fq_to_solr, :add_facetting_to_solr, :add_sorting_paging_to_solr ]
-```
-
-> Source: [[./lib/blacklight/solr_helper.rb|https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/solr_helper.rb#L70]]
-
-### Document Extension Framework
-
-The main use case for extensions is for transforming a Document to another
-format. Either to another type of Ruby object, or to an exportable string in
-a certain format. 
-
-An Blacklight::Solr::Document extension is simply a ruby module which is mixed
-in to individual Document instances.  The intended use case is for documents
-containing some particular format of source material, such as Marc. An
-extension can be registered with your document class, along with a block
-containing custom logic for which documents to apply the extension to.
-
-```ruby
-    SolrDocument.use_extension(MyExtension) {|document| my_logic_on_document(document}
-```
-
-MyExtension will be mixed-in (using ruby 'extend') only to those documents
-where the block results in true.
-
-Underlying metadata formats, or other alternative document views, are linked to from the HTML page <head>. 
-
-# Customizing the User Interface
-## Layouts 
-
-The built-in Blacklight controllers all by default use a Rails view layout called "blacklight", that lives in the Blacklight source. This ends up being a bit confusing, but is the best way we have at present to have out of the box default using a layout with full functionality, without stepping on a possibly existing local 'application' layout. 
-
-To change what layout the Blacklight controllers use, simply implement a method #layout_name in your local application_controller.rb that returns the name of the layout you'd like them to use. 
-
-```ruby
-# [from app/controllers/application_controller.rb]
-class ApplicationController < ActionController::Base
-  ...
-    def layout_name
-       "application"
-    end
-  ...
-end
-```
-
-When implementing your own layout instead of using the stock one, you may want to look at the Blacklight [app/views/layouts/blacklight.html.erb](https://github.com/projectblacklight/blacklight/blob/master/app/views/layouts/blacklight.html.erb) file to see what helper methods are called there, to maintain full Blacklight functionality you may want to call these same helper methods. 
-
-* `render_head_content` renders content within the
-  html `<head>` tag, which includes document-specific alternative
-formats as well as tags generated by plugins, etc.
-* `sidebar_items` renders features including sidebar content, e.g. facet
-  lists.
-* flash messages
-* user util links
-
-## Overriding Views (templates and partials)
-As a Rails Engine, you can easily override views in your app. You can see what views and partials are provided by looking in [[./app/views|https://github.com/projectblacklight/blacklight/tree/master/app/views]] inside the Blacklight source.
-
-Once you find the view you'd like to change, you should create a file with the same name and relative path in your own application (e.g. if you wanted to override [[./app/views/catalog/_show_partials/_default.html.erb|https://github.com/projectblacklight/blacklight/blob/master/app/views/catalog/_show_partials/_default.html.erb]] you would create ./app/views/catalog/_show_partials/_default.html.erb in your local application. Frequently, you will start by copying the existing Blacklight view and modifying it from there.
-
-It is generally recommended that you override as little as possible, in order to maximize your forward compatibility. Look to override either a small, focused partial template, or a helper method of partial template called from a larger template, so your application's version can call out to those same helpers or partial templates within blacklight core code. 
-
-## Overriding the CatalogController
-Overriding the Blacklight `CatalogController` implementation is easy, and the skeleton of the `CatalogController` is generated into your application for you when you install Blacklight. 
-
-See the [[Extending or Modifying Blacklight Search Behavior]] for tips and approaches to customizing the catalog.
-
-## Overriding Other Controllers
-
-1. Find the controller you're interested in blacklight's app/controllers/  . 
-2. Create a file with the same name in your local app/controllers. 
-3. This file requires the original class, and then re-opens it to add more methods.
- 
-```ruby
-require "#{Blacklight.controllers_dir}/some_controller"
-
-class SomeController < ApplicationController
-   # custom code goes here
-end
-```
-
-In that "custom code goes here", you can redefine certain methods (action methods or otherwise) to do something different.  You can also add new methods (again action methods or otherwise), etc. 
-
-It's kind of hard to call 'super' to call original functionality: 
-
-* the ruby language features here make 'super' unavailable, although you can work around that confusingly with the rails #alias_method_chain method. 
-* but more importantly, action methods in particular don't really suit themselves to being over-ridden and called by super, because the original implementation often does something you'd want to change but there's no easy way to 'undo' -- calling 'render', which can only be called once. 
-
-So basically, if you find yourself wanting to access some functionaltiy in the original implementation of a method that you also want to over-ride -- the best solution is probably to refactor Blacklight core code to put that functionality in a subsidiary method, so you can over-ride the action method entirely but call that logic from core.  Action methods should be short and sweet anyway. 
-
-
-## Custom View Helpers
-
-(This is accurate for Blacklight 3.1.1 and subsequent. Before that, things were messier). 
-
-One of the most common things you might need to do is create a view helper -- especially to override some Blacklight behavior implemented in it's own view helpers. The first step is looking at Blacklight source to determine what view helper method you want to override. 
-
-Blacklight comes packaged with several view helper modules. There is a BlacklightHelper in (blacklight source) app/helpers/blacklight_helper.rb , and several others that correspond to specific controller. (Note, depending on version of Rails and configuration, all helpers may get loaded for every request, even ones that are named to correspond only to a particular other controller). 
-
-If you simply created a local helper with the same name as a helper in Blacklight, that will end up preventing the Blacklight helper from being loaded at all though, which is not what you want to do to override. 
-
-We've structured each Blacklight view helper module into two parts to make it easy to selectively over-ride methods. For instance, here's Blacklight's app/helpers/blacklight_helper.rb:
-
-```ruby
-module BlacklightHelper
-  include Blacklight::BlacklightHelperBehavior
-end
-```
-
-Now, the actual methods will be found in app/helpers/blacklight/blacklight_helper_behavior.rb instead. 
-
-If you want to over-ride a helper method, copy the wrapper blacklight_helper into your local app, with the 'include' line, and now you can individually over-ride methods from BlacklightHelperBehavior, and the other methods you don't over-ride will still have their default implementation. 
-
-YOUR `app/helpers/blacklight_helper.rb`
-
-```ruby
-module BlacklightHelper
-  include Blacklight::BlacklightHelperBehavior
-
-  def application_name
-    "Bestest University Search"
-  end
-end
-```
-
-One helper you might want to over-ride for customization is #render_document_partial (currently defined in [[blacklight_helper|https://github.com/projectblacklight/blacklight/blob/master/app/helpers/blacklight_helper.rb]]), which you can over-ride to choose different local partial views to display a document on search results or detail page, possibly varying depending on type of document according to your own local logic. 
-
-## Adding in your own CSS or Javascript
-
-Within your local application, you can use the [[Rails Asset Pipeline|http://guides.rubyonrails.org/asset_pipeline.html]] to manipulate javascript and css documents.
-
-**todo??** better instructions for over-riding BL's built in CSS using SASS? (jrochkind thought jamesws wrote such already, but can't find them now)
-
-The Blacklight generator added a file to your app at `./app/assets/stylesheets/blacklight.css.scss`, elements of the BL default theme can be customized or over-ridden there. If there's something you want to do but aren't sure of the best way, feel free to ask on the listserv. 
-
-
-## See also
-
-* [[Extending or Modifying Blacklight Search Behavior]]
-* [[Pagination]]

data/doc/Configuring-rails-routes.md

@@ -1,13 +0,0 @@
-If your solr ids happen to have dots in them, Rails is going interpret the dots as the separator between the file name and the file exension, and your documents won't be displayed on the show view.  In order to fix that you can override the default routes like this:
-
-```ruby
-ALLOW_DOTS ||= /[a-zA-Z0-9_.:]+/
-MyApp::Application.routes.draw do
-  root :to => "catalog#index"
-  ...
-  resources :catalog, :only => [:show, :update], :constraints => { :id => ALLOW_DOTS, :format => false }
-  Blacklight::Routes.new(self, {}).catalog
-end
-```
-
-you must put the line defining the route with the constraints before you call Blacklight::Routes because the first route that matches is the one that will be used.

data/doc/Contributing-to-Blacklight.md

@@ -1,43 +0,0 @@
-# Contributing to Blacklight
-
-Blacklight is a collaborative, open source project produced by developers from many diverse  organizations. The Blacklight developers want to create an out-of-the-box framework that is easy to install and get started with, both as a service to the community and in the interests of our own institutions in creating a sustainable project and product.
-
-Development is largely motivated by the needs of each developer’s organization, and we work on the shared project together so we can benefit from the community’s development efforts, experiences building discovery systems, and shared problem solving.
-
-We always welcome contributions from the community, especially to add new features, address bugs or defects, and clarify existing code for future developers.
-
-## Adding a ticket
-Let us know you're interested in working on a feature by filing a ticket in our [[issue tracker|https://github.com/projectblacklight/blacklight/issues]].  
-
-## Making Your Changes
-
-* Fork the project
-* Start a feature/bugfix branch
-* Commit and push until you are happy with your contribution
-* Make sure to add tests for it. This is important so we don't break it in a future version unintentionally.
-* After making your changes, be sure to run the [[Blacklight tests|Testing]] to make sure everything works. 
-* Submit your change as a [[Pull Request|http://help.github.com/pull-requests/]].
-
-## Support
-If you are interested in working on the Blacklight plugin, but want guidance or support, please send an email to our [[Blacklight-development mailing list|http://groups.google.com/group/blacklight-development]] and we'll be glad to help.
-
-## Becoming a Committer
-
-Anyone can contribute to Blacklight using pull requests, the issue tracker, and being active on the mailing list and IRC channels. Being a contributor means that you take an active interest in the project and contribute regularly in some way, ranging from asking sensible questions (which documents the project and provides feedback to developers) to providing new features as patches. 
-
-If you become a valuable contributor to the project you may be invited to become a committer.  Blacklight code contributors become committers after being sponsored by one of the current active committers.  The committers will take an Apache-style (+1/0/-1) vote to elevate them, and then a formal invitation will be extended to the contributor. 
-
-Committers should be:
-
-- technically adept
-- constructive, positive members of the Blacklight software community
-- committed to producing useful, practical code for the community
-
-You're expected to:
-
-- contribute patches and new functionality to Blacklight and other shared development efforts (RSolr, Blacklight plugins, etc)
-- actively participate in technical discussions on the email list, IRC, and github
-- answer user support questions via the various channels
-- review pull requests from fellow committers and the community
-- test-drive new release candidates against your own institution's Blacklight applications
-- participate in regular committer meetings, usually in the form of conference calls, to coordinate development & direction

data/doc/Examples.md

@@ -1,120 +0,0 @@
-## Out of the Box Demo
-
-You can see a demonstration of the generic Blacklight plugin at http://demo.projectblacklight.org
-
-## Implementations
-
-### Agriculture Network Information Center
-http://www.agnic.org/search
-
-### American Legislative and Issue Campaign Exchange (ALICE)
-http://alicelaw.org/
-
-### Archive Engine West
-http://aew.orbiscascade.org
-
-### Bibliothèque Clermont Université 
-http://195.221.120.231
-
-### Columbia University:
-
-* CLIO - Unified search and discovery - http://clio.columbia.edu
-* Academic Commons - Institutional Repository - http://academiccommons.columbia.edu
-* Human Rights Web Archive - http://hrwa.cul.columbia.edu
-* Special Collection Site - Lindquist - http://lindquist.cul.columbia.edu
-
-### Cornell University 
-http://newcatalog.library.cornell.edu/
-
-### Danmarks Tekniske Universitet (Technical University of Denmark)
-DTU Findit - http://findit.dtu.dk
-
-### Indiana University Libraries
-* IUCAT library catalog - http://iucat.iu.edu/
-* Digital Collections Search - http://webapp1.dlib.indiana.edu/dcs/
-
-### Johns Hopkins University Libraries (Catalyst)
-http://catalyst.library.jhu.edu
-
-### Lowcountry Digital Library (College of Charleston)
-* http://lcdl.library.cofc.edu/
-* Code4Lib Article - http://journal.code4lib.org/articles/8327
-
-### The National Library of Medicine's Digital Collections
-http://collections.nlm.nih.gov
-
-### NCSU Libraries' Digital Collections: Rare and Unique Materials
-This application superseded the Historical State application which was also a Blacklight application.
-http://d.lib.ncsu.edu/collections/
-
-### The New York Public Library
-
-* Andre Studios 1930-1941 - http://andrestudios.nypl.org 
-* Prints & Photographs Online Catalog - http://wallachprintsandphotos.nypl.org/
-
-### Northwestern University Library Archival and Manuscript Collections
-http://findingaids.library.northwestern.edu
-
-### NRM (Natural Resource Management) knowledge online
-http://nrmonline.nrm.gov.au/
-
-### The Pennsylvania State University (Penn State)
-https://scholarsphere.psu.edu/
-
-### Rock & Roll Hall of Fame
-http://catalog.rockhall.com/
-
-### Stanford University
-
-* http://searchworks.stanford.edu (catalog) / https://github.com/sul-dlss/SearchWorks
-* http://bv.stanford.edu (finding aid for special collection) 
-* http://frda.stanford.edu (full text plus image collection) / http://github.com/sul-dlss/frda
-* http://revslib.stanford.edu / http://github.com/sul-dlss/revs
-
-### Tufts University
-http://dl.tufts.edu
-
-### University of Miami
-https://library.miami.edu/udvd 
-
-### University of Virginia
-http://search.lib.virginia.edu
-
-### University of Wisconsin-Madison
-http://search.library.wisconsin.edu/
-
-### United States Holocaust Memorial Museum
-http://collections.ushmm.org
-
-### WGBH Open Vault
-http://openvault.wgbh.org
-
-### University of Hull
-
-* Institutional repository
-    http://hydra.hull.ac.uk
-* Library catalogue
-    http://libsearch.hull.ac.uk/
-    https://github.com/uohull/blah
-
-### Universiteitsbibliotheek Gent (Ghent University Library, Belgium)
-http://lib.ugent.be
-
-### The World Maritime University (using Koha ILS )
-http://beacon.wmu.se
-
-### Yale University
-* Collection of Musical Instruments
-    http://collection-media.yale.edu/
-* School of Music media site
-    http://music-media.yale.edu/
-
-
-The UI component of the Hydra Framework - http://projecthydra.org
-
-
-## Media/Presentations
-
-* ["Highly Relevant Search Result Ranking for Large Law Enforcement Information Sharing Systems"](http://www.lucidimagination.com/blog/2011/06/01/solr-and-law-enforcement-highly-relevant-results-can-be-a-crime/), presented by Ronald Mayer of Forensic Logic at Lucene Revolution 2011 - Blacklight was used to quickly provide a proof-of-concept on law enforcement data.
-
-* [Podcast: Project Blacklight, Hydra and Libraries in the Digital Age](http://www.lucidworks.com/blog/podcast-project-blacklight-hydra-and-libraries-in-the-digital-age/) Interview with Bess Sadler for the SolrCluster podcast. Origins of the Blacklight software, the Hydra Project, some of the challenges facing libraries with regard to search and management of digital content, and future Blacklight development projects like Spotlight and GeoBlacklight are discussed.