<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Markus,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
We are dealing with a lot of catalogues as well as images, cubes etc. Currently these have a blank dataproduct_type in the CASDA obscore instance as there wasn't anything we could use in v1.0. <span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background: var(--white);">We
will probably start using measurements soon as it is better than nothing, but it isn't a term that our community uses. Their expectation is to see catalogue in the type, so I'd be keen to see that as term available for use.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Our catalogues are generally source lists produced from the associated image/cube.</div>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers,</div>
<div id="Signature">
<div></div>
<div></div>
<div></div>
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div class="BodyFragment"><font size="2">
<div class="PlainText">
<div class="PlainText">James Dempsey</div>
<div class="PlainText"><span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:small; text-align:start; background-color:rgb(255,255,255); display:inline!important">Senior Developer</span></div>
<div class="PlainText"><span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:small; text-align:start; background-color:rgb(255,255,255); display:inline!important">Information Services Applications</span></div>
<div class="PlainText">CSIRO Information Management & Technology (IM&T)</div>
</div>
</font></div>
</div>
</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> dal-bounces@ivoa.net <dal-bounces@ivoa.net> on behalf of Markus Demleitner <msdemlei@ari.uni-heidelberg.de><br>
<b>Sent:</b> Wednesday, 11 March 2020 7:48 PM<br>
<b>To:</b> dal@ivoa.net <dal@ivoa.net>; registry@ivoa.net <registry@ivoa.net>; semantics@ivoa.net <semantics@ivoa.net><br>
<b>Subject:</b> Re: Vocabularising dataproduct_type</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi Sarah,<br>
<br>
On Tue, Mar 10, 2020 at 03:58:09PM +0000, Sarah Weissman wrote:<br>
> * Would too many things be mapped into "Measurement" to be useful<br>
> from a discovery perspective?<br>
<br>
Given my findings yesterday (no active obscore service right now has<br>
measurements rows), I think we shouldn't sweat this measurements<br>
thing too much at this point -- in Registry, this term would only be<br>
used for (SSAP, for now) services *returning* lists of such<br>
measurements (as they would otherwise return spectra), which seems a<br>
long shot.<br>
<br>
Normal discovery of catalogues and similar will of course proceed as<br>
usual.<br>
<br>
However, I largely agree with Laurent:<br>
<br>
On Tue, 10 Mar 2020 17:42:43 +0100, Laurent Michel wrote:<br>
> I would really prefer the list of dataproduct_type to ensur an ascending<br>
> compatibility with Obscore. I believe it is worth to keep as fas as possible a<br>
> consistance betwenn standards. This might help in many cases to map things<br>
<br>
So, even though I think we've found that the actual definition of<br>
measurement is, well, hard, I'm now rather convinced we shouldn't<br>
drop it. On the other hand, when we follow Marco --<br>
<br>
On Tue, 10 Mar 2020 13:53:09 +0100, Molinaro, Marco wrote:<br>
> Il giorno mar 10 mar 2020 alle ore 13:14 Markus Demleitner <<br>
>> A set of derived measurements obtained from a particular original<br>
>> dataset. The prototypical example would be a list of sources<br>
>> extracted from an image.<br>
><br>
> Does it have to be "original dataset" _singular_?<br>
<br>
and Laurent's previous proposal, we'd end up with:<br>
<br>
A set of derived measurements obtained from original datasets or a<br>
catalog of sources.<br>
<br>
I'd say the "obtained from original datasets" in there doesn't really<br>
mean much (what else could the measurements be derived from?), so<br>
reduced it would work out to<br>
<br>
A set of derived measurements or a catalog of sources.<br>
<br>
Which, as Sarah rightly says, is really vague and all-encompassing.<br>
As I said, I'd normally throw out such a term on grounds of it<br>
colliding with too many other terms without really fitting well into<br>
a hierarchy.<br>
<br>
But again, since it's in obscore, we shouldn't drop it. But since<br>
it, to me, seems ill-defined, perhaps we should be frank and just say:<br>
<br>
Generic tabular data not fitting any of the other terms. Because<br>
of its lack of specificity, this term should generally be avoided,<br>
and new, more precise terms should be introduced instead.<br>
<br>
Can people live with that? If we find good use cases for<br>
"measurements" later, we still can get more precise in this<br>
definition as long as we now say "don't use it, really".<br>
<br>
Back to Sarah:<br>
<br>
On Tue, Mar 10, 2020 at 03:58:09PM +0000, Sarah Weissman wrote:<br>
> * Do we need a separate category for "Model"?<br>
<br>
The future Vocabularies 2 standard is designed to make it easy to add<br>
new terms exactly when they're actually needed. So, when you you<br>
have an SSA or Obscore service returning such Models instances -- or<br>
some future use of this vocabulary needs it --, we can include it.<br>
For now, let's see if we can just stick with what Obscore already<br>
has.<br>
<br>
> * Do you expect that more than one label would be applied to a data<br>
> product? For example (naively) could a "spectral image cube" be<br>
> labeled with "spectrum" and "image" and "cube"?<br>
<br>
This depends on where the terms are being used. In obscore, only one<br>
label per row is possible, and I don't think that can be changed in a<br>
backwards-compatible way; we could, however, in some future version<br>
of obscore, introduce a multi-valued "other_dataproduct_types" in the<br>
style of EPN-TAP -- but that's a different discussion.<br>
<br>
In what I'm drafting for SimpleDALRegExt, SSA services can be<br>
annotated with zero or more dataproductType elements (current<br>
internal draft: <a href="http://docs.g-vo.org/SimpleDALRegExt.pdf">http://docs.g-vo.org/SimpleDALRegExt.pdf</a> or on<br>
volute). More on this later on the Registry list.<br>
<br>
Thanks,<br>
<br>
Markus<br>
</div>
</span></font></div>
</body>
</html>