Skip to end of metadata
Go to start of metadata




  • Initial survey of VO standards – which do we need/want to adopt?

Discussion items


  • SUI/T is concerned about efficiency of data transfer with VOTable for large results.
  • VO BINARY2 may be a reasonably performant alternative.  Need to check if reference implementations of ser/des are available for Java, C++, Python.
  • Could we work with IVOA to get an additional encoding officially adopted, based on more contemporary and widely adopted ser/des frameworks (e.g. protobufs or capnproto)?
    • These frameworks have advantages (and disadvantages) of automatic stub generation for multiple languages.
    • Could be generic row-based result protocol; would not have to be touched/changed for every different result row type.  This is done currently for Qserv, where protobufs are used for the wire ser/des for query results flowing from workers to czar.
    • It would be helpful to have a working example to demonstrate efficiency wins to IVOA in order to advocate adoption.  Consider a test based on existing Qserv protocol description.
    • An advantage of getting IVOA adoption is that we could then perhaps dispense with poorly performing encodings which are otherwise currently mandated by IVOA.
  • Tim notes that science pipeline is currently looking at migrating afwtable to astropy; once this is done it is much easier to go from astropy to VOTable.
  • Firefly does have a VOTable parser.


  • IPAC has some very preliminary experience accessing other catalogs via TAP.  IRSA has just published via TAP.
  • IPAC has work on their plate to adapt Firefly to TAP, but hasn't begun this work yet beyond a very simple prototype.
  • IPAC considering/recommending working with Mark Taylor (TOPCAT) in consulting capacity.
  • dbserv will be adapted to TAP; Brian will be undertaking this work.
  • Brian has some preliminary concern about slightly different semantics of sync/async between TAP and Qserv as currently formulated.  We shall see...
  • Need to coordinate this work so we don't break/stall SUI/T pending TAP client-side work.


  • IPAC has a simple ADQL parser in C++.  Qserv team should check this out and see if we could leverage this for upcoming parser work.  Currently targets Oracle, but we will look anyway (wink)


  • Simple cone search, etc. may overlap with imageserv/metaserv.  Should we adapt our services to SIA, include SIA as alternate access method in our services, or advocate the IVOA adopt our protocols here?
  • Tim recommends we also take a look at VO data-link service (as an alternative to SIA hardcoded approach?) for drilling down from catalog results to images.


  • SUI/T will be driving an investigation of this, with respect to L3 user workspaces, etc.
  • There may be some involvement from dbserv though (for example, request that sends query results to L3 workspace rather than streaming results directly to client).


  • MAST and IRSA are considering moving to CAOM
  • Adoption could affect some of our table designs
  • Would need to coordinate this with data production and alert production for L1
  • Maybe something new ("obsserv", "visserv"?)


  • Defines minimal core of VO which must/should be implemented.  May be a good place for us to look first.
  • Mandates some VO registry things.  
    • MAST provides a registry; could we publish into theirs?
      • IPAC/IRSA experience with MAST registry was not positive.
      • Tim mentions that JWST is motivating cleanup/maintenance here, so may be improved/improving.
    • Operational def'n for sucess with registry: can TOPCAT find you?


  • How do we pick VO standards that are well-adopted "winners", vs. new fads that will be dead in a couple years?
    • Could MAST tell us user statistics?
    • Brian might have some folks at Goddard to talk to.
    • XiuQin's experience is that TAP, SIA, SSA are de-facto expected.
  • Bonus lengthy digression into remote-Butler design and issues, a la mode... (wink)
  • Let's have a follow-up meeting at a time when we can get both Gregory and Jacek involved.