# IVOA Interop, 20-24 May 2024

## Monday
### Summary of state of IVOA/CSP/TCG

- Couple of mentions of new astroquery modules that I was not aware of (e.g. SKA)

- CSP activities may be of interest of the group (Vandana is part of the committee). Typical topics:
- Basically all lessons leared and difficulties we run into with the archives/data providers could be propoagated back through this group.
- Typical topics of discussions from previous interops
- big data access
- VO friendly parquet
- cloud usage inclusion in e.g. SIA results
- wider TAP adoption
- Heliophysics API
- ...

### Tiger Team pre-interop meeting results

### Apps sessions
#### Monday
Not exactly has relevance for the fornax team.

##### SAMP
- some new chanages in astropy 6.1? How does the affect the move SAMP to pyvo? (who are actually using astropy.samp, do we have any ideas?)
##### MIVOT/CooSys/etc in astropy and pyvo

- Lots of MIVOT, I don't think it's relevant for fornax for now, and if/when it will, it will be seemless for the end users/scientists writing working with notebooks as everything will work internally in the libraries

- MIVOT notebook: how could we include stuff like this in the docs/should we even think about it? Should we expose it for the users (if yes, who is responsible with making sure it keeps working or being fixed if/when issues come up). E.g. we cannot dump it in the NAVO notebooks as it has nothing to do with NASA data.

##### MIVOT in TOPCAT
- irrelevant for the fornax team (likely of interest for firefly people though), lots of complications, there is only manual mark ups for and it's difficult to make the gaia catalog to propagate
- Round tripping is difficult

##### Aladin Lite and VO Standards
- "hipscat with ellipse footprints" --> is this the same hipscat?
- dataling support

##### Rust and VOTables
- what is hips and what the rubin hipscat is not
- VOTable Rust library
- https://github.com/cds-astro/cds-votable-rust. Would be interesting to see if it was possible to swap out the python implementation in astropy to improve the performance or that will never be an option and we better keep patching up what we have
- Cool STC-C --> MOC demo

#### Thursday

### TimeDomain usecase
- https://wiki.ivoa.net/internal/IVOA/InterOpMay2024OpenTCG/TDIG_slides_sydney.pdf
- maybe parquet format
- GW has a very similar use case

### Aussie landscape plenary
#### Data Central
- they have a science platform with jupyterhub and notebooks
- TODO for BMS: check-in with them about testing, if these notebooks are good standing, include that in pyvo/astroquery pointers
- Answer to question: test users only, not on the dozens level yet

#### ASKAP
- SKA flavour, not exactly relevant for fornax, see Gregory's notes in ``mtg-ivoa-202405``
#### MWA
- Another radio array, not exactly relevant for fornax, see Gregory's notes in ``mtg-ivoa-202405``

- No need for ADQL for the most often used query types or joins -- we could rephrase something along these lines for the reasoning for astroquery

#### Theory

#### Gravitational Waves

#### AI driven accelerator trainings by ....
- they already work with ESA and NASA, mostly in Eart Science and Heliophysics. E.g. https://frontierdevelopmentlab.org/fdl2024 and https://trillium.tech/applied
- Interesting example projects about the AUS flodding and landslides, but not sure any of this is relevant/can be relevant for us

## Tuesday

### Radio plenary

#### Gregory's talk
- is IRSA relevant of course
- his mention of CADC cloud based TAP is interesting, but it's vendor locked-in with BigQuery atm, as well as the CADC cloud

#### ASKAP
- Radio, but some of their challeges may be relevant regarding bulk spectral access, cutouts from spectral cubes.
- they have the Parkes pulsar data on S3 already. Not clear if it is accessible via the astroquery casda module, or some other way? This maybe an interesting science use case if we have interesting non-radio overlap?
- cutouts: users request larger cutouts than they expect
- bulk spectra: their challenges may be super relevant. Currenly they serve them individually as a FITS table

#### SKA
- not fornax, but relevant for BMS: astroquery module for SKA

### DAL

#### TAP Next
- new features to come to pyvo
- list tables
- get table metadata (BMS note:maybe this fixes parsing the maxrec=0 responses???)
- create/update/drop table
- load data
- create index
- get/set permissions
- ...

## Wednesday

### P3T
- cost to clients: it has to be able to handle the new style versions. Hopefully everything is transparent for end-users
- Effect on Fornax/NAVO
--> this heavily impacts pyvo, it will have to become a dual-capable client
--> If there is any user API changes, that new style needs to be used in all end-user facing documentation, demo, and examples. E.g. NAVO/Fornax/IRSA notebooks
--> All non client using examples needs to be updated, to help users not stuck on the old style.

Q: can clients help sunsetting?

## Thursday

### ESA datalink talk
- the shout out to scientific platform interoperability is very relevant to the cloud-data-access-API WG's work
- they also started (?) doing parquet files dor gaia DR4

### HiPSCat demo + parquet as votable talk
- both well received
- Mark Taylor was keen to add support for the VOTable metadata containing parquet files to Topcat

- Check-in with parquet people about metadata preservation. --> we need to ensure this new metadata is preserved through various I/O, etc.

### PyVO talk
- many questions, but cut short for photo, etc (the session was running long), and couldn't cover the notebook testing extension part of the talk as the session was running late
- future feature, queries to multiple TAP services and then join them? does this belong to pyvo/astroquery or something else?