[Heig] Start up of our HEIG
BONNAREL FRANCOIS gmail
francois.bonnarel at gmail.com
Tue Feb 11 17:09:03 CET 2025
Dear Ian,
> -------- Message transféré --------
> Sujet : Re: [Heig] Start up of our HEIG
> Date : Fri, 24 Jan 2025 14:53:07 -0500
> De : Dr. Ian N. Evans <ievans at cfa.harvard.edu>
> Pour : BONNAREL FRANCOIS gmail <francois.bonnarel at gmail.com>
> Copie à : Bruno Khelifi <khelifi at apc.in2p3.fr>, heig at ivoa.net
>
>
>
> Dear François,
>
> Good to hear your feedback! This document was literally written as a
> level 0 starting point, with the hope that it would prompt others to
> chime in so we can refine what is needed to support the HE regime.
> And, like all my inputs, it was written from the perspective of
> somebody who wants to be able to use the IVOA to do science rather
> than from the perspective of somebody who has to do the implementation
> - i.e., it’s results oriented and not task oriented.
>
> I do have some responses to your comments - again mostly from the
> perspective of what the issue is that I see rather than how to solve it.
>
>
Thank you for this.
> — For o_ucd, o_unit etc.: I want to know as part of data discovery
> that a particular event list includes certain observables. Ideally, I
> would like to do this as part of the query - for example, I might only
> interested in event lists that include X-ray polarization observables.
> Adding new axes characterization may be the best way to move forward
> simply given what we already have, but it just seems to me that
> assuming that a dataset includes only a single observable is very
> limiting (especially when we start talking about advanced data products).
As already said I think an extension may add other variables (such as
polarization observables for example) as additional axes. of course it's
not possible for everything. On the other side the current spec (1.1)
writes (section 4.20) "In the case of event lists all components could
be considered as observables prior to sampling, then o_ucd must be left
NULL, unless the data provider wants to highlight a specific axis like
phot.count." This maybe also a solution for polarization or
a quantity (with a ucd to define) more appropriate than phot.count.
There are also possibilities to combine several ucd in some cases
>
> — s_fov, s_resolution etc.: I think the CADC proposal is helpful here.
> But it doesn’t really let me perform a query like “find me all
> Chandra datasets for which the spatial resolution at the location of
> Sgr A* in the field of view is < 2 arcsec”. I don’t know how to do
> this and it might indeed be non-trivial.
Sure. But ObsCore (and even with possible extensions) will always be
some corse graining query. With the query you should be able to exclude
90% (or more) of the datasets not answering your constraints. Then check
the remaining response in more detail. And for this overall resolution
min and max for the whole dataset may help
> Is this functionality needed in the UVOIR?
Min and max for spatial resolution have never been considered as missing
by these communities so far, as far as I know. The idea of extension
specific to a domain is to not overload everybody with a too large root
ObsCore. But of course if min max are needed by both Radio and HeiG the
should try to share the
same definitions
> Perhaps. I know from experience analyzing UV/optical objective
> prism data that spectral resolution across a single dataset can easily
> vary by a factor of 20 or more, so that is in a similar regime.
in wavelenght unit ? But UV/optical use unitless resolution power ? Is
that also the case for that one ? I don't really know or remeber actually
> Having worked with instrumentation in pretty much every waveband from
> radio to X-ray during my career, my view is that you are better off
> providing a capability generally in case somebody needs it in the
> future, since new instrumentation and techniques are being developed
> all the time.
>
> — dataproduct_type: I agree with you that the vocabulary appears to be
> the right path forward. I noted in my Malta presentation that
> “spectrum” as currently defined in the data product vocabulary appears
> to be more restrictive than the ObsCore definition (and “light curve”
> is similar), so we should start there.
Yes the obscore vocabulary is work in progress. It's still possible to
add terms and change definitions. Fo example distinguishing "light
curves" from the UV/optical/IR from more general time series
> Perhaps the issue in the vocabulary is simply due to a lack of
> precise definitions for the terms used IN the vocabulary!
Sure
>
> — energy_min/max: In this particular case I believe that there is a
> technical issue that means that 32 bit em_min/max actually don’t work
> at VHE. IIRC, Bruno pointed this out.
OK
>
> — t_min/max, t_gti: I really think this should be addressed in core
> rather than just a HE extension for GTIs/STIs. Advanced data products
> - irrespective of waveband - may be comprised from data from many
> observations may span decades or more, albeit very sparsely, and that
> makes queries based on data overlap with a specified time interval
> undoable.
OK. Could Make sense for HST Drizzled images and HiPS also (which is
based on some kind of stacking also). But nobody is findinh HiPS by
ObsCore at the moment.
>
> — irf_type/assocproduct_type etc.: Datalink may be the way to do this
> as you suggest. I don’t know that instrument responses necessarily
> have to be in ObsCore independently, although someone may want to
> access them independently from the event list (for example, if they
> are directly using a source spectrum data product). For advanced data
> products, we would definitely want to include some associated data
> products in ObsCore as they will be of interest in their own right.
I looked at the list you provided in Malta. I don't think you will
expose all of them directly in ObsCore. So some kind of compromise
between datalink linkage and direct ObsCore integration (for example
standard spectra) with possibly new product type terms seems to be
possible
By the way I also have a comment on your Malta slides about
"observation". I think section 3.3.3 of ObsCore 1.1 clarifies (with
respect with 1.0) the difference between observation and
observationDataset on one side and observationDataset and dataproducts
on the other side. It also allows observationDataset has being the
combination of several observation results (by stacking for example)
An ObservationDataset may be coming from several observations
(considered as a new "observation") but may also contain several data
products (rows in Obscore). So what you have chosen for advanced data
products seem to be standard
> Hope you are enjoying retirement!
>
Well I am slowly landing on the "country" of this new situation. Not
really suited yet. I a little more time to sleep.
Cheers
François
> Cheers,
> —Ian
>
>
>> On Jan 24, 2025, at 09:36, BONNAREL FRANCOIS gmail via heig
>> <heig at ivoa.net> wrote:
>>
>> Dear all,
>> I will not attend the meeting today.
>> I had a quick look on this interesting document :
>> https://wiki.ivoa.net/internal/IVOA/HEIG_Winter25/HEIG_obscore_summary.pdf
>> These are my retired person with radio domain eye 2 cents on this :
>> + o_ucd, o_unit, etc... multiplicity :
>> In the case of event lists with specific axes ("new"
>> measured quantities) I wonder if o_ucd is the right place to tackle
>> that. o_ucd was designed for the "dependant axis". Maybe adding new
>> axes characterization should be a better choice. Look at the
>> description of visibilities in the radio extension.
>> + s_fov,s_resolution, etc.. min/max with dependency from the
>> spectral coordinate (photon energy).
>> This is a common issue with radio domain as you know. CADC
>> proposed recently to add this in the root Obscore.But
>> I wonder if UV/optical/IR astronomers really need that. We
>> should not add to much in the root ObsCore. maybe common definition
>> with the the radio domain is a better solution.
>> / + dataproduct_type : the current ObsCore vocabulary is limited.
>> I think the IVOA dataproduct_type effort is the right place to define
>> . To my knowledge it's not yet an official vocabulary and adding new
>> termis is easy to do following the/
>> /VEP procedure of vocab 2.0. So that's the place to play in for Heog
>> people./
>> //+ t_min/t_max : see t_gti
>> + proposal_id : OK for multiplicity
>>
>> New terms :
>> + ev_number : OK. I think there is even an IVOA
>> characterization DM utype for that.
>> + energy_min / energy_max : OK. But I think you know the
>> equivalent f_min/f_max for radio domain was rejected by the community
>> fairing value conflicts in case of duplication with em_min/ em_max
>> (despite Mireille's an mine personal opinion)
>> + t_gti : OK. this is the concept of time support in
>> characterization terms. ascii tmoc is a possible format for that.
>> also look if DALI proposed an xtype for this kind of list of intervals.
>> + irf_ype , irf_description. I wonder if these complementary
>> data have to be in ObsCore or are better located in DataLink
>> associated to the main product (event list). In that case
>> content_qualifier is the place to describe the exact type.
>> + access_format, UCDS : I 'm OK with what is written
>>
>> Cheers
>>
>> François
>>
>>
>> Le 23/01/2025 à a$14:47, Bruno Khelifi via heig a écrit :
>>>
>>> Dear all,
>>>
>>> For the meeting of tomorrow, I send you a Zoom link (that I have
>>> reported in our meeting page of the Wiki):
>>>
>>> Link:https://u-paris.zoom.us/j/86351476440?pwd=2YMHRRAvFvIgLbdftUt0d4GAa1USmL.1
>>>
>>> Meeting ID: 863 5147 6440
>>> Secret code: 937310
>>>
>>> The best,
>>> Bruno
>>>
>>> Le 20/01/2025 à 18:08, Bruno Khelifi via heig a écrit :
>>>>
>>>> Dear all,
>>>>
>>>> Based of the pool outcome, the best time slot is the ideal one
>>>> because some of you could not attend unfortunately. However,
>>>> the meeting is fixed to this *Friday 24th, 15h30 CET / 9:30 am EST*.
>>>>
>>>> The draft meeting page can be found here:
>>>> https://wiki.ivoa.net/twiki/bin/view/IVOA/HEIG_Winter25. A meeting
>>>> link will be sent by email soon and written in this page.
>>>>
>>>> The best,
>>>> Janet and Bruno
>>>>
>>>> Le 16/01/2025 à 12:21, Bruno Khelifi a écrit :
>>>>>
>>>>> Dear all,
>>>>>
>>>>> First of all, I profit of my email for the season's greetings.
>>>>> Best wishes to you and your relatives for this new year. We
>>>>> finished up 2024 with the creation of the HEIG with its attached
>>>>> note, which is an important achievement for the HE community.
>>>>> Congratulations to all !
>>>>>
>>>>> As starting point for our activities, we propose to remotely meet
>>>>> via Zoom to exchange about our roadmap for 2025, built from your
>>>>> collective inputs. This roadmap will be a guideline for our future
>>>>> meetings. Here is a doodle to find out the most appropriate date:
>>>>> https://doodle.com/meeting/participate/id/bD6Z5Oye
>>>>>
>>>>> The tentative agenda is:
>>>>> - IVOA news (Janet)
>>>>> - 2025 roadmap: collection of items and definition (all)
>>>>> - Organisation of HEIG: monthly meetings? and next hybrid meeting
>>>>> - Thematic remote meeting: Obscore extension proposal by Patrick
>>>>> Dowler (see Janet's email of the 01/06/25)
>>>>> - AoB (based on your feedback)
>>>>>
>>>>> The best,
>>>>> Janet and Bruno
>>>>>
>>>>>
>>>>> Material: HEIG wiki page
>>>>> https://wiki.ivoa.net/twiki/bin/view/IVOA/HEGroup
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Bruno Khelifi
>>>>> Physicist at CNRS (laboratory APC, Paris)
>>>>> Phone: +33.1.57.27.61.58 - Fax: +33.1.57.27.60.71
>>>>> APC, IN2P3/CNRS - Universite de Paris Cite
>>>> --
>>>>
>>>> Bruno Khelifi
>>>> Physicist at CNRS (laboratory APC, Paris)
>>>> Phone: +33.1.57.27.61.58 - Fax: +33.1.57.27.60.71
>>>> APC, IN2P3/CNRS - Universite de Paris Cite
>>>>
>>> --
>>>
>>> Bruno Khelifi
>>> Physicist at CNRS (laboratory APC, Paris)
>>> Phone: +33.1.57.27.61.58 - Fax: +33.1.57.27.60.71
>>> APC, IN2P3/CNRS - Universite de Paris Cite
>>>
>>
>> --
>> heig mailing list
>> heig at ivoa.net
>> https://www.google.com/url?q=http://mail.ivoa.net/mailman/listinfo/heig&source=gmail-imap&ust=1738334209000000&usg=AOvVaw1r64WsMg9G79BexrwpHtWh
>
> —
> Dr. Ian Evans
> *Astrophysicist*
> *Chandra X-ray Center*
> Center for Astrophysics | Harvard & Smithsonian
> Office: (617) 496 7846 | Cell: (617) 699 5152
> 60 Garden Street | MS 81 | Cambridge, MA 02138
>
> PastedGraphic-2.png
>
> PastedGraphic-3.png_
>
> <http://cfa.harvard.edu/>__cfa.harvard.edu
> <http://cfa.harvard.edu/>_ | _Facebook
> <http://cfa.harvard.edu/facebook>_ | _Twitter
> <http://cfa.harvard.edu/twitter>_ | _YouTube
> <http://cfa.harvard.edu/youtube>_ | _Newsletter
> <http://cfa.harvard.edu/newsletter>_
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20250211/0a91795b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iZ87Cpo1qkWUMJtP.png
Type: image/png
Size: 370 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20250211/0a91795b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dZuc90OzsCOrL2Xy.png
Type: image/png
Size: 8364 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20250211/0a91795b/attachment-0003.png>
More information about the heig
mailing list