[VEP-0001] DataLink semantics vocabulary enhacement proposal

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Mon Oct 21 11:40:42 CEST 2019


Dear IVOA,

On Fri, Oct 18, 2019 at 01:43:54PM +0200, ada nebot wrote:
> Thanks for putting this together. 
> 
> I think "associated-lightcurve" should be
> "associated-timeseries-lightcurve” to be in line with the other
> terms added for timeseries. 

>From a semantics standpoint, I would very much like to only introduce
terms that are actually used.  The process is designed as very light
and fast in order to alleviate the urge to introduce terms just
because someone might need them in the future -- vocabulary work is
hard even without attempting to look into the future.

So, a question to all (including Carlos, who's posted on voevent@):
Which of these terms do you actually need *now* (or at least for data
that you will want to publish in the safely forseeable future)?  And
can you see a clear scenario for a *machine* to have to understand
matters at that level of detail (for human, there's always the
description in datalink)?

The central use case here, as far as I can tell, is to make a client
"do the right thing when a user clicks on a data point".  For
instance, Aladin would send a timeseries to SPLAT when displaying
Gaia DR2 and it figures out there is one for an object the user
selects.  

SPLAT, in turn, for each photometry point in a time series, could see
that there is an associated image (not yet for Gaia DR2, but it's
there for BGDS, ivo://org.gavo.dc/bgds/l/tsform, for instance) and
then have that displayed as users select individual points on the
time series so people can immediately check if something is odd with
the source of an outlier (say).

This would lead me to the following terms:

associated-data: The data at access_url contains information on the
  discovered item not directly related to the original observation
  [which would probably be a progenitor or derivation] but giving
  additional insights in the source or phenomenon observed.

That's the root term; I'd rather not talk about "dataset" here, as
that, at least in some parts of the VO, is a strong term.  For
instance, associated images will almost always be cutouts of 
datasets, and we may not carelessly want to promote these to
datasets themselves.

associated-timeseries: The data at access_url is a mapping from 
  time to one or more scalar observables (examples: a lightcurve or a
  time series of radial velocities) giving additional insight into the
  discovered item.

associated-image: The data at access_url is an image giving
  additional insight into the discovered item.

Now that I write this, I frankly think that associated-image as given
in the use case above should actually be progenitor: that's clearly
what a postage stamp that shows the image that the photometry point
was derived from.

So -- does anyone have another use case (as I said: try describing
what a client would do with the term) for associated-image?  Or for
any other term other than associated-data and associated-timeseries?
And let me stress again because I think that point is often neglected
in the VO: "use case" should really include proposed client
behaviour.

I'd be great if we didn't introduce terms nobody may be using for
many years.  Bonus: We don't need to quarrel about what's the
difference between associated-cube and associated-timeseries-image
when it's not really clear what any client might be doing with
either.


Be that as it may: The proposed terms will appear as premliminary at
http://ivoa.net/rdf/datalink/core/ real soon now.


I'd also say we shouldn't crosspost all discussion to three lists.
In the next Vocinvo2 WD, I'll propose that VEPs must designate a
single mailing list on which the discussion is (preferably) to take
place after the announcement (which can be widely crossposted).  In
the present case, can we restrict the discussion to the DAL list?
People not there yet but still interested in real-time discussions on
this could temporarily subscribe to it, could they?

Thanks,

            Markus


More information about the voevent mailing list