DM Workshop wrap-up
Gerard Lemson
glemson1 at jhu.edu
Tue Aug 24 16:26:18 CEST 2021
Hi Mark
> -----Original Message-----
> From: Mark Taylor <m.b.taylor at bristol.ac.uk>
> Sent: Tuesday, August 24, 2021 9:39
> To: Gerard Lemson <glemson1 at jhu.edu>
> Cc: Laurent Michel <laurent.michel at astro.unistra.fr>; dm at ivoa.net
> Subject: RE: DM Workshop wrap-up
>
> Gerard,
>
> the xmlns:xxx namespacing attribute just has to be in scope wherever the xxx
> namespace is used, so it's fine to put it in the root VOTABLE element. Since
> this is at the level of XML syntax though, it may not be wise to mandate that
> it goes there or for client software to rely on its specific form or position.
>
> I wouldn't want to add requirements to normal VODML usage that make my
> "topcat session" usecase more convenient, since it's far from the "normal"
> way that VODML is likely to be used, for which I guess a single VODML element
> per document will be a good choice.
> I'm happy to work round inconveniences; I'd just rather that what I want to
> do isn't flat out illegal.
>
Well I guess it is too late for that 😊
In any case I think we agree it is up to the mapping spec to make any statements about this.
gerard
> Mark
>
>
> On Tue, 24 Aug 2021, Gerard Lemson wrote:
>
> > 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%2F
> > > > gith
> > > > 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%2F&data=04%7C01%7Cglemson1%40jhu.edu%7C8b32efd49acb4e9be
> ee50
> > >
> 8d967048968%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C63765409
> 145
> > >
> 1420567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIi
> > >
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3OXASQmWttznROEI
> BvnK
> > > wpBUrqT%2By78dBpyfut%2BWEAM%3D&reserved=0
> > >
> 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
> >
>
> --
> 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
> C8b32efd49acb4e9beee508d967048968%7C9fa4f438b1e6473b803f86f8aedf0d
> ec%7C0%7C0%7C637654091451420567%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> 0&sdata=0w8mizzb79esV0GB9rRLDfcdykRBbU95slWhYZJ%2ByIs%3D&
> ;reserved=0
More information about the dm
mailing list