[Obscore1.1] WD comments / New content comments

[CresitelloDittmar, Mark]

Mireille,

A couple quick notes

On Fri, Jul 10, 2015 at 2:55 PM, Louys Mireille <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20150716/a61dbcb1/attachment.html>