MIVOT: RESOURCE relation to VOTable

[Laurent Michel]

Dear DM,

Le 14/12/2022 à 18:45, CresitelloDittmar, Mark a écrit :
> Hi,
> 
> Following-up on Markus' mail on RESOURCE location (http://mail.ivoa.net/pipermail/dm/2022-December/006292.html 
> <http://mail.ivoa.net/pipermail/dm/2022-December/006292.html>).
> 
>  From Section 3 of the MIVOT spec:
>    It looks like finding the annotation block boils down to:
>      - from RESOURCE with type='results'
>        - identify the contained child RESOURCE with
>            - type='meta'
>            - whose first child node is "VODML"

The requirement for the MIVOT block to be child of a resource at type=results is not necessary.
  either.
In my experience, many VOTables often come with data enclosed in resources without @type attribute.
> 
> I'm sure this was already discussed and I don't want to open a can of worms, but..
>    o the VOTable spec says that RESOURCEs can be nested into a tree.

Right

>    o the type attribute is optional, and the only spec'd value I see is for type="meta" which means the RESOURCE contains no data.
> 
> So, my questions are:
>    1. is MIVOT really linking its RESOURCE to a parent RESOURCE with specified type? or am I misreading the section?.
>        o the examples have type='results' on the parent.
>        o there were several example files in the workshop which do not have a type attribute on the RESOURCE. (eg: vizier files, 
> ZTF time series)

Workshop examples have been written before MIVOT was finalized.
You cannot take them as reference datasets.


>    2. has there been any consideration of an example with nested RESOURCEs?
>        I'm not sure what that might be, but maybe a "SED" resource, with sub-resources for each "SPECTRUM"?
> The rule  we agreed on was that the scope of the MIVOT block is the whole content of the enclosing resource.
No need to specify any @type for it.

The case of multiple MIVOT blocks located each in nested resources has not been considered.
We could apply in this case the same rule as for the e.g. Java local variables: the deepest wins; but does it worth to spend 
time on that very unlikely case?

Section 3 has to be updated as well

Laurent

Laurent--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurent_michel.vcf
Type: text/vcard
Size: 406 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20221216/8188d793/attachment.vcf>