<div dir="ltr">Hi Mireille, Hi all,<div><br></div><div>if I get it right, that table comes out of obscore's use case A.3.2.</div><div>It seems to me that my case takes something also from the A.3.4 (because my users want to see RESTFRQ reported, even if it's not in the FITS header explicitly) and also the cubes we're dealing with span both the 3 axis and 4 axis cases (even if the 4th currently is just degenerate and not considered in the usage of data).</div><div><br></div><div>Anyway, that said, I think that d_</div><div>ucd</div><div>unit</div><div>definition</div><div>min</div><div>max</div><div>would suffice. I think reference_position will be GEOCENTRIC in my case, but I have to investigate.</div><div><br></div><div>In some sense the above listed are enough to describe the data for the needs of the community I'm serving, I'm wondering if it's ok also for a generic VO user searching for datasets that include the ones I (will) have in place.</div><div><br></div><div>As for the units specification Arnold pointed out: my user need it not in search phase (the unit there is fixed by the service interface, which I think will always be the case in VO) but it wants it in the response to ease the work of the client app. So probably my use case does not put requirements on this issue.</div><div><br></div><div>Cheers,</div><div> Marco</div><div><br></div><div>ps - to be honest all my use case works in GLON,GLAT instead of RA,DEC, but that's trivial.</div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-23 17:25 GMT+02:00 Louys Mireille <span dir="ltr"><<a href="mailto:mireille.louys@unistra.fr" target="_blank">mireille.louys@unistra.fr</a>></span>:<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></div></div>