VOTable interface with Registry

1
VOTable interface with Registry
THE INTERNATIONAL VIRTUAL OBSERVATORY ALLIANCE

• Joint Apps/DM/Registry G. Greene
• Application Registry Clients
• NVO Discovery Portal Interfaces

2
Motivation for App Registry Interface

• Early NVO Science projects demonstrated the
  usefulness of registry programmatic search
  interfaces
• Query registry of centralized resources with
  filters on science qualifications to find common
  services of interest
• waveband, images, catalogs, etc.
• Programmatic interfaces were developed from the
  bottom up using fashionable web services (SOAP)
• Application requirements
• created SimpleResource view of registry
  resources metadata
• Web Service quick uptake, quick growth in
  application client dependencies
• Datascope, OpenSkyQuery, WESIX, VOClient, JAVA
  lib

3
Limitations to Interfaces

• Custom dependency on a specific registry
• Pitfalls of non standard implementation
• Server side WSDL changes resulted in breakage of
  client software
• Mirroring registry alleviated failover concerns
  yet demands resources to fully transition to
  operational support
• Non-standard formats for reference implementation
  produced short term solutions and eventually
  software refitting needed

4
Standard Registry V1.0

• Resource element definition changed to a
  composite hierarchical structure
• Resources CAN represent collections which contain
  multiple different service capabilities (i.e.
  cone, sia, ssa, skynode, s)
• Service Capabilities may have multiple interfaces
• Service Capabilities may have multiple versions
• VOResource schema and associated extension
  schemas include rich namespace management,
  serialization
• Requires development of new software libraries
• Standard Registry Interface v1.0 Search based on
  SOAP protocol
• Eliminates application dependency on single
  registry
• SearchRequest container for VOResourceS
• Exception case is the OAI harvesting

5
NVO Data Discovery Portal

• Interoperable suite of Applications
• Science use case oriented toward location and
  discovery of data through VO DAL services (CONE,
  SIA, SSA, Skynode, etc.)
• Absence of Software libraries for working with
  new Registry Interface services and VOResource
  data model
• Proposal for working with VOTable simplification
  of VOResource
• Recognized this was NON-Standard yet active
  communication and collaboration with RWG
• Defined a set of CORE registry fields that
  discovery applications required, allows for
  optional
• XSLT technology identified for transformation of
  the VOResource data model into a defined
  ResourceVOTable

6
Making Choices Apps Requirements

• Applications requirements prioritized higher to
  achieve science goals
• Move forward and provide psuedo solutions and
  wait for the dust to settle on the RI standards
  evolution
• ?? VOTable TAP registry interface on the
  horizon
• Require a resource service container that may be
  transferrable between web applications
• user state for managing discovered services
• How to find the individual services with
  composite resources gt optional return type
• Rows of resources with multiple interfaces
• Rows of interfaces with redundancy in resource
• Complexity with uniqueness

7
Resource Container

• ResourceVOTable Flat-Field Resource
• Variable Length service interfaces
• delimiters
• Defined set of CORE service metadata elements
  applications require
• e.g. title, ivorn, service type, accessURL
• Programmatic dependencies, software coupling is
  growing
• would prefer non-proprietary standard solution
  before the client technology evolves
• XSL filtering for specific VO protocol
  capabilities to expand on interfaces

8
Services

• Service endpoint viewable in parallel to the
  Registry Interface standard services
• http//nvo.stsci.edu/vor10/riws.aspx
• NVO Registry Interface primary search criterion
• Keyword
• simple predicate (e.g. title like chandra)
• capability (aka Cone, SIA, SSA, )
• Wavelength
• Optional VOTable output handling