DM Workshop wrap-up
Gerard Lemson
glemson1 at jhu.edu
Tue Aug 24 15:53:14 CEST 2021
Hi Laurent
> > Can we not "simply" have the mapping standard prescribe a particular
> *usage* of VOTable instead?
>
> That's my question.
> Can we accept to have a VOTable valid against the VOTable schema (including
> the mapping schema) but not against the mapping spec because the mapping
> block is not at the right place?
> If the answer is yes, let's move on.
>
I guess that would be an illegal mapping spec yes.
I guess a precedent might be a SSAP VOTable that is valid VOTable but does not conform to the SSA spec.
Gerard
> Laurent
>
>
>
> > 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%2Fgit
> >> hub
> >> .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%2F&data=04%7C01%7Cglemson1%40jhu.edu%7C971f4f13509444f2f64
> 608d
> >>
> 96705dd3b%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C6376540971
> 5644
> >>
> 3265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> IiLCJB
> >>
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=c7%2FhIxdd4SPvdxBb4lKs
> FLz
> >> f2Oi9umD0TLn8%2FtFMjTI%3D&reserved=0
> >>
> 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%2F&data=04%7C01%7Cglemson1%40jhu.edu%7C971f4f13509444f2f64
> 608d
> >>
> 96705dd3b%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C6376540971
> 5644
> >>
> 3265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> IiLCJB
> >>
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZQmeNTUfm4i%2Bn%2Fr
> ZNPQh%
> >> 2BMtkUos58mNdoEX29pCu2RQ%3D&reserved=0
> >>
> 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%2F&data=04%7C01%7Cglemson1%40jhu.edu%7C971f4f13509444f2f64
> 608d
> >>
> 96705dd3b%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C6376540971
> 5645
> >>
> 3263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> IiLCJB
> >>
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fqdU4MtQQar1fkcICRQW
> fQQZp
> >> 4rHIXHZ%2FMVfxC%2FuDV4%3D&reserved=0
> >>
> 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
>
> --
> English version:
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.d
> eepl.com%2Ftranslator&data=04%7C01%7Cglemson1%40jhu.edu%7C971f
> 4f13509444f2f64608d96705dd3b%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0
> %7C0%7C637654097156453263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> ;sdata=TiHkwqvvAtrllr2%2FGmwJL26Tr7aAKQWVewronN3z5GI%3D&reser
> ved=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%7C971f4f135094
> 44f2f64608d96705dd3b%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7
> C637654097156453263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=l
> rmeC%2Bv3zDf4QAruQm0ofXVjywphGDODb%2BIlz6uNDlE%3D&reserved=
> 0>
> Observatoire Astronomique
> 11 Rue de l'Université
> F - 67200 Strasbourg
More information about the dm
mailing list