[Heig] vocabulary update: proposal for dataproduct_type update for high energy data : event-list definition and event-bundle

[Dr. Ian N. Evans]

Hi Markus,

> On May 28, 2025, at 16:59, Markus Demleitner via heig <heig at ivoa.net> wrote:
> 
> Dear Colleagues,
> 
> On Wed, May 28, 2025 at 10:24:44PM +0200, BONNAREL FRANCOIS gmail via semantics wrote:
>> A query with  a constraint such as "WHERE ivoa_smaller(dataproduct_subtype,https://www.google.com/url?q=https://www.ivoa.net/rdf/responsefunction_type%23response-function&source=gmail-imap&ust=1749070770000000&usg=AOvVaw0-UO7t5qNoAXxTQHQYFCi9")
>> should validate for #psf, #lsf, #arf, etc....
> 
> Let me just mention that if there were such a response-function
> vocabulary, you could already write
> 
>  WHERE 1=gavo_vocmatch(
>    'response-function',   -- the vocabulary name
>    'response-function',   -- the concept name
>    dataproduct_subtype)   -- the column to match against
> 
> on https://www.google.com/url?q=http://dc.g-vo.org/tap&source=gmail-imap&ust=1749070770000000&usg=AOvVaw1TD0ibt7kg0b9dL6ZgPfVx (and other DaCHS services) and this would
> be true for all terms narrower than that #response-function.  This
> isn't actually hard to implement, so I'd be confident we could turn
> this into ivo_vocmatch (i.e., an interoperable UDF) rather easily.
> 
> If you're looking for something to try it out, try:
> 
> SELECT TOP 5 * FROM ivoa.obscore
> WHERE
>  1=gavo_vocmatch('product-type', 'spectrally-resolved-dataset', dataproduct_type)
> 
> on https://www.google.com/url?q=http://dc.g-vo.org/tap&source=gmail-imap&ust=1749070770000000&usg=AOvVaw1TD0ibt7kg0b9dL6ZgPfVx.  Ahem. Right now, there's only #spectrum
> coming back, but that's only because I'm not yet marking up the
> califa cubes as spectral-cubes.  Which I'll do as soon as an obscore
> WD is out that sanctions using product-type terms in the
> dataproduct_type column.
> 
> Anyway, if we decide that we need the narrower terms, I think I'd
> prefer to put them into dataproduct-type rather than create an extra
> vocabulary.  That's mainly to keep the vocabulary ecosystem as small
> as we can; in this new view on the response functions, these *are*
> (perhaps somewhat odd) sorts of data products, after all.
> 
> Oh, and while I'm talking: Ian's post this morning my time about the
> numbers of matches for Chandra's response functions does suggest we
> may want the narrower terms (#irf and friends); on the other hand,
> the 6'010 rows for #rmf is probably still too much for efficient
> discovery and as such not a *tremendous* progress over the 104'740
> you'd get for #response-function.

I don’t think returning 6K rows is necessarily unreasonable.  A lot of catalog science (across all wavebands) are studies of populations of objects so you might expect that such samples might include thousands of matching rows.

That said, I don’t know that anybody would make a query of RMFs like this.  I can potentially see users wanting to do this sort of query for PSFs, and perhaps even ARFs (the former because they vary substantially across the field of view [although it wouldn’t make sense with a 15 arcsec radius constraint] and the latter because they vary with epoch as the response of the telescope has changed with time).  But I still think efficient discovery in this space (i.e., with many matching targets) will require differentiating between response-function types.


> 
> So... What would people do to pick the rmf they actually need from
> the obscore result?  Or do they really need them all?  And wouldn't a
> possible extra constraint cut down the #response-function result to a
> reasonable size, too?

Again, it depends on what you are doing.  For example, to find the PSFs for a particular source and observation, one might do a query like 

SELECT * FROM ivoa.obscore
NATURAL JOIN ivoa.obscore-hea
WHERE
(CONTAINS(POINT(s_ra, s_dec), CIRCLE, 83.843583, -5.436392, 0.00138888889) = 1)
AND (dataproduct_type EQ ‘response-function’)
AND (dataproduct_subtype EQ ‘psf’)
AND (obs_id = ‘4374’)
AND (obs_collection = ‘CSC2’)

to identify PSFs for 2CXO J053522.4-052610 for obsid 4374.  This would return 5 files totaling 417,600 bytes (PSFs in each of the CSC ultrasoft, soft, medium, hard, and broad energy bands), which could be reduced further by constraining the energy range.  Note that in very crowded fields like this (the Orion star forming region), the number of matching products increases exponentially with search radius.


> 
> Thanks,
> 
>             Markus
> 
> -- 
> heig mailing list
> heig at ivoa.net
> https://www.google.com/url?q=http://mail.ivoa.net/mailman/listinfo/heig&source=gmail-imap&ust=1749070770000000&usg=AOvVaw088Yf8vDWU-ZzWSgtAtny4


Cheers,
—Ian
—

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



 


 <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/20250529/ab4e59b3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 581 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20250529/ab4e59b3/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-3.png
Type: image/png
Size: 21717 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20250529/ab4e59b3/attachment-0003.png>