Child pages
  • Federated Search
Skip to end of metadata
Go to start of metadata

The federated search system will work the same as any individual collection's search system. Due to inconsistencies in field usage, a small set of fields will be used on the results page. We may want to concatenate some fields into a "citation" if actual fielded data isn't consistent enough (but eventually, we should be able to use the DC representation for this). Links from the results page will always be PURLs, which will direct the user to the details page in the object's primary collection.

Work to do:

  • (UI Designer) Design an "ideal" interface
  • (Ryan) Clean up implementation of SRU server, release it
  • (Ryan/Randall) Identify portions of the ideal interface that we can implement easily and implement them
    • (Ryan) Determine how to convert current metadata for use with result pages
  • (Ryan) Identify portions of the ideal interface that have low cost/benefits, put them into the schedule
  • (Ryan/Randall) Find out what is necessary to integrate this search with the main library search system

Fields to include in result pages:

  • title
  • type of document
  • host collection
  • date
  • creator (if useful/available for this collection)

Open questions

  1. Is it worth the effort to create a completely separate rendering for each collection or object type on the primary results page?
  2. How do we deal with "thumbnails" for audio and video?
  3. Do we need a "mini" federated search system for images, or should we just provide a way to restrict searches in the "main" federated search system? (Same question applie to textual content and other media types.)
  4. How best to make everything Google-able? This is a somewhat different type of federated search, but it may be useful to compare our "real" federated search with a Google search restricted to dlib.indiana.edu. For example, should we make detail page titles more Google-friendly?
  • No labels