<div dir="ltr"><div><div><div><div><div><div><div><div><div>Yes, I think this would work.<br></div>There is a slight peculiarity, in that the units can be specified, but do not apply to the metadata.<br></div>However, there may be good reasons to do that?<br></div>Also, it does not accommodate the use of z instead of Doppler velocity.<br></div>That could be accommodated by allowing REDSHIFT as a valid type for the Doppler type<br></div>and it's not urgent that that be added at this point.<br></div>However, if one were to do it that way, the prescribed units for the bounds cause a problem;<br></div>that might be an argument in favor of having the specified unit apply to the metadata, too.<br><br></div>Cheers,<br><br></div> - Arnold<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory tel: +1 617 496 7701<br>60 Garden Street, MS 67 fax: +1 617 495 7356<br>Cambridge, MA 02138 <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Thu, Apr 23, 2015 at 11:25 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marco , Hi all ,<br>
<br>
I think your use-case corresponds to the current questions we have about axes description.<br>
<br>
I proposed together with Doug Tody , some way to describe the velocity axis, and showed this in Banff.<br>
the slides are here : <a href="http://wiki.ivoa.net/internal/IVOA/InterOpOct2014DM/obcore-ObsdatasetDM_compatibility.pdf" target="_blank">http://wiki.ivoa.net/internal/IVOA/InterOpOct2014DM/obcore-ObsdatasetDM_compatibility.pdf</a><br>
<br>
Do you think you could reconsider the table I shown , page 5 and check if columns starting with d_ would help in your case.<br>
There has been several iterations with Doug Tody about this axis description.<br>
I am eager to know if that would fit your needs or not.<br>
<br>
Cheers , Mireille.<br>
<br>
<br>
Le 23/04/2015 15:50, Marco Molinaro a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Markus, hi all,<br>
if this reply is confusing it's probably me not completely getting the<br>
points.<br>
So...if you get lost, discard this reply from your inbox.<br>
<br>
2015-04-23 11:57 GMT+02:00 Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
:<br>
Dear DAL, dear DM,<br>
<br>
On Thu, Apr 23, 2015 at 09:51:46AM +0200, Marco Molinaro wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
regarding this topic I have a small use case that comes from a (currently<br>
custom) set of services whose aim is to allow velocity spectra analysis<br>
</blockquote>
of<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
galactic FITS cubes.<br>
</blockquote>
That's a perfect use case for obscore+datalink, I'd say.<br>
<br>
</blockquote>
sure, it can also fit a SIAv2 plus AccessData, I think.<br>
Honestly I'm quite puzzled on the way to go, I'll vote for providing both,<br>
at least on the long term,<br>
even if currently a related service is already a TAP one, so obscore should<br>
be a direct extension.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
a - a super-set of FITS cubes from non-homogeneous galactic surveys and<br>
pointed archives in the radio band is deployed to allow velocity spectra<br>
analysis<br>
b - the first step for the user is to search in this set for available<br>
</blockquote>
data<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
along a line-of-sight, with possible filtering on a cone around it, or a<br>
box around it, limiting the velocity range, selecting explicitly one/more<br>
survey(s) by name, species, transition, ...<br>
</blockquote>
It seems to me most of the necessary metadata already is in obscore,<br>
no?<br>
<br>
</blockquote>
also this is right.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
c - the search output (which includes something along the lines of a<br>
PublisherDID) is then used to explicitly cut the needed cube(s) to make<br>
data transfer affordable (in the near future merging of adjacent<br>
"same-survey" cubes will be also implemented)<br>
</blockquote>
And here I'd argue that's a Datalink thing. There's just too many<br>
sorts of processing one could do on data products to have any<br>
hopes of describing them in a single database table, and datalink<br>
lets you do exactly what you're asking for with minimal overhead on<br>
both the table and the client (it will typically have to request one<br>
small file per cutout, of course, but given the transfer volumes<br>
we're talking about here on the data side that's neglible).<br>
<br>
</blockquote>
one small file for each cutout call is what current custom service does.<br>
I'm not saying I will not use Datalink, but I'd like to see whether that's<br>
the only solution.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Conversely, just having the pixel sizes of the cube (as in the +6<br>
columns proposal) won't really help you for your use case either, and<br>
even if that information could, you'd still have to have some<br>
descriptor of the access service somewhere, and so you'd have to use<br>
datalink either way.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The need for WCS information in the output of the search comes from the<br>
idea of allowing the client side to build correct cutout queries to the<br>
</blockquote>
Well, let me do a general plea here: "Keep data discovery and data<br>
access separate as much as you can." Datalink is the model to<br>
efficiently perform that separation.<br>
<br>
</blockquote>
again, current custom service does so, but uses the same parameters to do<br>
both,<br>
it's just for logical reasons that the endpoints of the services will be<br>
detached, otherwise<br>
simple parameter discrimination between the two would do (in my case).<br>
You're probably right my use case is already covered from DAL point of<br>
view, maybe the only<br>
thing not spoken about a lot is the velocity axis of the cubes.<br>
<br>
[cutting...] I think I follow you, but I'm not completely convinced...could<br>
be my use case is not so complex<br>
in these terms.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I give you, though, that there are open issues from a practical<br>
perspective. Mine are:<br>
<br>
(1) certain types of queries (e.g., "give me all datasets that have a<br>
certain axis type in any position") aren't really too well suited<br>
for going through indices.<br>
<br>
(2) there might be major *discovery* use cases that require additional<br>
information on the axes<br>
<br>
On (1), I've already written something in<br>
<a href="http://mail.ivoa.net/pipermail/dm/2015-April/005150.html" target="_blank">http://mail.ivoa.net/pipermail/dm/2015-April/005150.html</a>, which I<br>
think hasn't been disputed yet.<br>
<br>
</blockquote>
In my case it would be finding datasets having velocity axis<br>
somewhere (usually it's the 3rd axis, but<br>
in general it shouldn't change if it's in another position).<br>
But I yet have to understand what to put to identify the velocity axis.<br>
<br>
On (2), I can well imagine they exist, but I'd still hope we can avoid<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
expanding obscore by 20% to satisfy those. Let's identify them if<br>
they're there, shall we?<br>
<br>
Let me mount the soapbox once more (I'm done in a few lines): Think<br>
of our adopters. Based on what I hear from DaCHS' users and even a<br>
sizable crowd on this list, I'm convinced that additional fields in<br>
DMs are being paid for in terms of takeup (not to mention that people<br>
tend to put junk in fields whose purpose they don't understand).<br>
<br>
For the sake of takeup, please don't add fields without a strong,<br>
validated use case that cannot be sanely satisfied in any other way.<br>
<br>
</blockquote>
I find it difficult to reply this soapbox buildup, because I found myself<br>
many<br>
times in the dilemma of using or not (also some SHOULD) fields due to lack<br>
of description of what was required.<br>
<br>
I understand (already said so in my previous mail) your concern on widening<br>
the number of table fields. I agree we should have use cases, to be sure we<br>
don't leave someone out and find ourselves in troubles with new revisions<br>
when<br>
they require a major one for back-compatibility issues<br>
(oh, god, breaking back-compatibility!).<br>
<br>
I also think we need clear guidelines if we want takeup to increase when<br>
resources are limited or otherwise spent.<br>
<br>
ciao<br>
Marco<br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Mireille Louys , Maître de conférences<br>
Centre de Données ( CDS) Icube & Télécom Physique Strasbourg, Pôle API<br>
Observatoire de Strasbourg 300, boulevard Sébastien Brant<br>
11, Rue de l'Université CS 10413<br>
67000 Strasbourg F - 67412 ILLKIRCH Cedex<br>
<a href="http://astro.unistra.fr" target="_blank">http://astro.unistra.fr</a> <a href="http://www.telecom-physique.fr" target="_blank">http://www.telecom-physique.fr</a><br>
tel : 03 68 85 24 34<br>
</font></span></blockquote></div><br></div>