28 October 2008IVOA Interoperability Meeting --

Baltimore

THE INTERNATIONAL VIRTUAL OBSERVATORY ALLIANCE

TAP/VOTable Registry Interface

Reg 1 – G. Greene

Registry Interface with VOTableTAP Param Demo

NVO Discovery Portal Interfaces

28 October 2008 IVOA Interoperability Meeting -- Baltimore

History• Registry Interface 1.0 Proposed Recommendation

– Programmatic Search Interfaces limited to supporting VOResource and Extension Schemas with SearchResponse Object Types

• SOAP protocol

• Introduced the VOTable Output Format at May 2008 Interop in Trieste– General agreement for supporting the Interface– Nominal case would be Selectable Output Columns– Further Definition Required for NEXT RI version

• Level of completeness, REST? e.g. Utypes, etc.

• Currently VOTable output format preferably supported in non-standard interface for Registry Clients for service discovery– NVO Data Discovery portal

28 October 2008 IVOA Interoperability Meeting -- Baltimore

TAP Registry Use Case • Working Draft DAL protocol for accessing

tabular sets of data – Registry metadata may be stored in RDBMS but not

required– supports VOTable output

• Satisfies the capability of querying selectable columns either as Parametric queries or ADQL

• Caveat as to how to support the registry keyword search method– not TAP standard

28 October 2008 IVOA Interoperability Meeting -- Baltimore

Registry TAP Param Example

• Primary Resource Table containing partial VOResource metadata, demonstrating both SELECT and WHERE with match to identifier field

http://localhost/TAP/tapservice.aspx?REQUEST=ParamQuery&FROM=Resource&SELECT=$ALL

http://localhost/TAP/tapservice.aspx?REQUEST=ParamQuery&FROM=Resource&SELECT=$ALL&WHERE=identifier,*heasarc*

Reuse of Dower/Gillies TAP prototype to demonstrate the registry interface

28 October 2008 IVOA Interoperability Meeting -- Baltimore

NVO Data Discovery Portal RI

• Suite of Applications which Depend on VO Standard DAL service registry search– VOResource schema was considered overkill– Software libraries not available for working with RI, yet

readily available for VOTable

• 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, i.e. standard solution, SOON

• XSL is currently the key for transformation between VOResource to VOTable yet found expensive for large scale search on fine grained content