Helioinformatics Project: Faceted Search and Inferencing

Background and Motivation

Astronomy is among the fields of scientific endeavor that have recently begun to generate data on a massive scale. A prime example of this data-intensive astronomy is the Large Synoptic Survey Telescope, LSST. Bearing a 3 gigapixel digital camera, the LSST is planned to output 30TB nightly. And, even sooner than the LSST, within a few months the Solar Dynamics Observatory will be launched. As its name implies, the SDO will bear instruments to observe the sun, very powerful instruments which will output up to 2TB of data a day.

Over this past summer, I interned at the Lockheed Martin Solar and Astrophysics Lab in Palo Alto, CA. The LMSAL group is greatly involved with the SDO project. As I am a student focusing on software development, Neal Hurlburt, my supervisor, pointed me to a project involving the use of software systems to bring some order and structure to this avalanche of solar data. For my SOS project, I propose to continue working on this system.

Goals

1. Provide professional documentation for my code
2. Develop a faceted search for solar data
3. Develop an inferencing system for solar data

Scope

My software will interact with already-established LMSAL software and hardware systems. It will probably include both server-side, run at LMSAL, and client-side, run on a web browser. The primary audience of my software is solar physicists.

Deliverables

• faceted search interface, in form a web browser-accessible GUI
• recommender engine, maybe incorporate into search engine
• inference engine (maybe)
• documentation

Plan and Schedule

Faceted Search

This project has multiple objectives–I shall first focus on the faceted search. For the faceted search, I am drawing inspiration from the browsing system at Zappos.com. To illustrate what I am planning for the faceted search, I have created a mock-up of the GUI I am planning, though this one is for beverages, rather than solar events and observations.

state 1:

Types of beverages, like types of solar events, can have a wide variety of parameters. Also like solar events, some parameters are applicable to one type but not to others–alcoholic beverages can be further discriminated by whether or not they are fermented or distilled–tea cannot be classified thus. The default interface will present the four or five most “discriminatory” parameters in four or five boxes that have drop-down boxes, for “finite” parameters like “whether beverage is served hot or cold” or text boxes for “non-finite” parameters like “region of creation” (it would be silly to put every city and region in the world in a drop-down menu). If the user desires finer control, the entire set of parameters can be accessed by the “display all parameters” button.

I define degree of parameter discrimination by how well-balanced the types are among the parameters; e.g. if a subset of drinks is 90% non-alcoholic and 50% served hot, hot-cold is more discriminatory than alcohol content. After entering parameters and clicking “Search,” state 2 is reached:

state 2:

After entering the new parameter, the number of drinks is narrowed down. The search box that was just used is then replaced by the most discriminatory parameter to for the new subset.

Recommender Engine

This would probably be like the system at Amazon.com that suggests similar books and movie, though this one obviously for solar events instead. I plan to focus on this part more in spring quarter.

Inference Engine

This would be able to find logically connected observations and events in the system. I plan to focus on this part more in spring quarter.

Schedule