During Fall 2020 Interop we had a session, requested by Markus Demleitner, that aimed at opening a wide discussion on both Measure and Coordinate models and possibly at refining their usages.

This came after a long discussion on the mailing list, related to the necessity of keeping or not a tight dependancy between Measurements and Coordinates. It has also been suggested that product models (e.g. CubeDM ) could be replaced with domain related components.

Many people have participated to the discussion with many positive contributions.
Although the goal of this message is not to report on that meeting, we do need to note a few points:

  • There is a clear demand for using models
  • There is a clear demand for the models to be simple and modular.
  • The distinction between what is modelling and what is serialisation is unclear.
The need for a concrete solution for annotating catalog data, that resurfaced last week, has been tackled by the WG for a couple of years along with the development of Meas/Coordinates models.
  • 2018:Discussions have been engaged on this topic after a hands-on session in Victoria.
  • 2019: We asked data providers and client developers to present their needs in a dedicated session at Paris
After these 2 surveys the scope of the model usage has been exposed in Virtual May 2020 and we have been working on MANGO (a model for source data with some MC adaptations) that has been sketched in Groningen and in the virtual-May meetings and then presented in November 2020.

To continue this action we have been organising a virtual workshop (initially proposed by Tom to the TCG) with the hope of getting a widely accepted framework.

The idea is not to start afresh but to give to the participants the opportunity of matching their needs with the current proposals.

To get a clear picture of what has to be done, we proposed to work with a variety concrete use cases, mostly taken out of the SourceDM proposal ( 2016) and data samples provided by interested people.


  • 2021 February 18: Public release of the use-case repository.
  • 2021 February 24: Running meeting to present the process
  • 2021 March: People can look and contribute at the repository
  • 2021 May: Virtual Workshop - Pre-Interop meeting & 3 sessions during Interop.

