### IVOA April 2022 Interoperability Meeting # Hack-a-thon topics Please put here your pitches/ideas for potential topics to develop during the [hack-a-thon session](https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpApr2022Hack) that will take place on Thursday 28 April 2022 on [Gather town](https://app.gather.town/app/PuCDQczUl8pfyXH3/ObAS). Just enter somthing like: ---- ### My topic title (your name here) A short description of the work to be done and goal. ---- Please refer to interop_helpdesk@ivoa.net if you had any question about this page or the hack-a-thon itself. #### ## Hack-a-thon Gather Town "space" 1. PyVO VO-DML API Meeting 1: Thu 28 @ HH:MM 1. Collecting notebooks using PyVO/astroquery Meeting 2: Thu 28 @ HH:MM 1. PyVO/astroquery notebooks Meeting 3: Thu 28 @ HH:MM 3. Boxed ConeSearch Meeting 4: Thu 28 @ 13:30 5. Boxed RegTAP Meeting 5: (postponed?) 7. ProposalDM Meeting 6: Thu 28 @ 15:00 UTC 7. JSON Usage in the VO Meeting Room: Fri 29 @ 14:30 UTC ## Hack-a-thon Topics 1. ### Define pyvo API for accessing VODML information in DAL results (Laurent Michel/Tom Donaldson) Work is progressing on instantiating Astropy objects directly from VOTables annotated with VODML. PyVO seems like the best place to support that work. How should the API look? See the wiki for ([VO Model Annotation Syntax (VOMAS)](https://wiki.ivoa.net/twiki/bin/view/IVOA/DataAnnotation)) 2. ### Finish merge request for automating PyVo releases (Tom Donaldson and PyVO maintainers) [Github action to publish to pypi and test pypi](https://github.com/astropy/pyvo/pull/266) 3. ### Collecting notebooks using PyVO/astroquery (Brigitta Sipőcz) Create readme/dashboard of notebooks that use AND test against pyvo (and astroquery). Modify/add test runs that use the dev versions instead of the latest releases, then link the notebooks to a new dashboard page in the pyVO docs that shows the status of those test runs. Tracking issue for this idea, including CI examples, in the PyVO repo is: https://github.com/astropy/pyvo/issues/314 4. ### Simple Cone Search server bundle (~ Marco Molinaro) The idea is to implement a small package to provide a ConeSearch service to be re-used by newcomers to test curation and deployment. An idea could be to start out of [Simple Cone Search Creator](https://github.com/tboch/Simple-Cone-Search-Creator). 5. ### TAP container with RegTAP support (Marco Molinaro, Grégory Mantelet, Markus Demleitner) __NOTE__: it's possible it'll happen _outside_ formal hack-a-thon scheduled time. Try to containerise ([VOLLT/TAPLib](https://github.com/gmantele/vollt)?) a TAP service giving it the ability to deploy a RegTAP interface. To be re-used later for a sandbox Registry in publishing tutoring events. [Markus: The big one here is, I'd say, the harvesting and ingestion infrastructure, which is totally unconnected with pyvo... Of course, if you get the table content from somewhere else, that may be an option. But frankly: apt install gavodachs2-server; cd /var/gavo/inputs; svn checkout http://svn.ari.uni-heidelberg.de/svn/gavo/hdinputs/rr/; dachs imp rr/q create gives you a full RegTAP mirror...] 6. ### ProposalDM Hacking (Paul Harrison) There will have been a formal presentation of the state of the [ProposalDM](https://github.com/ivoa/ProposalDM) the day before, but time for discussion will have been limited. This session will offer the opportunity to cover topics such as; * Using the tools associated with creating ProposalDM * Extending and refining ProposalDM * writing tests for particular observatory use cases (that exercise the model) * examining structures and concepts within the model * Relationships with other efforts * other exisiting IVOA data models * new small data model that could be created e.g. Source DM. * semantics efforts - see for example [discussion on "facility"](http://mail.ivoa.net/pipermail/semantics/2022-February/002965.html) ### 7. JSON Usage in the VO? * JSON tooling is improving all the time whereas XML tooling is fairly static. * Should IVOA start planning a future where JSON is supported? Is the intent for IVOA to still be requiring XML in all services in 20 years? * Can interested parties discuss (1) whether IVOA should do this (2) what the main blockers are for starting to experiment? * This also brings up the issue of whether we want to switch to a more REST-based services API. We are still using the "best practices" approach of 2004.