DM Workshop wrap-up
Gerard Lemson
glemson1 at jhu.edu
Tue Aug 24 15:39:10 CEST 2021
Hi Laurent
I thought the idea was not to have a change to the VOTable standard at all.
Can we not "simply" have the mapping standard prescribe a particular *usage* of VOTable instead?
Gerard
> -----Original Message-----
> From: dm-bounces at ivoa.net <dm-bounces at ivoa.net> On Behalf Of Laurent
> Michel
> Sent: Tuesday, August 24, 2021 9:35
> To: Mark Taylor <m.b.taylor at bristol.ac.uk>
> Cc: dm at ivoa.net
> Subject: Re: DM Workshop wrap-up
>
> Mark et al.
>
> Le 24/08/2021 à 14:47, Mark Taylor a écrit :
> > 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.
>
> OK, can some expert assess the consequence of this approach on the VOTable
> standard?
> - opt #1: Defining specific complexType for the VODML RESOURCE?
> - e.g. <RESOURCE type="mapping">
> - This would allow put any constraint on it without breaking the backward
> compatibility
> - Can we introduce such a new type ("mapping") for a minor version
> (extension of the RESOURCE at type enumeration)?
>
> - opt #2: using <RESOURCE type="meta">
> - no new item in the schema, just a constraint saying that <RESOURCE
> type="meta"> must be the first child of the upper RESOURCE. (no idea how to
> do it with XSD1.0)
> - Does this break the backward compatibility? (I thing so)
>
>
> >
> > 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.
> I understand.
> I'm not saying you have to merge VODML blocks, I'm just saying if you need to
> do it, it should be possible.
> If Topcat session items are stored in separate RESOURCES, there is no longer
> issues, things are well isolated with 0 or one
> specific mapping block per RESOURCE
>
> Laurent
> >
> > 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
> .com%2Fivoa-
> std%2FVOTable%2F&data=04%7C01%7Cglemson1%40jhu.edu%7Cd09d00
> c343c8470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%
> 7C0%7C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s
> data=MGAAOsQZi6L1vSPj9gT%2FYNjLjLfU6JmlKrQJbMJmA48%3D&reserve
> d=0 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.d
> eepl.com%2Ftranslator&data=04%7C01%7Cglemson1%40jhu.edu%7Cd09
> d00c343c8470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0dec%7
> C0%7C0%7C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> mp;sdata=iTPCLg%2B32dqm8welwoBgbJWyyLBuixcTO3UkTeOQ6lc%3D&re
> served=0
> >> --
> >> 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
> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> unistra.fr%2F&data=04%7C01%7Cglemson1%40jhu.edu%7Cd09d00c343c8
> 470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7
> C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
> %2FW30DazZEMs7c21i%2BSmQT1voyCpFDNDyrVnNUreOAUU%3D&reserv
> ed=0>
> >> 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
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.st
> ar.bristol.ac.uk%2F~mbt%2F&data=04%7C01%7Cglemson1%40jhu.edu%7
> Cd09d00c343c8470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0de
> c%7C0%7C0%7C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> 0&sdata=Ln9%2FsHp%2BLq2cyTzjauKRK7UBZQ8GwTb7237zm0vsZfg%3D&
> amp;reserved=0
> >
>
> --
> English version:
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.d
> eepl.com%2Ftranslator&data=04%7C01%7Cglemson1%40jhu.edu%7Cd09
> d00c343c8470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0dec%7
> C0%7C0%7C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> mp;sdata=iTPCLg%2B32dqm8welwoBgbJWyyLBuixcTO3UkTeOQ6lc%3D&re
> served=0
> --
> 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
> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> unistra.fr%2F&data=04%7C01%7Cglemson1%40jhu.edu%7Cd09d00c343c8
> 470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7
> C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
> %2FW30DazZEMs7c21i%2BSmQT1voyCpFDNDyrVnNUreOAUU%3D&reserv
> ed=0>
> Observatoire Astronomique
> 11 Rue de l'Université
> F - 67200 Strasbourg
More information about the dm
mailing list