[Heig] Fwd: HEIG Meeting - Wed, May 21

[BONNAREL FRANCOIS gmail]

Dear all,
Thank you Janet, Mark for this

I will also miss the meeting today.
I have a comment on Mark's bullets 2 and 3.

for s_resolution_min and s_resolution_max : It's true that nobody paid 
attention to the fact they were already there in
ObsCore. I think almost nobody implemented them in their service anyway.
Probably the need for Central spectral domains was very low.
Obviously the situation was really different for radio interferometry 
(where the resolution is proportional to the wavelength or so where 
spectral ranges may be large. I don't think it's the case for IFU cubes) 
reason why we focused on it as Mark says.

for s_fov, the difference with central spectral domain is the same (and 
in addition we did't have the min/max in ObsCore).

As I already wrote I am a little afraid to force central spectral domain 
data providers to add terms they didn't needed so far in the "core 
ObsCore" (root Obscore) in the future. I know that some people's answer 
to that statement is : provide min=max if you don't care . Humm....

Common definitions for common terms  in two extensions is required and 
not that difficult to proceed I would say.

In the future (1.2 an later) the whole ObsCore could provide the full 
list of possible attributes that at least one community needs to 
describe her data and  in this large set we define subsets known as profiles
          - core or root
          - radio
          - heig
          - time

Cheers
François




Le 21/05/2025 à 12:46, Mark Kettenis via heig a écrit :
>> From: Janet Evans via heig <heig at ivoa.net>
>> Date: Wed, 21 May 2025 04:33:53 +0200
> Hi Janet & others,
>
> Sadly I have another meeting scheduled for that timeslot. There is a
> small chance that meeting ends early and I'll be able to join you
> towards the end of your meeting.
>
> I skimmed through the latest draft of the HEIG ObsCore extension and
> noticed a few things:
>
> * I think in 3.6 (s_ra/s_dec) you're basically saying that these
>    should describe the relevant position for the data product instead
>    of where you pointed your instrument.  And I think that is already
>    how ObsCore is used in practice.  An interesting example in Radio
>    are mosaics where an image is constructed based on multiple
>    pointings where pointings are to some extent separate observations
>    each with their own s_ra and s_dec.
>
>    That said, it should be realized that s_ra/s_dec and s_fov are
>    related in the sense that s_fov is the diameter of the area around
>    s_ra/s_dec covered by the observation/dataproduct that is being
>    described.  So in that sense it *has* to be the center.
>
> * It seems the note does not describe some of the attributes we
>    previously identified as possibly common between Radio and HE.
>    Primarily the _min/_max for some of the existing ObsCore attributes.
>    I recently realized that s_resolution_min/_max are actually defined
>    (but optional) in ObsCore.  So maybe that's wht they were left out.
>    But I believe s_fov_min/_max were also mentioned in HE context as
>    the FoV of many instruments can vary significantly with
>    wavelength/frequency/energy.  But also the intrument_ attributes and
>    the tracking/scan type were mentioned before.
>
> * The s_resolution_min/_max thing is interesting in the sense that I
>    had completely forgotten that they are already in ObsCore.  I think
>    they ended up in our draft because their defenition neede some
>    adjustment and because they were optional.  Because they're optional
>    ObsCore implementations don't include them (i.e. DaCHS does not
>    implement them in the standard ObsCore protocol definition).  I
>    think this points out that optional columns are a bit of a problem,
>    or at least that there will be extra challenges for data providers
>    to actually implement them.
>
> Have a good meeting!
>
>> Hi Folks,
>>
>> Just a reminder of our meeting tomorrow - Wed @14:00 UTC.
>>
>> Here’s a link to the meeting page:
>> https://wiki.ivoa.net/twiki/bin/view/IVOA/HEIG_21May25
>>
>> Here’s a link to the zoom:
>> https://smithsonian.zoom.us/j/97478328416?pwd=ZEpmMnI4RGhrS01pazF5dXBLbEsyZz09
>>
>>
>> Attached is the current Obscore Extension note for HEIG (with latest
>> putbacks from a few days ago).  Mark CD sent an email a day ago with the
>> questions we’ll review to prep for the Interop.
>>
>> from Mark CD:
>>
>> To help keep the focus on the roadmap for standardizing the extensions, I
>> would like to provide a summary of the various extension projects in an
>> introductory presentation, rather than have individual presentations on the
>> Notes.  For this, I’d like to ask each Interest Group to provide:
>>
>>      * A slide or 2 summary of
>>
>>            - the status of your Note
>>
>>            - the status of any implementations (implemented or planned)
>>
>>      * A statement on the following questions:
>>
>>            1. What are the features about your domain which require an
>> extension to ObsCore to facilitate discovery of your data?
>>
>>            2. Are there open questions which still need to be resolved with
>> your group on your Note?
>>
>>            3. Are there particular questions which you feel need discussion
>> at this session?
>>
>>                This could be about content that you feel needs careful
>> consideration by the community, or about the evolution of the documentation
>> during the standardisation process, or whatever.
>>
>> Thank you,
>> -janet
>>
>> ——————
>> Janet Evans
>> Chandra Data System Software Development Manager
>> Chandra X-ray Center
>> Center for Astrophysics | Harvard & Smithsonian
>>
>> Office: (617) 495 7160 | Cell: (617) 688 6084
>> 60 Garden Street | MS 81 | Cambridge, MA 02138
>>
>>   Begin forwarded message:
>>
>>   From: Janet Evans <jdeponte at cfa.harvard.edu>
>>   Subject: HEIG Meeting - Wed, May 21
>>   Date: May 15, 2025 at 11:00:37 AM EDT
>>   To: heig at ivoa.net
>>
>>   Hi HEIG Folks,
>>
>>   I’ve been in contact with Bruno and also met with Mark CD yesterday for
>>   some interop planning.  I would like to move our current meeting
>>   scheduled for May 28 to next week ***Wed, May 21***.  We need the time
>>   to prepare for the Interop.
>>
>>   Mark and I discussed the Obscore Plenary and he will distribute
>>   questions that each of the IGs working on Obscore extensions will answer
>>   for that session.   They will be a way to level the inputs from the IGs
>>   working on Obscore extensions and get a current status.   We discussed a
>>   few other contributing talks from WGs who will need to be involved (DM,
>>   DAL, Registry, Semantics) to help take this all to the next place of
>>   standard development.  For that purpose, **Use cases** in our new doc
>>   showing how the changes we are proposing are *very important*.  It
>>   brings context to our work for other WGs who need to integrate the
>>   proposal into the current system.
>>
>>   So 2 assignments:
>>   1) Think about answers to the Questions that will come out on Monday in
>>   prep for the Plenary session at the Interop - Topic for Wed!!
>>   2) Work on Use Cases … either directly in Github or you can send them to
>>   the HEIG list and someone will enter them for you. - Review status on
>>   Wed!!
>>
>>   ****Next meeting: *** Wed, May 21 @14:00 UTC***
>>
>>   I’ll work on the HEIG meeting page and publish that with a reminder
>>   early next week.
>>
>>   Thank you,
>>   -janet
>>
>>   ——————
>>   Janet Evans
>>   Chandra Data System Software Development Manager
>>   Chandra X-ray Center
>>   Center for Astrophysics | Harvard & Smithsonian
>>
>>   Office: (617) 495 7160 | Cell: (617) 688 6084
>>   60 Garden Street | MS 81 | Cambridge, MA 02138
>>
>> [2:application/pdf Show Save:HighEnergyObsCoreExt-draft-3.pdf (473kB)]
>>
>