[Obscore1.1] WD comments / New content comments
Laurent Michel
laurent.michel at astro.unistra.fr
Fri Jul 17 15:18:30 CEST 2015
Le 17/07/2015 11:15, Arnold Rots a écrit :
> I am a bit confused, since some of this also appears in a different thread.
> If you want to describe an event list in a formally correct way, you should describe it as a sparse cube with n sub-cubes which
> all have all of their axis sizes set to 1 and where n is the number of events.
>
> - Arnold
You're suggesting a new DM specific for event lists, aren't you?
In our case, I don't think that Obscore aims at describing event lists "in a formally correct way" nor any other class of
dataset. It just provides a simplified view on those dataset helping users for discovering data. In that sense, it just has to
expose the parameters required to validate all referenced use cases and the number of events of an event list is one of these
parameters. But I agree with you that there is no obvious location in the current model to put the event number. Using t_time
exclusively is not really satisfactory (IMO).
Laurent
>
> On Jul 16, 2015 11:46 AM, "CresitelloDittmar, Mark" <mdittmar at cfa.harvard.edu <mailto:mdittmar at cfa.harvard.edu>> wrote:
>
> Mireille,
>
> A couple quick notes
>
> On Fri, Jul 10, 2015 at 2:55 PM, Louys Mireille <mireille.louys at unistra.fr <mailto:mireille.louys at unistra.fr>> wrote:
>
> pg 25: Axes dimensions
>
> Outside of the pixelated image context, what values do these hold?
> For example, the sparse cube (ie: event list). do each of these hold
> the #events? or are s_dim1,s_dim2 == the span along that axis? and
> if so, in what frame?
> It seems that #events is closest to the description as the number of samples.
>
> changed : I have included Doug 's suggestion to allows #events to be an as an estimated size for t_dim in case of an
> event list.
> this is unprecise , I agree , but seems the best work around in case of unpixelated data.
>
> the new text:
> "In the case of event lists where the axes are not sampled, one could extrapolate all the dimensions by using the number of
> collected events as an estimation for t_dim, and set all other dimensions to NULL. In any case, the event list would need a
> binning processing before being projected as a pixelated dataset."
>
> I think this is too vague, and event list directed. If these elements are added to the required ObsCore list, then the
> values for them must be explicitly defined for all cases of the flavors listed by the dataProductType field. (BTW: That
> list could be tweaked to match the DatasetMetadata list.. adding 'catalog' and 'photometry'). I'm assuming this can be
> reduced to 'pixelated' and 'non-pixelated' data products.
>
>
> B3.5: creation date
> Shouldn't we update this to clarify that this is not strictly ISO 8601, but rather, the FITS standard which is 8601
> without the "Z" tag. There was a discussion on this some time ago, and that is the language folded into the
> DatasetMetadata model (Section 6.4.1.1).
>
> added the reference to DAL
>
>
> B4.5 also has the same ISO 8601 text for the release date element.
>
> B5: Data Access
> Refers to SSA for the Access object content. Which document is supposed to be the 'parent' in the Access
> standard hierarchy?
>
> first defined in SSA , then re-used in ObsCore/ ObsTAP
>
>
> OK.. but this is an area of confusion for me.
>
>
> ObsCore:Section 1.3:
> "Specifically, this effort aims at defining a database table to describe astronomical datasets
> (data products) stored in archives that can be queried directly with the TAP protocol. This is
> ideal for global data discovery as any type of data can be described in a straightforward and
> uniform fashion. The described datasets can be directly downloaded, or IVOA Data Access
> Layer (DAL) protocols such as for accessing images (SIA) or spectra (SSA) can be used to
> perform more advanced data access operations on the referenced datasets."
>
> Which tells me that ObsCore/ObsTap is the fundamental model/standard which specialized
> protocols may build upon (SIA/SSA). So, ObsCore should be the parent/owner of commonly
> used elements (like Access).
>
> SSA-V1.1 and SIA-V1.0 do not reference ObsCore at all.
> SIA-V2.0 is expressed in terms of ObsCore.. so there is a migration to ObsCore as parent.
> Given that, having this element 'inherited from the SSA Utype list' is an arrow going in the
> wrong direction. If it is a matter of crediting the source, then a change in language such as
> "extracted from SSA-1.0" or "first described in SSA-1.0"
> would provide the credit, while allowing this definition to be the primary.
>
> B6.1.1:
> The description seems very pixelated data specific.
>
> yes , absolutely . I think it is quite natural that in the discovery process , one might want to guess the number of
> points available for an observation on the sky.
> For a user, I imagine the next step after discovery might be a preview , as an image or as an histogram or a graphical
> representation of some sort showing the properties of the dataset.
>
> Would it be possible to describe a use-case scenario , where a user wants to discover x-ray event-lists and select them
> using various binned representations ? or are there specific criteria , like snr , etc that are not covered in Obscore
> , but should be specified in the Use-cases of the Cube DM ?
>
>
> I'm not sure I understand this response. My comment here is a basically the same as for the ObsTap field definition (see
> above). The description is very pixelated data specific, but the element applies to both pixelated and non-pixelated
> observation datasets.
>
> Mark
>
>
--
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
More information about the dm
mailing list