Design Options

2 Design options

• Option one: less work but might skip interesting features provided by annotated data
• Option two: more work but more interesting features

Follow the patterns exposed at the Fall 2022 interop

Global pattern

The adopted guideline is to implement the model related code in PyVO as much as possible. There are 2 reasons for this:

• The Astropy code is not VO code. Astropy user must not be forced to deal with VO features (class, functions)
• The PyVO development cycle is more flexible due to a community which is both smaller and more VO aware.

The only things we have to put in Astropy are the read/write operations of the MIVOT block. The reason is that the MIVOT block must be extracted on the fly during the parsing. Doing this in PyVO would require to extend the Astropy VOTable parser into a PyVO class with a great danger of divergences due to software evolution.

All others model-related operation are implemented in PyVO.

All model activities are under the control of a MIVOT parser (namely the ModelViewer) From the user perspective, it is in charge of:

• Providing access to XML components of the mapping
• Building VO Model mock instances
• Building Astropy Quantities directly from the mapping This module must be hosted by PyVO. It will be the entry point of the VOModel API.

Some science level VO-model classes (Photometric filters, coordinate frames...) have no counterparts in AStropy. They must be implemented in PyVO.

The Astropy quantities can be used as such. In this case, they do not need to be extended, the logic for instantiating them from MIVOT is totally in charge of the ModelViever. They can have extended feature that are allowing the model mapping. In this case, the Astropy class must be extended and these sublcasses must be hosted by PyVO

The different options are discussed below.

Funtionality	AStropy	PyVO
Mapping block Read/Write	X
Mapping block parser		X
Model extension for Quantities		X
VO Model classes		X

Option 1: lite implementation

• We do note change the Astropy Quantity classes (see the table here)
• The ModelViewer looks for mapped columns that can be used to build instances of these classes et return them to the user.
• The Modeliewer is also able to return any mapped components as XMM blocks that can be retrieved through a VODML based API. This API would allow to extract XMM serializations of model instances by using selectors based on VODML concepts (dmtype, dmrole)

This approach would require the following developments

Funtionality	AStropy	PyVO
Mapping block Read/Write	X
Mapping block parser		X
XML API based on VODML concepts		X

• PRO
  • Just one module to develop
  • No model-dependent code
• CON
  • Non astropy objects all returned as XML (or JSON) elements
  • Interesting model features such as data associations are not supported

Option 2: extended lite implementation

• We do note change the Astropy Quantity classes (see the table here)
• The ModelViewer looks for mapped columns that can be used to build instances of these classes et return them to the user.
• The ModelViewer looks for mapped globals that can be used to build instances of VO models such as the photometric filters or other coordinate frames.
• The Modeliewer is able to return any mapped components as XMM blocks that can be retrieved through a VODML based API. This API would allow to extract XMM serializations of model instances by using selectors based on VODML concepts (dmtype, dmrole)

This approach would require the following developments

Funtionality	AStropy	PyVO
Mapping block Read/Write	X
Mapping block parser		X
XML API based on VODML concepts		X
VO Model mock classes		X

• PRO
  • Reasonable development effort
  • Mock objects implemented in the package for the most useful models (frames, provenance...)
• CON
  • Model-dependent code, might be obsolete the code in case of model evolution.
  • Non astropy objects returned as XML (or JSON) elements
  • Interesting model features such as data associations are not supported

Option 3: model oriented pattern

• We do extend the Astropy Quantity classes (see the table here) to enable them to be connected with errors, coordinate frames or with other Quantity instance.
• The ModelViewer looks for mapped columns that can be used to build instances of these classes et return them to the user.
• The ModelViewer looks for mapped globals that can be used to build instances of VO models such as the photometric filters or other coordinate frames.
• The Modeliewer is able to return any mapped components as XMM blocks that can be retrieved through a VODML based API. This API would allow to extract XMM serializations of model instances by using selectors based on VODML concepts (dmtype, dmrole)

This approach would require the following developments

Funtionality	AStropy	PyVO
Mapping block Read/Write	X
Mapping block parser		X
XML API based on VODML concepts		X
VO Model mock classes		X
Extended Quantity classes		X

• PRO
  • Interesting model features such as data associations are supported
  • Mock objects implemented in the package for the most useful models (frames, provenance...)
• CON
  • Bigger development effort
  • Model-dependent code, might be obsolete the code in case of model evolution.