1. The VAO is operated by the VAO, LLC. Alternative Protocols for Discovery & Access Mike Fitzpatrick NOAO

2. May 18, 2010IVOA Interop – Victoria, 2010 22 Cost-Effective Data Management Data Discovery (should) != Data Access Large queries can be expensive Large queries can be confusing Is it working?? I didnt want that much data, but now Im stuck sorting it out is X in the VO Where X can be an object or a data resource Responsive applications Strict versus loose Not everyone has fast internet

3. May 18, 2010IVOA Interop – Victoria, 2010 33 Data Discovery First stop should always be the Registry What search term to use ? How should results be sorted ? What if I have an object name ?

4. May 18, 2010IVOA Interop – Victoria, 2010 44 Data Discovery First stop should always be the Registry, but …. What search term to use ? How should results be sorted ? What if I have an object name ? Inventory Services help in some cases Fast results for large queries (using cached information) But… Not a VO standard (DAL/GWS/etc), it is an Application Currently missing large data collections (Sloan, 2MASS, etc) Catalog services only Can this be easily added as a capability for large providers like Vizier (in fact, already done). What about VOEvent repositories?

5. May 18, 2010IVOA Interop – Victoria, 2010 55 Data Discovery Footprint Services Not generally in wide use, but documents/tools exist Seems like it would be simple to do for curators like Vizier or HEASARC All-Sky data a special case Many catalogs could be footprinted (e.g. Cepheids in M31) Some types of image surveys will work, general pointings from observatory Registry CoverageSpatial entry Not always properly filled out for a resource Client software generally doesnt use it as a result Is this a DAL issue? Is it a Registry issue? What about Apps?

6. May 18, 2010IVOA Interop – Victoria, 2010 66 Responsive Applications Whyis this a DCP issue? Reduce load on data provider Users will make their own judgments about the good and bad data sources in VO What are the problems? Large queries which take time to process,…and then timeout Large VOTable documents that take time to return over a slow network Lack of metadata in response E.g. no WCS/filter/depth info in SIA result hinders client selection of data

7. May 18, 2010IVOA Interop – Victoria, 2010 77 Responsive Applications What can be done to help? Proxy services? Could compress results for faster access (a la Opera/Chrome) Could remediate bad practices (old standards) Could provide automatic fail-over for high-value resources Could enrich default metadata (e.g. bump up VERBOSE) But, is this then a shadow VO? What if it was an App? Better use of existing standards Wider use of STREAM or BINARY in VOTable over text XML Should Inventory be a VOSI capability ?