Appendix Use cases A.2.3 and A.2.4

[loumir]

In both use-cases, the constraint on data product type reads "data_productype=timeseries"
but as we are dealing with light curves here , this should be replaced by "data_productype=light-curve"

then I think the "data product subtype =flux" constraint could be changed to o_ucd = 'phot.flux'

For searching aperture photometry probability density functions, we need to mention which variable is evaluated in the pdf file , so for this special use case
we could search for data_product_type='pdf' and o_ucd= 'stat.probability;phot.aperture' (aperture photometry probability density functions)

an add on for the definitions of advanced products 's types:
if the advanced data product 'pdf' becomes an all wavelength concept , other variables may be evaluated for other domains, so it seems safer to me to attach the variable to the label like poserr-pdf , aperture-pdf , etc.

[iannevans]

In both use-cases, the constraint on data product type reads "data_productype=timeseries" but as we are dealing with light curves here , this should be replaced by "data_productype=light-curve"

I don't see a 'light-curve' dataproduct_type defined in the ObsCore REC version 1.1 (section 3.3.1). The relevant dataproduct_type in the REC appears to be 'timeseries'.

then I think the "data product subtype =flux" constraint could be changed to o_ucd = 'phot.flux'

Bruno will need to address A.2.4 dataproduct_subtype='flux'. Since it's data provider defined, maybe it is a standard definition for CTAO?

For searching aperture photometry probability density functions, we need to mention which variable is evaluated in the pdf file , so for this special use case we could search for data_product_type='pdf' and o_ucd= 'stat.probability;phot.aperture' (aperture photometry probability density functions)

For A.2.3, I used dataproduct_subtype = 'photometry' as a generic specifier for our aperture photometry PDFs. I think we could change this to use UCDs. The relevant query might look something like
(o_ucd = 'stat.probability; phot.count') OR
(o_ucd = 'stat.probability; phot.flux.particle; particle.photon') OR
(o_ucd = 'stat.probability; phot.flux.energy')
given that our aperture photometry PDFs include counts flux (count s^-1, i.e., phot.count), photon flux (photon s^-1, i.e., phot.flux.particle; particle.photon), and energy flux (erg cm^-2 s^-1, i.e., phot.flux.energy). Here I'm using the proposed extension to its fullest :-). I would prefer not to use phot.flux since as currently defined it is rather vague. I don't see 'phot.aperture' defined in UCD1+ version 1.6, but agree that it would be useful and would simplify the UCD query since it would match any type of aperture photometry PDF (if a specific type of aperture photometry flux is required then that would need to be specified as part of the query).

an add on for the definitions of advanced products 's types: if the advanced data product 'pdf' becomes an all wavelength concept , other variables may be evaluated for other domains, so it seems safer to me to attach the variable to the label like poserr-pdf , aperture-pdf , etc.

I believe that PDF is a multi-wavelength concept, as are the other dataproduct_types that we proposed ('response-function', 'draws', 'region'). I think the individual data provider will need the ability to more narrowly define the details of these types of data products (e.g., by using dataproduct_subtype) since I don't think we can exhaustively identify all the possibilities a priori.