30_11_22

Follow up the the 30/11/2022 meeting

Development plan following the discussions

On Astropy

• Make a MR to enable Astropy to extract the XML content of a meta resource
• The XML content would be returned as a string.
• The tools should also be able to insert XML content in a meta resource
• We have to take care that a read/modify/write/read cycle does not alter the VOTable content.

That has been prototyped on the LM fork but we might consider to make this functionality applicable for other content than MIVOT blocks; e.g. resource descriptors.

We can also consider to push some specific classes developed in the context of this project; e.g. photometric stuff, back from PyVO to Astropy. The conditions for this are:

• The pattern have been validated by the comminuty
• The classes must keep a loose coupling with VO DMs.

On Pyvo

All the VO-related code will be in PyVO. We plan to implement first option 2 and then option 3

We consider that making these 2 steps is not a waste of time since option 3 is a natural evolution of option 2. This strategy gives us the opportunity to refine the design before to have a too large chuck of code.

The global pattern is as follow:

• A object factory doing the XML parsing and building instances of data classes (SkyCoord, PhotCal, ...)
• This factory will allow users to get XML elements extracted from the MIVOT block by applying constraints on both roles and types.
• The Astropy data classes (SkyCoord, Time, Quantity) built by the factory will be those of Astropy when possible
• All other data classes will be developed on purpose within the MIVOT PyVO package?

Meeting notes (from the pad, taken by Jesus)

Participants: 10 Laurent Michel LM, Marco Molinaro MM, Renaud Savalle RS, Mireille Louys ML, Francois Bonnarel FB, Tom Donaldson TD, Mark CD MCD, Gilles Landais GL, Adrian Damian AD

Agenda: The standard to mapping VOTable data on VO models (MIVOT) is in PR. No serious issue has been risen so this can be interpreted as green light to move on.

I worked a little bit on the code and I wrote a Wiki page summarizing the options we have. https://github.com/ivoa/modelinstanceinvot-code/wiki/

and especially https://github.com/ivoa/modelinstanceinvot-code/wiki/Design-Options

Notes: LM introduces the status of the modelinvot-code wiki and the activities done https://github.com/ivoa/modelinstanceinvot-code/wiki/ Questions: - How to generate the annotations (not to be covered today) - How to consume the annotations (to be discussed today)

First we need to create generic classes, then model specific classes in line with the IVOA DM and then define the binding software. The python engine (parser and formator) will take care of these actions

Proposals of use cases requested. GL sent a proposal to consume annotated VOTables with photometric data. An API guideline was proposed for the annotation workflow and in the python block, the XML shoudl be extracted and the model objects should be gnenerated from the XML view and astropy objects from the model object

API Components are: XML block extractor astropy.io.votable mapping explorator pyvo.mivot _Model classes pyvo.mivot.vodm _ Astropy Extensions pyvo.mivot.astropydm      For the design pattern, we need factories to produce the required transformations from the XML block to the model instances

Model viewer implies the implemenation of the factory: votable = parse('my_votable.xml') model_view = pyvo.mivot.ModelView(votable.resources[0])

_Three options to implement it are described at: _ https://github.com/ivoa/modelinstanceinvot-code/wiki/Design-Options

Question: TD: Solution 2 could be rapidly implemented and then 3 in the future. What are the experiences in development something like 3? MCD: Multiple levels of complexity for 3 to implement all the models needed for this solution LM: Models from XML is not too difficult but errors and missing fields is difficult      MCD: define what is inside the block looks a complex part _LM: extract complex things (like time series) could be really complex. _      MCD: If I download an annotated table, it would be interesting for users to declare what is inside LM: Some getters/setters to extract one particular dm instance XML section developed. What it is difficult is to extract references between objects (e.g. filter calibration link to meassurement)

TD: if option 3 can be as a progression of option 2, that could be a way forward. Implement 2 and foresee an option 3 extension LM: Yes, the implementation is not orthogonal but an implementation extension LM: Also a problem to implement it properly to generate the mapping

AD: Can be the classes generated in line of the DMs part of astropy? LM: The classes implemented in astropy are not in line with DM. That could prevent the problem of the versioning but it would require more agreements (but it is a good proposals) TD: astropy does not have a schema for prototype annotations so decoupling looks to be a better approach

TD: Reverse process (from metadata to annotation) could be interesting to explore LM: generation of modelmapping and saving into a votable works (what is close to this) (this is part of the pyvo LM fork)

MCD: get_instance_by_type is returning a simple instance for more complex ones? LM: there is another parameter in the method to also return the references MCD: what about joins? (it could be complex to return them) LM: the model viewer navigates the join (the code could be not too clean)

AD: return real classes would be nice LM: technically is easy to use the current output using dmtypes and dmroles

ML: should it be interesting to explore a particular use case to see so the benefits and comparision of how pyvo and astropy can handled it LM: the extraction of time series from gaia, as proposed, can be used for that

LM: Are classes specific for photometric data? MCD: not that I know AD: recommendation to add to the slack astropy members (to a relevant slack channel). They are quite useful for the discussions