[Obscore1.1] WD comments / New content comments
Arnold Rots
arots at cfa.harvard.edu
Tue Jul 21 19:01:58 CEST 2015
Quite a while ago we suggested to use the sparse hypercude as the root of
the
model for the data structure. The two extreme cases of a sparse hypercube
are
the full contiguous hypercube (a sparse hypercube consisting of one
sub-cube)
and the event list (where each sub-cube consists of a single voxel).
It's a concept that covers all our cases (I think).
- Arnold
On Jul 17, 2015 9:18 AM, "Laurent Michel" <laurent.michel at astro.unistra.fr>
wrote:
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20150721/3ae7bfef/attachment.html>
More information about the dm
mailing list