DM Workshop wrap-up

[Mark Taylor]

Laurent,

I agree that it's a good idea to organise things so that for each
TABLE there is a single VODML element to which it corresponds
(avoid mappings from multiple models).  The spirit of your proposed
resource location rules seems to underline that without forbidding
multiple VODML elements in the same VOTABLE document, which suits me.

My usage for TOPCAT sessions would therefore be to make sure that 
the scopes of different VODML elements don't overlap (by isolating
within container RESOURCEs).  I would prefer to avoid merging
multiple VODML elements into a single one since (a) that requires
parsing of the VODML, and (b) it may be necessary to disentangle
them again later, for instance when saving another session later
with only a few of the same tables.

Mark

On Tue, 24 Aug 2021, Laurent Michel wrote:

> Hello,
> 
> Here is my take after having read this thread.
> I'll open an issue on https://github.com/ivoa-std/VOTable/ for the follow-up
> 
> VODML block
> ===========
> - follows a separate schema
> - prefixed with a specific name space e.g. <dm_mapping:VODML>
> - enclosed in a <RESOURCE type="meta">
> 
> VODML resource location
> =======================
> My take is that there is no need to support multiple VODML blocks since the
> mapping syntax is not model-dependant. Assuming that dealing with annotated
> VOTables is an extra job for both data providers and client developers, let's
> keep this job as simple as possible. Our first use-case is to improve the
> meta-data representation and it look wise to keep this in mind and not to
> bother our-self with more complex features e.g. involving mappings on multiple
> models:
> 
> - The VODML RESOURCE must be enclosed in another RESOURCE
> - The VODML RESOURCE must be the first child of the host RESOURCE
>   - thus maxOccur=1 by construction
> - The scope of the mapping blocks covers the whole content of that host
> RESOURCE
> 
> QUESTION:
> - What are the consequences of such rules on both VOTable schema and standard?
> 
> The TOPCAT session issue
> ========================
> My take:
> - The structure of the mapping should easily (*) support the merge of
> different mapping blocks since it is based on TEMPLATES that are
> table-specific.
> - The GLOBALS contents can be merged
> - The TEMPLATES from all tables can be stacked
> 
> Let's take an example:
> 
> Votable #1:
> RESOURCE
>   RESOURCE
>    VODML
>      GLOBALS
>         globals_1
>      TEMPLATE (tableref=1_1)
>      TEMPLATE (tableref=1_2)
>  TABLE (ID=1_1)
>  TABLE (ID=1_2)
> 
> Votable #2:
> RESOURCE
>   RESOURCE
>    VODML
>      GLOBALS
>         globals_2
>      TEMPLATE (tableref=2_1)
>      TEMPLATE (tableref=2_2)
>  TABLE (ID=2_1)
>  TABLE (ID=2_2)
> 
> Topcat session:
> 
> RESOURCE
>   RESOURCE
>    VODML
>      GLOBALS
>         globals_1
>         globals_2
>      TEMPLATE (tableref=1_1)
>      TEMPLATE (tableref=1_2)
>      TEMPLATE (tableref=2_1)
>      TEMPLATE (tableref=2_2)
>  TABLE (ID=1_1)
>  TABLE (ID=1_2)
>  TABLE (ID=2_1)
>  TABLE (ID=2_2)
> 
> - Difficulties will arrive when the same IDs will be used by both VOTables;
> but this is an issue even without VODML mapping.
> 
> 
> Laurent
> 
> (*): in theory at least
> 
> 
> --
> English version: https://www.deepl.com/translator
> -- 
> jesuischarlie/Tunis/Paris/Bruxelles/Berlin
> 
> Laurent Michel
> SSC XMM-Newton
> Tél : +33 (0)3 68 85 24 37
> Fax : +33 (0)3 )3 68 85 24 32
> Université de Strasbourg <http://www.unistra.fr>
> Observatoire Astronomique
> 11 Rue de l'Université
> F - 67200 Strasbourg
> 

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/