The Architecture of a Multitiered Virtual Observatory The VMO

1
The Architecture of a Multi-tiered Virtual
Observatory The VMO

• Todd King1, Jan Merka2, Raymond Walker1, Steven
  Joy1 Tom Narock2

1 Institute of Geophysics and Planetary Physics,
University of California, Los Angeles, CA 2 NASA
Goddard Space Flight Center, Code 672, Greenbelt,
MD
2
NASA's Heliophysics VxO Universe
VSO
VHO
VITMO
ViRBO
VMO
Figure from Tom Narock
3
The Virtual Magnetospheric Observatory - VMO

• The Virtual Magnetospheric Observatory (VMO),
  part of NASA's virtual observatory effort for
  Heliophysics research, is unique.
• The VMO is lead by two groups one at Goddard and
  the other at UCLA.
• Each group operates as peer virtual
  observatories.
• Each virtual observatory functions as an access
  point to all the VMO resources and services.

VMO-GGoddard
VMO-UUCLA
4
How The VMO Operates

• Collectively the VMOs function as an open source
  development effort which share metadata and tools
  while dividing up tasks in a complementary
  fashion.
• Some examples
• UCLA Goddard
• word search structured search
• ground stations spacecraft
• and spacecraft
• tools data mining
• (parsers, editors) (resource content)

5
The VMO is more

• We have international collaborations
• Some examples
• CANOPUS (Canadian Space Agency)
• ULTIMA (International ground station consortium)
• Participation is open
• Trusted partner network.
• If UCLA and Goddard can work together, then we
  can work with anyone.

6
Basic Concept

• Resource Providers describe their resources using
  SPASE
• Descriptions are harvested and served by a
  Registry Server.
• Registry Servers can be chained in self-declared
  networks.
• A search can enter the network at any point
  circulate the network.
• Results from all sources are blended.

7
A Single Registry

• The simplest network consists of a single
  registry server (node).
• Each registry service has this basic
  configuration.

Resource
Repository
Registry
Access point
Model and Methods
8
Multi-tiered Registry

• One registry can declare that another registry is
  part of its network.
• Any number of "neighbors" is possible.

9
Registry Configuration

• ltRegistrygt
• ltIDgtVMO/Glt/IDgt
• ltDescriptiongtVMO/GSFC resource
  descriptionslt/Descriptiongt
• ltPathgt/volume_vho/mission/metadata/GSFC/obslt/Pa
  thgt
• ltReloadTriggergtreload.txtlt/ReloadTriggergt
• ltExtensiongt.xmllt/Extensiongt
• ltNextRegistrygt
• ltURLgthttp//vmo.igpp.ucla.edu/registry/resource
  Search.jsplt/URLgt
• lt/NextRegistrygt
• ltNextRegistrygt
• ltURLgthttp//vmo.nasa.gov/resourceSearch.jsp
  lt/URLgt
• lt/NextRegistrygt
• lt/Registrygt

May be omittedif access pointonly
10
A Fully Interconnected Network
11
Avoiding Race Conditions

• Suppose A -gt B C and B -gt C A
  and C -gt B A
• If we always pass to the next registry we would
  be in an endless loop.
• This can be avoided by only visiting unvisited
  registries.
• This requires passing the list of visited
  registries along with the query.
• Full search is A -gt B -gt C

12
Optimizing

• Localize decision making
• Search near the source
• Divide search space into smaller pieces
• Set limits for number of responses
• For example, Top 5 hits
• Return count of total matches
• Use metadata effectively
• Avoid drilling into the data.

13
Federated Searches
Number of local matches

• Within the VMO we use the SPASE data model
• Use a single scoring method for word searches
• Have common facets.
• Example User requests top 5 matches.

5
Score, Blend, Select
n
Results from Neighbors
10
Registry
5
5
Results Returned
n
n
14
Query Interface

• Parameters
• resourceID SPASE Resource ID.
• topLimit The number to top hits to return.
• resourceType Constrain to a resource type.
• words list of words to match.
• match How to match words (all/any).
• Other metadata constraints (xpathcriteria)exampl
  e ResourceHeader/Contact/PersonIDx

15
Query Interface - Refinements

• Add ReleaseDate parameter with relational
  constraint.
• Before a date
• On a date
• After a date
• Change xpathconstraint to XQuery
• constraintxquery
• Add selectable facets

16
Example REST Query

• Service name is defined in Registry
  configuration. Lets assume it registry.jsp
• registry.jsp?wordsplasma,data,isse1

17
Returned Results

• Schema
• ltResultsgt
• ltVisited /gt
•   ltMatches /gt
•   ltElapsed /gt
• ltTopLimit /gt
•   ltWords /gt
• ltGroupgt
•   ltTitle /gt
•   ltResourceType /gt
•   ltMatches gt
•   ltShowing /gt
• ltResourceProfile /gt
• lt/Groupgt
• ltResultsgt

Envelope for results
Visited Registry One for each
Total matches found
Time spent
Facet Group
Resource Description
18
How the Pieces Fit

• Web form creates REST query
• Request send to local registry server.
• Which in-turn may send to other neighbors and
  blend results.
• Results are transformed to HTML
• Returned to browser.

XSLT
19
Its Easier Than it Looks

• Theres only one system component.
• Registry Server
• Everything else is either
• Adhering to a standard
• SPASE
• Request
• Response
• Transforming results

20
Compared to OAIS/ISO
21
Compared to ISO
22
Conclusions

• Best with trusted partners.
• Local management
• Eliminates need for active harvesting.
• Query propagates
• Allows parallel execution of queries.
• Each registry server participates
• May improve response time.
• Dividing database into smaller pieces