Running meeting(25/02/2021)

  • Etherpad [[https://yopad.eu/p/dm_virtual_meeeting_#2-365days][link]

DM meeting - Workshop preparation - collective remarks and minutes
Participants 15

  • Mirreille Louys, Tom Donaldson Laurent Michel, Mark CD, Jesus Salgado, Gilles Landais, Francoise Genova, Kai Polsterer, Marco Molinaro, Francois Bonnarel , FX Pineau, Carlos Rodrigo, Sara Bertocco, Vincenzo Galluzzi, Markus Demleitner
The purpose of this meeting is to prepare the DM workshop forseen in April 2021:
Workshop goals
LM presents the goal of the meeting. Preparation of meeting on data models on VO and how
to improve consensus on data modeling generation.
Some DMs work well but disagreements on how to match models with scientific quantities.
Proposal to solve mapping problems is MANGO, developed by LM
Also, proposal from Tom D. to organize a workshop on how to solve this gap
Proposed process to prepare the workshop
Gather a list of concrete use cases and possible solutions
Gather contributions
  • propose new use cases
  • comment the use cases
  • propose a solution
  • comment proposed solutions
The dm-usecases repository
These use cases is created compiling some VO historical use cases that require data modeling
Two folders per use case, raw_data with an annotated xml and another folder with a mango proposal
fulfilling the use case
Time line for contribution to the use cases repository is during March to allow the pull requests merging
of all the contributions
poll created on use cases portal:
FB: Procedure is to create a branch and ask for a pull request to be merged by LM? yes, either for commenting
existing or creating a new use case
TM: Lack of consensus are, in my view, due to the level of implementation of the solutions
LM: I contacted Mark T. about using data models in Topcat and the problem comes from heteregeneous data
modeling annotations in VOTables
FG: It is difficult to decide whether to implement before having an idea of the work required to implement
This means that the point has to be central to the workshop using the use cases
MD: Will implement. If it works for VizieR, it will work for him.
TM: Use case for proper motion representation?
LM: Yes, in astrometry
Mark CD: Orbital models not present, a new use case is needed
MD: Not clear if we need models for quantities as this could be solved just with UCDs
FB: UCDs are standalone, DM informs about quantities.
MD: physics: UCDs, use DM to annotate
GL: Mango enables to link two different quantities together, no need to have a specific model for each case.
Workshop conduct
virtual / in person ?
Proposal and decision for a Date
  • End of April ?

DM meeting - Workshop preparation - collective remarks and minutes - Second session
Participants 8: Laurent Michel, Mireille Louys, Gregory Dubois-Felsmann, Jesus Salgado, Francois Bonnarel, Gerard Lemson, Tom Donaldson, Mark Allen, Harry Enke
LM presents objective of propossed workshop and historical background
poll created on use cases portal:
Use cases page proposed:
GL: Is there a DM behind all the MANGO annotations?
LM: totally free
Changes to be done in another branch (to be merged with trunk after review)
If a specific model is proposed , a new directory should be inserted
Same if a new mapping strategy is proposed

Pre-interop meeting(17/05/2021)

  • Etherpad [[https://pad.unistra.fr/p/pre-interop][link]
Participants 17
Gerard Lemson, Janet Evans, Mark Cresitello-Ditmar, Tom Donaldson, Laurent Michel, Mark Allen, Francous Bonnarel, Ian Evans, Jean-Mark, Jesus Salgado, Gilles Landais, Jean-Michel Glorian
Markus Demleitner, Vicenzo Galluzzi, Stefania Amodeo, Hendrik Heinl, Eric Buchlin
This session will allow interested participants to evaluate our proposals with regard to the services they are operating or may need to build in the future.
The meeting is OPEN to everyone.
One thing we are trying to do though is target scientists/implementors who may consider volunteering to relate their experiences at the Interop Workshop.
We envision presenting feedback on the use-case work completed so far, or presenting a vision of where a more mature version of the use case could end up someday.
François Bonnarel (8+2’)
Introduction by LM:
- Objective on how to use data models into VO and technical ways to share and to implement interoperability using DMs
- Use cases:
Data Sharing
  • - Description of elements of VOTable to identify if other elements are needed for data model serialization
  • - Quantities are well defined but tole and the way these quantitites are nested are poor. How quantities relate each other is very poor defined
  • - Proposal to add a mapping block without breaking existing VOTable blocks
  • - Most consensus on most of the data models issues but still not defined the mapping syntax
  • - Divided in three levels: Model fragments, Model Components and Integrated Models
  • - Main topic would to define which level should be mapped
  • - Presentation of the use cases https://github.com/ivoa/dm-usecases/wiki
VODML Overview (Gerard Lemson):
  • - Historical review of mapping DM problem and evolution from utypes to a complex VO/DML representation
Mark Cresitello Dittmar
Packages: Jovial, Rama (both specific for VO DMs developed mainly by Omar Laurino) and Astropy, MatPlotLib
GL: Code to use annotation
MCD: Jovial
Markus Demleitner
  • Data model strategy
  • TD: About astropy implementation fixes. Which fixes?
  • MD: My astropy code
Laurent Michel
  • Presentation on MANGO
  • GL: MANGO and model instances mapping should go together?
  • LM: MANGO API relay on the syntax but mapping and syntax are indendent
  • TD: Merging on pyVO. What funtionality could be used?
  • LM: For example get quantity parsing MANGO syntax, or bind together different quantities
F. Bonnarel
  • Mapping Mango strucuture on top of Gaia and ZTF tables
  • 26/05 15h UTC Mapping strategy
  • 27/05 15h UTC Model review
  • 28/05 15h UTC VOTable mapping syntax
  • MD: Client writers are needed e.g. for measurements data model adoption. This simplified measurements would be just removing some boxes away
  • MCD: Use cases have started very simple that have been able to progress to complex use cases like Gaia. Another point is to show that different implementation are able to arise to the same result that is totally solved yet
  • MD: Posibility to go to DPAC to serialize time series in line with a proper VO format
  • FB: For new projects you can go to them to modify the serializations but the modification of legacy data is a lot more complex
  • GillesL: At least in ViZieR if photometry data is added, it is very important to also add the provenance
  • GL: Probably better to focus in the more popular datasets/missions. Why still using VOTable for annotating (VOTables are there only because it could be related to a service response)
  • Slides to be uploaded to https://wiki.ivoa.net/twiki/bin/view/IVOA/Dm2021
Chat dump
  • 18:59:54 From Jean-Marc : Thanks to the speakers for the very nice introduction to VODML and the problem at hand. Unfortunately I have to leave now. I hope to be able to attend the workshop itself. Best.
  • 19:01:46 From Tom Donaldson : Thanks, Mark. That was a very helpful review of that work. Very intuitive flow.
  • 19:42:01 From Markus : That´s why you disentangle things...
  • 20:05:54 From Markus : Client writers!
  • 20:06:04 From Markus : Who´ll hijack them?
  • 20:06:23 From Mark CD : +1
  • 20:07:38 From Markus : Right.
  • 20:07:54 From Tom Donaldson : More important is skeptical client writers. But that’s a harder sell because they don’t see the point in expending effort.
  • 20:08:12 From Markus : Sell them error bars first.
  • 20:08:19 From Markus : automatic error bars.
  • 20:08:26 From Mark CD : Is that interesting enough?
  • 20:12:03 From Tom Donaldson : Along with Bambi eyeing, we may need hand holding. Even the simplest examples are intimidating without some initial help.
  • 20:12:42 From Markus : very true.
  • 20:19:26 From Tom Donaldson : I need to sign off at 25 past the hour. Thanks to everyone for the presentations, discussion points, and all the work behind them.
  • 20:22:01 From Markus : Again, I´m not saying we can ignore the legacy, I´m just saying let´s not burden our first version with it.
  • 20:24:12 From Ian Evans : I have to sign off to go to another meeting. Thanks everyone.
  • 20:25:38 From Markus : Oh: Do we collect slides/notes somewhere?
  • 20:27:59 From Laurent Michel : Can you upload you slides on the Wiki https://wiki.ivoa.net/twiki/bin/view/IVOA/Dm2021

Interop Sessions

Session #1 Wednesday May 26 15h UTC Model users have the floor floor
Participants 53
Laurent Michel Introduction
- Explanation of data model benefits for interoperability
- Presentation of data model use cases repository created by the team with examples of mapping techniques
- Presentation of goals of workshop
Jesus Salgado Data Models: Homogeneous view for heterogeneous data
High level, why are we creating data models in the IVOA?
- combining data from different missions is difficult and prone to error
- serialization o data is only partially standardized
IVOA Architecture:
- data models are a 'core' component, to be used by multiple aspects of IVOA standards
Data Models
- visual representation of data elements and relations between them
- assist data discover, database design, data documentation and interoperability
Photometry example:
- everyone uses magnitudes
- magnitudes are relative measurements; how do we compare between observatories?
- Photometry model associates necessary metadata to properly interpret/compare/combine magnitude data
"IVOA DM should be complex enough to allow scientific use cases but simple enough to..."
No questions
Jean Michel Glorian A developer's point of view on the use of models in the votable
- Presentation of CASSIS and use of data models on it
- Visualize and analyze electromagnetic spectra. Makes use of SAMP, SSAP, SLAP, TAP (with dataproduct=spectra) EPN-TAP
- From the data model point of view: Spectrum, Spectral Line, Spectral Data Cube, Image, Time Series
- utype is not enough. Some metadata is not present
- annotation could be used to fully characterize the spectrum (spectral axes, error spectral axes,...)
- Pointing to the client, link between different columns: flux value-> error flux value, flux value->normalized flux value
- In favour of mapping block preamble without breaking VOTable
- Also, a library for consuming this preamble would be very useful (e.g. java, python)
LM: A point missing also is the library for sever side
MCD: UCDs versus Data models for physics of the meassurements?
JMG: based on a fixed table. Sometimes the UCD is not enough and it is difficult to identify when it is really a problem
Matthias Fuessling Science case requirement for CTA
- Description of use of data models on CTA
- CTA covers gamma-ray with two telescopes arrays (La Palma and Chile)
- from sub-TeV to multi-TeV
- Also different coordination centers across Europe
- Open observatory run by proposals
- Requirement to follow FAIR protocols and support VO
- PB/year, only reduced data to the user (PB/year)
- Different data levels: R0, R1, DL0-DL6 (DL6, skymaps, spectra, light curves, phaseograms)
- DL3 are event-list and technical tables, and it is one of the scientific products level
- DL3 in line with the Open Gamma-ray Astro Data Format (OGADF)
- OGADF will evolve in lines with science needs
- H.E.S.S. format already have been released via VO
- Also, CTA is part of the multi messengers initiatives, in ASTERICS, ESCAPE, connected to VO events, what would need also metadata to be characterized
LM: Meaning of data VO complaint difficult to define
MCD: Comparison of Cube DM with gamma-ray data
MF: Not sure if this comparison has been done for CTA. All data is usually cubes so we will take a look into it
Catherin Boisson: Small test done with high level data (no exactly the same than X-Ray). Plans to do a deeper study
François Bonnarel Mango YAML serialisation
- Description of used cases
- VizieR use case: Photometry of 3 main belt asteroids
- Metadata from asteroids, fundamental metadata join with aspects shown
- Also, photometric measurements and positions relative to Earth and Sun
- Exercise to map all these table and characterize metadata using MANGO
- Generic MANGO elements used and Mango extension for TimeSeries created
- Serialization in YAML format with MANGO view
- FB showing and explaining the YAML file content
GDF: Origin of times (zero point) (Use of TIMESYS?)
FB: Taken from coordinates for the time (one single float value). Time system defined at the beginning
MCD: In the data models, a zero point for time is defined. JD and MJD are defined into the data model (class names

Session #2 Thursday May 27 15h UTC Model users have the floor floor

Participants: 60
Gilles Landais Annotated VOTable in VizieR
- Presentation of VOTable responses from VizieR and annotations

  • - Provenance
  • - Magnitude and system description
  • - Groups for related meassure columns
  • - Added values (e.g. coordinates into J2000)
- Example of mapping of radial velocities and associated errors
- Photometry viewer implementation using photometry annotations
- Analysis of possible MANGO annotated VizieR tables and presentation of prototype
- DMs used, Source and Meassure annotations
- In order to convert prototype to operational:
  • - Provenance information for filter origin
  • - Provanence dublin core (DOI, authors, date)
  • - Stable MANGO building block
  • - VO validator
Ada Nebot: ask for link:
VizieR mango prototype:
Tom D.: in last point, about the need of new provenance.
GillesL: For second part to prevent scientists looking for it but for photometry in order to consume it by clients
Gilles: I like DataModel when a flat view exists ! (eg: Obscore, photDM)
Ian Evans Science considerations for IVOA data models
- Expose complex datasets managed by Chandra including sources, detections, ancilliary tables, and many types of FITS data products
- Explanatin of complexity on X-ray astronomy data, composed from (x, y, t, PHA) in order to reconstruct photons
- X-ray photometry depends on the source spectrum in order to calculate iteratively the real photon meassurement (forward fitting)
- CSC makes use of Bayesian X-ray aperture photometry, so multiple detections are solved simultaneously
- Optimization done by MCMC (Markov Chain MonteCarlo Chain)
- Use of confidence intervals (independent lower and upper confidence limits)
- 2nd lesson learned is temporal variability
- Individual and multi-epoch data
- Many to many relationship between detections and sources
- Data models should contain shape and epoch information
- IVOA data models can represent X-ray and X-ray source data?
- Some changes needed
- MANGO provides a good framework for mapping
Kai P: Probability function is needed in general to make proper science
Ian E: Yes, for a radial velocity sensor, e.g. PDF are also needed
Jean Marc Petit Asteroids: astrometry, photometry, dynamics, survey modelling
Different types of data:
- Photometry:
  • Flux vs time lightcurves
  • Physical properties: lightcurve, phase function, colors
  • Heterogeneous time description (data, JD, MJD)
  • Showing example file and client to filter properties
  • Derived data: periods, lightcurve amplitude, shape
  • Provenance
- Astrometry:
  • MPC typical information shown
  • Survey internal information
- Dynamics
  • Orbit information
  • a, e_a, e, e_e, i, e_i, omega, e_omega, tperi, e_tperi and, in general, orbital elements information
  • Also, phometric information, distance, etc
  • Dynamics classification
- Comparison with models explanation
- Question on how to represent metadata needed for orbital estimation
Francois B: How is done the generation of orbital parameters from observational measurements (astrometry)?
Jean-Mark: there is a data hierachy from meassurements to the orbital estimator calculation.
JJK: what is the data provenance is the question, does it have any? Answer from JM is yes, but the provenance is not expressed in the model we use.
Jean-Marc: Fully agree
Mark C-D: Comparison of simulated and observed data is a very interesting case to me. Optimally, I think, the data itself could be described by the same model, but with VERY different associated Dataset Metadata, one describing the observation, the other describing the simulation. Does this approach seem feasible for your data?
Jean-Marc: Models and real data behaves the same in the orbital simulator.
GL: Link between real and simulated data is done through by defining the provenance of both sides (that is different) but trying to find similarities between both metadata
AN : I also like this idea of the comparison of simulated and observed data. Same model for both helps for that. I guess that we have an example of something like this in the VOSA service (different context tho), where photometry (observed, collected from different surveys) is compared with synthetic photometry computed from stellar models., the aim is to determine stellar parameters from SED.
In this specific science case it would be from positions, time, rvs, get the orbital parameters.
Laurent Michel Binding PyVO with MANGO
- Presentation of plans to include MANGO support on PyVO
- Presentation of basic architectural concepts on VOTable handling in pyVO
- MANGO is a container model
- MANGO improves view of metadata
- Example of elements to annotate VOTable with SpaceFrame, LonLatSkyPosition and ProperMotion (Global and Parameter Dock)
- Showing example of MANGO annotation with previous elements
- A MANGO parameter could contain different columns (e.g. value, error, frame)
- Description of similarities between python dictionary and MANGO

Session #3 Thursday May 28 15h UTC Mapping Syntax

Participants: 41
Laurent Michel Introduction:

  • - This last session is more technical on mapping solutions
  • - utypes useful for complex protocols but limited for complex cases
  • - Complex mappings require architecture and techniques approaches
  • - Quantities and roles
  • - Annotation in VOTables without breaking exisiting VOTable structures
  • - mapping written in pure XML
  • - out of VOTable resources
  • - allow nested structures
  • - freedom to setup the schema
  • - XML schema mapping imported into VOTable schema
  • - Avoid name collisions between mapping and VOTable elements
  • - VODML mapping 2017
  • - 2019 MANGO mapping
  • - 2020 ModelInstanceInVot
Gerard Lemson VODML Mapping
- Concepts:
  • - Mapping express how instances of data model are expressed on VOTable and TAP_SCHEMA
  • - Based on the VODML standard
  • - Example of a Source toy model to decribe the proposed mapping
  • - Explanation of mapping for real catalogues tables
  • - Complication of mapping is more than the syntax the impedance between data models and tabular data
- VO-DML Mapper
  • - tool that can read TAP_SCHEMA and VOTables
  • - able to read data models
  • - allow graphical connection between data elements and data model fields
  • - generates mapping block
- Mapping Meta-Models
  • - VO-DML is IVOA standard meta-model/language
  • - goals: mapping at the meta-model level
  • - mapping as much as possible 1-1
- Inspired by object-relational mapping
- Explanation of VO-DML mapping, VODML-mapping.xsd
- VODML/Model: Model1: xmatch -> Model2: source <- Model-2-sub: sdss-source
- GLOBALS: container for "standalone" instances of VO/DML types
- Explanation of the different elements into VO/DML mapping
Laurent Michel ModelInstanceInVot: alternative or evolution
- More focused on the mapping generation than the object-relational mapping
- Comparison of the approach of the path from mapping and models
- XML elements faith to the model path
- Use of dmrole and dmtype
- Into the mapping block there are globals and the mapping of the tables included in the document
- working draft written on ModelInstanceInVot
- Similarities with VO/DML mapping but, also, significant differences
GL: Elements can have structure so mapping is somehow more complex. Also connections from rows
is too simplified. Container is very similar
Some commonalities, some deviations but close enough to find elements missing
LM: JSON can express complex data organizations, so the solution is based on this
GL: Some elements in the VO/DML mapping so a different approach would be to evolve the old standard
with these ideas
Mark Cresitello Dittmar Summary
- Impressions of the two approaches comparison
- Both support the workshop use cases
- Analysis of the Modelinstanceinvot mapping and VODML mapping on the use cases, including possible mapping limitations
- Possibility of moving forward by using an hybrid solution
GL: Same problem, elements is more general that attributes. Original idea was to have a very specific tecniques
and it could be simplied
FB: GROUPBY only have one reference but it can be stacked
LM: to get the inputs and prepare summary to be sent to interop
GL: question of SourceDM in MANGO
LM: MANGO is not a SourceDM but annotations for source
Mireille L: Question on the roadmap for a mapping strategy? 60% of simple datasets that can be already mapped. Do we need more complex use cases?
TD: Probably mapping syntax is linked to VOTable 2.0 so first would be to ignore the block in the mapping and second the parser
AN: If you have multiple tables we should wait to VOTable 2.0 and ensure we do not break backwards compatibility
TD: multiple tables are allowed in VOtable but connections not really expressed
LM: Internship at CDS to create a TAP that annotates on the fly

DM Workshop Session #4 Wrap up

Workshop overview MAY2021-ws41.pdf

Tuesday 2021 July 13 17h UTC

Participants :
Laurent Michel, F. Bonnarel, Mark Taylor, Mark Cresitello-Dittmar, Tom Donaldson, JM Glorian, Mireille Louys, Jesus Salgado, Adrian Damian, Gerard Lemson

TD feel >0 Can help for PyVO integration
JMG we have to keep in touch
TD: how do you validate wrt the xml schemata. votable element / instance ?
how do the imports work?
LM: shows unit tests on some instances in the mapping examples
Separate the parts using name spaces
at top of the votable there is a reference to the mapping syntax schema
there must be a skip possibility to interpret the mapping , and the votable separately
MT : can stiil ignore the mapping part and work with the VOtable part
do we need an update of VOtable std?
GL : Mapping part can be external to the VOTable, but it points into VOtable Fields for instance
TD: how can we keep these parts separated
do we want Votable and mapping syntax evolve separately for their future versions ?
MT: what happens when the model is changed ?
LM: if you rename or if you delete/ remove one attribute or instance
JS : how difficult is it for a parser to cope with model changes ?
TD: Parsing is relately straightforward
depends on the model , more than on the syntax of the original VOTable.
Parsing in a model agnostic way is easy but how to use properly this information could be tricky if the model is complex
When the exercise for VO/DML was done to create a parser, it took not too long to create the parsing of the preamble
propose reference interpretation to understand the problem pragmatically.
GL: Also, the mapping tool could be adapted for this new syntax so the annotations are done in a more consistent way so parsing is simplified.
MCD; About server side implmentations, obviusly ViZieR would be relevant implementation but we do not expect them to annotate all the catalogues
JS: Maybe for luminosities is not so complex as they were already identified by Sebastien Derriere in the past and annotated in a temporary agreed syntax
LM : model agnostic translation
this was the experience of TD too in presenting syntax comparison in Santiago
Topcat does not need the complex model structure to work
Spectra tools are more suppposed to cope with Model complexity
what if you would have a source model ? Could e.g. topcat/stilts be adapted to make use of the annotations for science use cases?
Xmatch use-case : at best can interpret selection boxes, but much interpretation and choices come from the astrononer expertise
Topcat does not do automatic conversions using metadata provided by the service. The user always select the information and use if in the way they consider it correct
GL : try the Source model for annotation
can be done by hand , crowd-source effort , or infered with rules from ucds / units
reminder / sharing the merged syntax document
Laurent to send the link around
TD : how the Votable schema will change : we should clarify this
can help to move the process further
MT to chek how to interpret a VOtable with two imported schemata
GL to test import of one schema?? please confirm , I may have not understood correctly (neither clear to me)

FB On the mapping xml schema issue :

in next version of VOTABLe we can introduce the optional VODML tag as a direct child of <VOTABLE>
the type of this element "VODML-type" would be defined in the external mapping schema will all its child elements
I think something like
<VODML xsi-type="mapping:VODML-type" > ....... </VODML>
with mapping namespace imported and defined as whatever version of the mapping xml schema

Chat Dump

chat 18:56:40 From Laurent Michel to Everyone:
18:56:51 From Laurent Michel to Everyone:
18:57:11 From Laurent Michel to Everyone:
19:09:10 From Mark Taylor to Everyone:
good summary of my concerns!
19:30:13 From Franois Bonnarel to Everyone:
19:30:17 From Franois Bonnarel to Everyone:
19:30:49 From Gerard Lemson to Everyone:
hi all, sorry for being delayed.
19:31:03 From Mark CD to Everyone:
19:49:09 From Franois Bonnarel to Everyone:
Where is the etherpad ?
19:54:59 From Jean-Michel Glorian to Laurent Michel(Direct Message):
Dsol, je dois partir du zoom. Comme je l'ai dit je n'ai pas eu le temps de regarder tout cela mais je vais essayer de voir ce que je peux faire avec le service de spectre polarbase que je maintiens et avec cassis cot client... Par conrte aucune ide au niveau du planning ...
19:55:10 From Laurent Michel to Jean-Michel Glorian(Direct Message):
19:55:56 From Jean-Michel Glorian to Laurent Michel(Direct Message):
tu viens de m'nevoyer le lien moi directement ...
19:56:08 From Laurent Michel to Everyone:
19:56:27 From Laurent Michel to Everyone:

Running Meeting 06/10/2010

Etherpad: https://pad.unistra.fr/p/DM_Running_Meeting

Slides: DMRunning-10-2021.pdf


  • Mapping syntax
  • WG Roadmap
  • Obscore for radio data
Attendees: L. Michel

Etherpad content:

  • - As the specification is a "language" it is difficult to validate
  • - Decision to create snippets to check different areas of this pattern and using a unit test tools (python)
  • GL: Should meta resource included into the results resource?
  • LM: Yes, this is the way foreseen
  • FB: Is this really valid or the correct way to add the resource "meta" inside "results"?
  • LM: It was agreed that this was better during last meeting
  • LM showing new xsd of the merged-syntax
  • Dave M. propose to add a preamble on the python snippet with a description of the purpose of this test and also in the xml files
  • DM: In particular a comment in the XML file for the rich examples to say what it represents
  • GL: Multiple primary keys is a new feature? that could make things more complex.
  • After clarification it is more multiple fields
  • LM: In paralllel, a python client has been produced to have real instances of the model
  • Proposal to merge with PyVO and connection to AStroPY investigated
  • ADASS BoF: TAP and the DMs (to be prepared)
  • Help wanted as the task is far beyond the VO time for the people involved
  • Tom D. proposes to makes the contact with pyVO
  • Next point Radio-Obscore
  • Francois B. presents status of Radio extension of Obscore
  • Present the ins and outs of Radio extension of Obscore
  • list of columns to add to describe visibility data, list of authors, spec draft for Interop, status (endorsed note or full recomendation) ?
  • List of possible additional columns : min max for spatial resolution and field of view, maximum angular scale, characterisation of the uv plane coverage, instrument description (nb of antennae eg), pointers fields to maps (uv coverage, beams, etc...)
spatial resolution : min and max needed
nb of antenna --> data quality
uv coverage maps
Mark Lacy, Mark Kettenis , Mathia Mancini , to contribute writing this
+Fb , ML
  • Should these extra columns inside obscore table or as another table? Not decided
a separate table in the TAP SCHEMA or new columns in the same Obscore table
discussion is going on. M.Kettenis is for another table.
  • Marco M.: how to inform that this extra columns are empty?
  • Francois B.: probably with a different extension Id?
  • Mark T: For discovery it would be better to reuse the mechanism used by obscore
  • Both approaches could work as these are only additional columns but not a modification of the basic Obscore table
which kind of document ? EN or update of Obscore
question Marco:
how do you check the new columns if they are null ?
EPN TAP and ObsLocTap check capabilities via the presence of specific tables
MT:Obscore defines the capability via the model reference.
seems better to keep the same as tapregext , as EPN-TAP.
first step : prepare a document for Interop

Topic attachments
I Attachment History Action Size Date Who Comment
PDFpdf DMRunning-10-2021.pdf r1 manage 38.3 K 2021-10-06 - 13:13 LaurentMichel Running Meeting 10/2021 conductor
PDFpdf IVOA_DM_premeeting_20210517_v1.pdf r1 manage 1583.1 K 2021-05-17 - 16:43 GerardLemson VO-DML and Mapping
PDFpdf MAY2021-ws41.pdf r1 manage 2638.1 K 2021-07-15 - 08:26 LaurentMichel Wrap-up session
PDFpdf MangoViewONtwoTables.pdf r1 manage 1311.1 K 2021-05-22 - 13:47 FrancoisBonnarel Mango view on top of two tables with time variation
PDFpdf Workshop_pre-interop.pdf r1 manage 585.8 K 2021-05-17 - 14:00 LaurentMichel  
PDFpdf dm_workshop_preinterop.pdf r1 manage 2883.3 K 2021-05-18 - 13:18 MarkCresitelloDittmar Implementation review
PDFpdf markus.pdf r1 manage 2876.6 K 2021-05-17 - 18:30 MarkusDemleitner Lecture notes for Markus' talk
PDFpdf workshop_pre-interop_MANGO.pdf r1 manage 2858.9 K 2021-05-17 - 14:00 LaurentMichel  
PDFpdf workshop_pre-interop_MANGO2.pdf r1 manage 2768.9 K 2021-07-15 - 08:25 LaurentMichel MANGO + MIVOT
Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2021-10-06 - LaurentMichel
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback