DM Workshop wrap-up
Gerard Lemson
glemson1 at jhu.edu
Tue Aug 24 15:24:05 CEST 2021
Hi Laurent and Mark
I think making RESOURCEs the containers of set of TABLEs all mapped as a group for a given (set of) model(s) makes sense.
Also adds some nice semantics to the RESOURCE element.
Would we need an explicit xmlns:dm-mapping declaration for the vo-dml-mapping schema's targetNamespace in each VODML element?
Or could that go inside the root VOTABLE element? This could be used by parsers to infer that vo-dml-mapped elements may be encountered.
Wherever it goes, is it a MUST to use the prefix 'dm-mapping'?
I guess that would simplify Mark's use case of gathering a bunch of votables into one?
Cheers
Gerard
> -----Original Message-----
> From: dm-bounces at ivoa.net <dm-bounces at ivoa.net> On Behalf Of Mark
> Taylor
> Sent: Tuesday, August 24, 2021 8:47
> To: Laurent Michel <laurent.michel at astro.unistra.fr>
> Cc: dm at ivoa.net
> Subject: Re: DM Workshop wrap-up
>
> 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fivoa-
> std%2FVOTable%2F&data=04%7C01%7Cglemson1%40jhu.edu%7
> >
> Ca6352f3d0b8545668f8e08d966fd5e41%7C9fa4f438b1e6473b803f86f8aedf0de
> c%7
> >
> C0%7C0%7C637654060675797377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMD
> >
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JP
> 4j
> > r5NzNhlHYgwOTlet07FUzvjAwGWrDYCfq7gKWjs%3D&reserved=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.
> >
> deepl.com%2Ftranslator&data=04%7C01%7Cglemson1%40jhu.edu%7Ca6
> 352f3
> >
> d0b8545668f8e08d966fd5e41%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7
> C0%7
> >
> C637654060675807368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIj
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PtRNsWV
> 9Vrq6
> > 9%2BBUPjA7BlZoQEgSKurFo%2FbAXNtKxYQ%3D&reserved=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%7Ca6352f3d0b85
> 4566
> >
> 8f8e08d966fd5e41%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C6376
> 5406
> >
> 0675807368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luMzI
> >
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ywbUMN0Km5tgk45
> jBR0vv
> > ZmyISyafdyPVdMBPim9%2BLc%3D&reserved=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
> Ca6352f3d0b8545668f8e08d966fd5e41%7C9fa4f438b1e6473b803f86f8aedf0de
> c%7C0%7C0%7C637654060675807368%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> 0&sdata=eiBaOQr5dtAQ5wPyzrPzibDQ7Kat4HKfS18sDAUMFEE%3D&r
> eserved=0
More information about the dm
mailing list