DM Working Group: Status & Discussion

(Tuesday May 5, 06:00-07:00 UTC)

Session notes:

    Overall presentation by Laurent Michel on DM activities done by the working group and use of data models in IVOA

    (49 participants)

Questions:

Jesús: Are there other data models needed not already covered or not in the DM WG plan? Science aspects not covered?
Ans: F. Bonnarel: Interferometric data and Characterization?
L. Michel: Characterization not in the slides but covered.
Jesús: Data models serialization. VO/DML adoption difficulties.
Mireille Louys: Should  DMObject libraries be developped  to help datamodels adoption. Python, other langages?
Ans:
Laurent has developped tooling in Java and Python with JSON serialisation.
will be shown in next sessions for Source Model next Friday
Possible future integration of these efforts in pyVO
Mark CD: Models are large so implementation is complex for data providers.
Laurent simplification using annotations

Gregory Dubois-Felsmann: Can you comment some more on the road map for evolving ObsCore to a VO-DML representation?
The usage of Obscore is more TAP oriented .
It is actually a subset with constraints ( a view ) of a bigger model: Datasetetadata which can be VOdml-ised together with Characterisation revamped in VODML. But it is a hard work.  (Mireille)
[Pat] I think I made a vo-dml description of ObsCore awhile back... will look for it -- in principle the "view" nature of ObsCore can be considered a mapping from one model to another (something that Gerard has discussed before)
[Gregory] ObsCore is not just a matter for (Obs)TAP but also for SIAv2
agreed (Mireille)
Markus Demleitner is rather concerned about the strong links between the DMs and would much rather  see lightly coupled things; for instance, source DM should IMHO talk about "position" as a role without requiring, say, positions 1.2.  There are annotation styles which then lets us provide both positions 1.2 and positions 2.0 annotation, letting clients choose which one they want.
François B is asking about  a possibility of  mapping VO-DML using only GROUPs + vodml-ids. But it's may be a question for Friday.
 L. Michel: A possibility but very close to one of the options presented
M. Demleitner: There was an initial proposal of serialization that was useful and complete. It only needs adoption

Markus points to a document for GROUP mappings http://www.ivoa.net/documents/Notes/VOTableSTC/20100618/NOTE-VOTableSTC-2.0-20100618.pdf
François B :Also on this. In Groningen,  In the context of CAB-MSD I compared flat utypes, VODM-Lite and GROUP strategies . the comparison were dervied from a Tableset representation in the sense of VOdatservice/TAP schema : https://wiki.ivoa.net/internal/IVOA/InterOpOct2019DM/Source.pdf
As, the lite mapping draft is going on, we could compare one by one all the features with both syntaxes


Gregory Dubois-Felsmann: Discussion of how to annotate metadata-only queries (e.g., MAXREC=0 in DALI queries), and (introduced by Pat Dowler) how to annotate "sliced" queries, like TAP queries in which the user/client has only requested a subset of the columns in a table, or TAP queries involving JOINs between tables (each table might have a well-established DM, but what is the DM for the join?).
Let's fist try to figure out how to say to a TAP server how to map one table
Meaning, a mapping that works only for simple 'SELECT *' queries?
LM yes. We have Utypes in the TAP schema, taht can give a role for each column, we have Utype for tables. This can give the class serialized in that table. What is missing is the way to group things. It you are using STC, all columns will have the following role (Utype) ivoa:RealQuantity.value. What you need is a way to know that this  ivoa:RealQuantity.value is the value of that parent class, or even of that gran-parent class. I've right no clean solution with the current TAP standard


slightly off-topic: diagram (slide 7) may be useful for the architecture doc (Marco M.)
- totally agree, and it would be good to have in a published paper - ADASS? AC? (Mark A.)
   - all what Laurent is currently saying would perfectly fit a paper explaining model usage and needs in the VO and beyond
- indeed, very clear and useful diagram for the architecture doc (Christophe)
- except it is not quite correct -- but it is one of the types of diagrams that are useful
LM: I agree, it must be updated

Universal praise for the successful adaptation of the InterOp to a virtual one compatible with our present situation.