Obsc ore 1.1 WD

Louys Mireille mireille.louys at unistra.fr
Thu Oct 8 20:53:11 CEST 2015 

Dear Tom, dear list members,

I think I also support your point of view.

Pixels or let say numerical elements along one characterized axis
of a science ready data product  are the result of a sampling step in 
the detectors, followed eventually by  a projection in a
specified coordinate system.
An event , as far as is the physical phenomenon that is 
converted/projected into a grid element.

There are scientific features needed for a safe and rich interpretation 
of the content of data set, that are not covered in Obscore.
for instance :
- the signal to noise ratio in flux,
- the number on non null channels in a spectra
- the detection limit for a source in an image
- correlation factors between spaxels in a cube ,
- the proportion of good time intervals in a CTA observation,
- the spatial density of detected sources in an image or cube ( crowding 
factor- probably there should be a better english name for that, sorry )
etc
...
all this information is closer to the astronomers concerns for advanced 
dataset selection, but is context dependent.
I think the number of events in an event list belongs to this category.

This could be interesting to explore further use-cases for these 
specialized physical features  about the data content.

ObsCore should keep its general properties for global discovery , and 
CubeDM could tackle the 'interpretation profile' for various kinds of 
observation.

Best regards , Mireille








Le 08/10/2015 19:45, Tom McGlynn (NASA/GSFC Code 660.1) a écrit :
> I confess that I find this a bit weird. E.g., consider a telescope 
> with several coaligned photon-counting detectors (so multiple
> detectors are looking at the same or overlapping fields of view).
>
> After I combine detectors I can have sets of  multiple photons with 
> identical energy, time, and position.  The photons may have been 
> detected in different detectors originally, but the scientist has 
> thrown that information away as irrelevant.  The whole idea of a grid 
> to me is that we only see each grid element once, but now we have the 
> same grid element showing up multiple times.  To me a grid value 
> intrinsically
> represents some kind of integration over the grid area/volume. Events 
> typically represent discrete photons.  While there may be errors 
> associated with the measurement of the characteristics of the photon 
> (and Heisenberg suggests that there will be!) a photon is a different 
> class of beast than a grid element.   It's sort of like saying that 
> when we are taking a census of people we should treat them as a grid 
> of times and places of birth.  We could do so but seeing the grid as 
> the underlying structure seems wrong...
>
>     Regards,
>     Tom McGlyn
>
> Laurent Michel wrote:
>> Arnold
>>
>>
>> I agree with your remark. Event lists can be classified sparse cube. 
>> However, we do not have in Obscore a column giving a the product 
>> class (pixelated or not, sparse cube). We just have a product_type 
>> column with a limited vocabulary. There is no field giving 
>> explicitly  the product class which could help to interpret correctly 
>> the content of the S-T-E axes.
>>
>> For now the point is to decide whether I) it's better to complete 
>> Obscore 1.1  with just the *dim and the extended list of product_type 
>> or II) whether we have to target a better description of these new 
>> categories of data products (new in term of Obscore) .
>> In my opinion, the option I) is safer until the event lists are 
>> better taken into account and modelled in the VO.
>>
>> Bye
>> Laurent
>>
>> Le 05/10/2015 18:48, Arnold Rots a écrit :
>>> I don't think event lists should be classified as /non-pixelated/.
>>> If we want to model data consistently, they should be classified as 
>>> /pixel lists/:
>>> each event is a pixel; we just end up with a sparse hypercube.
>>> If we were to add one more parameter: the total number of pixels in
>>> the data product, that would solve the problem. For solid cubes it
>>> would be the product of the *dims, for event lists the number of 
>>> events.
>>>
>>>    - Arnold
>>>
>>> ------------------------------------------------------------------------------------------------------------- 
>>>
>>> Arnold H. Rots Chandra X-ray Science Center
>>> Smithsonian Astrophysical Observatory                   tel: +1 617 
>>> 496 7701
>>> 60 Garden Street, MS 67 fax:  +1 617 495 7356
>>> Cambridge, MA 02138 arots at cfa.harvard.edu 
>>> <mailto:arots at cfa.harvard.edu>
>>> USA http://hea-www.harvard.edu/~arots/
>>> -------------------------------------------------------------------------------------------------------------- 
>>>
>>>
>>>
>>> On Mon, Oct 5, 2015 at 11:00 AM, Laurent Michel 
>>> <laurent.michel at astro.unistra.fr 
>>> <mailto:laurent.michel at astro.unistra.fr>> wrote:
>>>
>>>     Hello,
>>>
>>>     A consensus seems to be taking shape about the model evolution 
>>> for pixelated data:
>>>       + Adding several fields to provide the dimensionality in each 
>>> domain.  (s_dim, em_dim, etc) as described in the draft
>>>       + These are added as 'required' fields.. so must be populated 
>>> for all records
>>>       + These fields provide for instance the size of each image axis.
>>>
>>>     These new fields can however not be used to provide a robust 
>>> representation the dimension of non pixelated data (e.g. number
>>>     of event in an event list)
>>>
>>>     The proposal to complete the version would be:
>>>       1) To keep the new *dim* fields
>>>       2) To support the EventList and other non pixelated as 
>>> product_type
>>>       3) To clearly specify that the *dim* columns must be set with 
>>> NaN for non pixelated data.
>>>       4) To provide some use cases about discovering non pixelated 
>>> data with ObsTap
>>>
>>>     That would quiclky allow us to start the RFC period for ObsCore 
>>> without having to wait on a agreement about how to model non
>>>     pixelated data
>>>
>>>
>>>     Laurent
>>>
>>>     --
>>>     jesuischarlie
>>>
>>>     Laurent Michel
>>>     SSC XMM-Newton
>>>     Tél : +33 (0)3 68 85 24 37 
>>> <tel:%2B33%20%280%293%2068%2085%2024%2037>
>>>     Fax : +33 (0)3 )3 68 85 24 32
>>>     laurent.michel at astro.unistra.fr 
>>> <mailto:laurent.michel at astro.unistra.fr> 
>>> <mailto:laurent.michel at astro.unistra.fr
>>>     <mailto:laurent.michel at astro.unistra.fr>>
>>>     Université de Strasbourg <http://www.unistra.fr>
>>>     Observatoire Astronomique
>>>     11 Rue de l'Université
>>>     F - 67200 Strasbourg
>>>     http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34
>>>
>>>
>>
>


-- 
Mireille Louys	, Maître de conférences
Centre de Données ( CDS)		Icube & Télécom Physique Strasbourg, Pôle API
Observatoire de Strasbourg 		300, boulevard Sébastien Brant
11, Rue de l'Université			CS 10413
67000 Strasbourg 				F - 67412 ILLKIRCH Cedex
http://astro.unistra.fr			http://www.telecom-physique.fr
tel : 03 68 85 24 34

More information about the dm mailing list