Obsc ore 1.1 WD

[Tom McGlynn (NASA/GSFC Code 660.1)]

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
>>
>>
>