Follow-up: Participant Feedback and Requests

The section gathers partipant requests. It is intended to provide both modellers and developpers with inputs on missing, misleading or failing features.

• Any contribution is welcome.
• Those who have trouble with editing the Wiki can send an Email either to MarkCresitelloDittmar or LaurentMichel
• Please, sign your contribution so that we can get in touch with you for any further precision.

• During our exercise trying to map the prototype Source model to Gaia data results, we discover some model elements that were missing or not clear. If any of these are present, we couldn't figure out where:
  • Proper Motion (in this case, 2 values, RA PM and Dec PM)
  • Radial velocity
  • Position error (in this case, 2 values, RA Err and Dec Err)
• Documentation seemed missed from most model elements.
• When model elements are Quantities, units can be specified in VODML. How does this relate to the units on the FIELDs? Is it duplication, or does it represent a different flavor of unit, or can/should the VODML unit be left blank in cases where a FIELD specifies it?

• Starting from DM knowledge and expertise at level 0, having only followed the Beginner's Guide install steps, I grasped the first notions on how to build my model graphically and then went on trying to generate the VO-DML.xml. Unfortunately, using the latest (3.7) version of Modelio it turned out that the xmi-to-xml xslt transform requires some fixing. Nonetheless it was a good experience, let's continue having hack-a-thons. -- MarcoMolinaro - 2018-06-04

I try/have to evaluate what could be the impacts if we are adopting VO-DML serialization principle as it has been presented yesterday (for IVOA Apps, and more pragmatically, for CDS).

