Obsc ore 1.1 WD

[Laurent Michel]

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

-- 
jesuischarlie

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
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