<p dir="ltr">I am a bit confused, since some of this also appears in a different thread. <br>
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. </p>
<p dir="ltr"> - Arnold </p>
<div class="gmail_quote">On Jul 16, 2015 11:46 AM, "CresitelloDittmar, Mark" <<a href="mailto:mdittmar@cfa.harvard.edu">mdittmar@cfa.harvard.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Mireille,<br><br></div>A couple quick notes<br><div><br><div><div><div><div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 10, 2015 at 2:55 PM, Louys Mireille <span dir="ltr"><<a href="mailto:mireille.louys@unistra.fr" target="_blank">mireille.louys@unistra.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">pg 25: Axes dimensions<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Outside of the pixelated image context, what values do these hold?<br>
For example, the sparse cube (ie: event list). do each of these hold<br>
the #events? or are s_dim1,s_dim2 == the span along that axis? and<br>
if so, in what frame?<br>
It seems that #events is closest to the description as the number of samples.<br>
<br>
</blockquote>
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.<br>
this is unprecise , I agree , but seems the best work around in case of unpixelated data.<br>
<br></blockquote><div>the new text:<br>"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."<br><br></div><div>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.<br></div><div><br><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
B3.5: creation date<br>
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). </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">added the reference to DAL
</blockquote><div><br><div>B4.5 also has the same ISO 8601 text for the release date element.<br></div><div> </div> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
B5: Data Access<br>
Refers to SSA for the Access object content. Which document is supposed to be the 'parent' in the Access standard hierarchy?<br>
<br>
</blockquote>
first defined in SSA , then re-used in ObsCore/ ObsTAP<br></blockquote><div><br></div><div>OK.. but this is an area of confusion for me.<br></div><div><br><br><div>ObsCore:Section 1.3:<br>"Specifically, this effort aims at defining a database table to describe astronomical datasets<br>(data products) stored in archives that can be queried directly with the TAP protocol. This is <br>ideal for global data discovery as any type of data can be described in a straightforward and <br>uniform fashion. The described datasets can be directly downloaded, or IVOA Data Access <br>Layer (DAL) protocols such as for accessing images (SIA) or spectra (SSA) can be used to <br>perform more advanced data access operations on the referenced datasets."<br></div><br></div><div>Which tells me that ObsCore/ObsTap is the fundamental model/standard which specialized<br></div><div>protocols may build upon (SIA/SSA). So, ObsCore should be the parent/owner of commonly<br></div><div>used elements (like Access).<br><br></div><div>SSA-V1.1 and SIA-V1.0 do not reference ObsCore at all. <br>SIA-V2.0 is expressed in terms of ObsCore.. so there is a migration to ObsCore as parent.<br></div><div>Given that, having this element 'inherited from the SSA Utype list' is an arrow going in the<br></div><div>wrong direction. If it is a matter of crediting the source, then a change in language such as<br></div><div> "extracted from SSA-1.0" or "first described in SSA-1.0"<br></div><div>would provide the credit, while allowing this definition to be the primary.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
B6.1.1:<br>
The description seems very pixelated data specific.<br>
<br>
</blockquote>
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.<br>
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.<br>
<br>
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 ?<br></blockquote><div><br></div>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.<br><br></div><div class="gmail_quote">Mark<br><br></div><br></div></div></div></div></div></div></div>
</blockquote></div>