Discussion of VO specifications and their implications

Data Management DM Notifications
,
#1

Tl;DR:
We’re discussing VO specifications and their implications on Monday at 11AM PST. This discussion will focus on Data Access and things related to that.

It’d be best if you could familiarize yourself with the specifications, especially those which interest you:
http://www.ivoa.net/documents/

Blue Jeans:
https://bluejeans.com/405802848

@ SLAC:
052-108 (American River)

Summary
The IVOA Virtual Observatory specifications cover a gamut of components and have some interdependence between them.

In order to get a handle what VO means for LSST, we’re kicking off a process with the following goals:

  1. Identify relevant specifications for LSST
  2. Identify their dependencies
  3. Identify relevant integration points and existing implementations
  4. Identify potential conflicts and deficiencies
  5. Identify possible improvements (and advocate for them to IVOA)
#2

Is this discussion intended to cover VOEvent? It’s special in that:

  • We are already committed to support some version of it;
  • It’s not (as far as I know) handled by the Data Access team.
#3

My assumption was that this would only cover VO data access protocols. I would like to know who is really leading the VOEvent/VTP work though…

#4

FYI to others reading this topic:
If you’re fairly new to VO from a data provider’s point of view, like I am, the Deployers section of the IVOA site links to higher level introductions that might be useful reading before diving into specs.

#5

I put together a page of questions that we might want to consider:

https://confluence.lsstcorp.org/display/~gpdf/LSST+VO+strategy+considerations

for a discussion last spring. I think most of the questions are still open. I added a few to represent some more recent offline conversations that we’ve been having in this area.

As noted elsewhere, @davidciardi and I can’t attend today’s meeting, and we are hoping to schedule a follow-up meeting soon, but I hope perhaps those who are at the meeting will find this useful. Confluence comments are very welcome!

#6

See also:

https://confluence.lsstcorp.org/display/DM/VO+interfaces

which was intended to be a top-level page for information on our use of VO technologies in the project.

#7

Meeting notes are now available here: https://confluence.lsstcorp.org/display/DM/Data+Access+Meeting+2016-02-29

#8

Hey @brianv0, @fritzm et al.,

Thanks for the excellent meeting notes!

  • Regarding extending standards – yes, that is definitely an option! If there’s something in the standards that would block us from adopting them (or cause significant performance issues), we can develop fixes/extensions, test them in the field, and submit for standardization. Think SPDY -> HTTP2.
  • You may have already seen this, but there’s (at first blush reasonably engineered) ADQL parser library developed by the CDS folks (http://cdsportal.u-strasbg.fr/adqltuto/; it’s Java).