[Obscore1.1] WD comments / New content comments

[Arnold Rots]

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
On Jul 16, 2015 11:46 AM, "CresitelloDittmar, Mark" <
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
> > 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/20150717/70b12faf/attachment.html>