Design Options

Introduction

The page exposes different strategies to implement the processing of MIVOT annotations by the Astropy/PyVO code. The options shown here follow the growing complexity of the MIVOT use cases as exposed at the Fall 2022 interop

Global Pattern

The guideline adopted at the July 22 meeting was 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 users 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 operations are implemented in PyVO.

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

• Providing access to XML components of the mapping block
• 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 VO model API.

Some science level VO-model classes (photometric filters, coordinate frames...) have no counterparts in Astropy. They could 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 result from the model mapping. In this case, the Astropy classes must be extended and these subclasses must be hosted by PyVO.

The different options for doing this are discussed below.

Funtionality	Astropy	PyVO
Mapping block Read/Write	X
Mapping block parser		X
Model extensions for Quantities		X
VO Model mock classes		X

Whatever the chosen option, the MIVOT processing will start with implementing a model viewer:

votable = parse('my_votable.xml')
model_view = pyvo.mivot.ModelView(votable.resources[0])

Implementation options

Option 1: lite implementation

• We do note change the Astropy Quantity classes (see the table here)
• The ModelViewer looks for the 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

EXAMPLE

# get a SkyCoord instance
sky_coord  = model_view.get_first_sky_coord()
print(sky_coord.__class__)
<class 'astropy.coordinates.SkyCoord'>

# get a photometric filter
photfilter = model_view.get_instance_by_type("photdm:PhotFilter")
print(photfilter)
<INSTANCE dmtype="photdm:PhotFilter">
  .....
</INSTANCE>

• PRO
  • Just one module to develop, the ModelViewer
  • No model-dependent code
• CON
  • Objects that are not Astropy instances are 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 the mapped columns that can be used to build Quantity (or subclasses) instances and return them to the user.
• The ModelViewer looks for mapped GLOBALS that can be used to build instances of VO models classes such as the photometric filters or other coordinate frames.
• 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
VO Model mock classes		X

EXAMPLE

# get a SkyCoord instance
sky_coord  = model_view.get_first_sky_coord()
print(sky_coord.__class__)
<class 'astropy.coordinates.SkyCoord'>

# get a photometric filter
photfilter = model_view.get_first_phot_filter()
print(photfilter.__class__)
<class 'pyvo.mivot.astropydm.SkyCoord.PhotFilter'>

• PRO
  • Reasonable development effort
  • Mock objects implemented in the PyVO package for the most useful models (frames, provenance...)
• CON
  • Model-dependent code, might obsolete the code in case of model evolution.
  • Objects that are not Astropy instances are all 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 instances.
• The ModelViewer looks for the 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 component as XMM block 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

EXAMPLE

# get a pyvo.mivot.astropydm.SkyCoord instance
# get a pyvo.mivot.astropydm.SkyCoord instance
sky_coord  = model_view.get_first_sky_coord()
print(sky_coord.__class__)
<class 'pyvo.mivot.astropydm.SkyCoord'>

# using native methods or getters
print(f"position is {sky_coord.ra} {sky_coord.dec}")
position is 12.34 56.76

# getting the semantic (mapped)
print(sky_coord.semantic)
<ucd="pos;meta.main", vocabulary="#star.position", description="Main position">

# getting the space frame (mapped)
print(sky_coord.frame)
<class 'pyvo.mivot.vodm.coords.SpaceFrame'>

# getting the error (mapped)
print(sky_coord.error)
<class 'pyvo.mivot.vodm.mango.CovarianceError'>

• 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 obsolete the code in case of model evolution.