1. Prerequise : the model
   All this effort is based on the pre-existence of a global model defined and adopted by the IVOA. Is it reasonable to think that we could have a unique IVOA model coherent, ready and adopted now (probably based on the convergence of our various DM efforts (STC1, and now STC2, Image DM, Cube DM,...) ? If no, how to start ?
2. Alternative model(s)
   If some IVOA partners prefer to use CAOM model (or another) to annotate their VOTables, what will be the impact on the global interoperability ? How a client based on the IVOA regular model will be able to understand VOTable annotated based on another model ?
3. Model evolution - meta data impact
   If one of these models is extended in the future, what is the impact on the existing VOTables (static stored files). Still usable, or should need to be updated ? Is it easy doable ?
4. Model evolution - clients/server impact
   Same question for client codes, and server codes.
5. External dependencies ?
   For interpreting a VODML annotation, does the client may have to access/download external information (via registry or other DM repository system ?).
6. Meta data duplication ?
   What is the part of the FIELD metadata information duplicated in the model ? datatype ? unit ? UCD ? more ?
7. Concretely, where are my coordinates ?
   What would be the mapping to describe the same information that I have in COOSYS and associated FIELDs (RA,DEC,PMRA,PMDEC designation + SYSTEM/EPOCH) ? Is it reasonably understandable by reading "manually" the VOTable ? Or does it really require a dedicated tool ?
8. Concretely, where is my time ?
   Same question for time (time frame, origine, offset, format = the possible TIMESYS that I would like to have)
9. Price of the entry ticket for the client ?
   If a basic client want to retrieve space or time meta data description from the VODML serialization header, does it can use some simple hacks (based on ref label or similar thing) ? Or there is no alternative and it has to to parse and understand the associated model (or use dedicated libs). If this "hack" exist, can we insure that it will resist to an evolution of the model ?
10. Price of the entry ticket for the server ?
    How a data base such as VizieR or HEASARC can integrate the model to be able to generate the appropriate VODML serialized header associated to each table without redesigning all its meta data information system ?
11. Alternative or not ?
    The way that the mapping would be done is still allowing the alternative usage of the regular VOTable meta data description information. (fields attributs: datatype, UCD, unit, utype xtype... COOSYS, GROUP ?) Or does the structure of the VOTable is modified (in the previous proposal, as the mapping was based on GROUP and utypes, there were some interferences).
    
    -- LaurentMichel - 2018-06-19 (on behalf of Pierre Fernique)

Model Features

• Source Parameters
  • Radial velocity (PierreFernique)
  • Parallax (PierreFernique)
  • Include upper flux limit (Flag?)
  • Add info on algorithm for mag/flux (psf, petro, ...?) (AdaNebot)
  • Add pipeline version to Algorithms
• Make axes dependencies explicit
• Physical Quantities
• STC is missing many transformations
• STC's covariance matrix has one element too many, so it could be asymmetric
• STC errors missing: sigmax, sigmay, sigmaxy, ErrorMatrix2D.
• Miscelaneous

Tools

• Model Design
• VO-DML Generation and Validation
• Mapping Generation
• VO-Table processing
• Miscelaneous

Wednesday May 30 -- 14:00 to 17:30

These sessions are intended to help data modellers to learn to use the available tools in order to describe their own models using VO-DML. This is a hands-on workshop/hackathon style event and not a normal speaker-audience-dicussion session.

If this doesn't sound like something you are ready to do or are interested in, then please don't feel guilty about taking the afternoon off to see more of Victoria, go whale-watching, etc

What is this all about?

VO-DML is the Virtual Observatory Data Modelling Language : http://www.ivoa.net/documents/VODML/index.html

The purpose of this session is 2 folds

• Giving VO people the opportunity of doing a concrete job with VO-DML and getting answers to any questions:
  • How to build a model
  • How to reuse a model
  • How to annotate existing data
  • How to annotate dynamically generated data
  • How to parse annotated VOTables
• Checking that the current VO-DML workflow fulfill the expectations of the community
  • Gain in term of interoperability
  • Curtation and developement effort
  • Sustainability

Project Pitch

• Gregory: Existing data from Wise, annotate with example data models.
• Olga: annotating NED images. Extend metadata for Cubes. List of minimal requirements. (Need anybody with solid knowledge about cubes)
• Mireille: vodml-ize CharDM
• Tim: Interop of WCS and Transform between GWCS and . Need a plan! Ideally STC2
• Pat: CAOM2 in VODML. Unit tests for models. Show you how to Continuous Integration.
• Tom: Exploring VODML annotations for Vizier Catalogs. (Need Vizier experts).
• Baptiste: STC2 with XML schemata for inclusion in VOEvent.
• Carlos: SimDM in VODML.
• Marco: how to build a model, from idea to VODML-XML.
• Omar: Explore JSON Serialization, Requirements on Data Providers Tools. SVO Photometry Filter Service annotations.
• Dave: Mapping tool, what I need to do to make it automatic

Possible subjects

In no particulaar order

• dealing with model imports in Modelio
• Mapping STC2 to many VizieR or other catalogues
• Compare different versions of STC2
• Create new model from scratch using Modelio + xslt path way
  • Data Model for Wise
• Create models using DSL (?)
• Porting existing models to VO-DML
  • characterization (Mireille?)
  • Simulation DM (+ using mapping in SimDAL?)
  • provenance
• generate XSD from VO-DML
• end-to-end time series treatment
• Java parser for mapped VOTables
• additions to mapping spec
  • SAMEINSTANCE for star-schemas
  • RemoteReference or ProxyInstance?
  • Time domain data grouped by rows (Gaia)
• Registering data models , in particular let's register ivoa model (and vo-dml standard!)
• End-to-End (simple) implementation of KDD interoperable workflow
• VODML-annotated Filter Profile Service
• Brainstorming about use of mediators creating ADQL queries for object queries, from annotated TAP_SCHEMAS
• Create an SDSS/Stripe82 analogue of the HSC data and run it through OMar/Tom's notebooks.
• Try the HSC annotations with Laurent's syntax proposal.
• JSON serialization of instances.

• A basic VO-DML: Beginner's Guide has been written to assist data modelers get acquainted with the procedures involved with generating VO-DML compliant models.
• A basic VO-DML: Import Guide has been written to assist data modelers to get acquainted with the model imports in Modelio.
• The VO_DML reference document can be found here
• The draft of the mapping document can be found here

Tutorials

• The Tesselation project proposes is guideline to start with VO-DML. This toy project has been used as support for 2 talks
  • Shanghai 2017 pdf
  • Santiago 2017 pdf
• Omar's tutorial on the space coordinates mapping.

Material

• Project Templates
  • Templates for the 3 supported modelers (Modelio, Magic Draw and Altova) can be found here.
  • The ivoa model for the basics VO-DML data types can be found here.
• Models
  • Some models are availble in Volute. The VO-DML mode representation can usally be found in the vo-dml sub-folder.
  • Toy Models
    • In the VO-DML project
    • Tessellation project
  • IVOA Model Pages:
    • STC model.
    • CubeDM model.
• Annotated VOTable Sample:
  • CubeDM sample
  • Tesselation sample

• Plenty of examples of STC, Cube, Time Series annotations

Tools

• VO-DML model representation can be build in 3 different ways
  • By hand
  • By using a DLS
  • By using a modeler in combination with a set of XSLT transformation scripts
    • Modelio, Magic Draw and Altova are currently supported
• Data can be annotated in 3 different ways
  • By hand
  • By using a DSL
  • By a graphical Web application
    • http://dsa012.pha.jhu.edu:8081/VODML-Mapper
    • if you want to save results, send a user name + MD5 encrypted password to glemson1 at jhu.edu
    • http://www.miraclesalad.com/webtools/md5.php)
    • will be presented during DM session
    • documentation being updated

• Python > 3.6
• Java 8
• Modelio last release