Product-type as a SKOS vocabulary

[BONNAREL FRANCOIS]

Dear all,
I didn't comment this and I think I have to do that both from the 
RadioIG and DataLink point of view.

I think it's a good idea to have several different terms hierarchically 
related to a single one and to use SKOS concepts features for that.

But I would like to see if some new terms could enter this scheme and in 
which way.

In a long (and unsolved) discussion some times ago common to 
TDIG/DataLink the question was raised to introduce light curve (and also 
velocity curve) in the vocabulary. These are special types of 
TimeSeries. In ObsCore this could be solved by adding these terms in 
dataproduct_subtype.

Spectropolarimetry : polarimetric spectra ? This is narrower than 
spectra but should have another broader term. Currently in obscOre this 
is also probably managed by a dataproduct_subtype


In the radio domain we don't have only images and spectral cubes we also 
have moment maps, velocity maps, polarization cubes

We also had an email by Stephane about the EPN-TAP types.

In the context of DataLink we cannot use dataproduct_subtype in a 
standard way. there is no field for that and will probaly not be in the 
future. *So the SKOS concept semanticsRelation network is a good idea to 
organize the terms*

If we want to organize dataproducts in a network we have to think what 
are the properties  able to characterize the dataproducts and see what 
are the most common cases

    I see at least 4 type of properties
       1 )  What are the independent variables (in the context of  
functional dependencies of variables with respect to others)? for 
example if time is independent we have a TimeSeries , if spectral 
coordinate is independent we have a spectrum
       2 )  What are the dependent variables. In case of TimeSeries If 
it's a photometric quantity, it could be a lightcurve, if it's radial 
velocity it is a velocity curve.
       3 ) Are the independent variable sparsed or regularly sampled ?
       4 ) The organization : is this a table (where the different 
quantities of a given measurement are explicitly recorded) or a bitmap 
where the range of a dependent measurement  in the dependent measurement 
array is a function of the independent variables

      Let's try to sort our dataproducts in a table according to these 
properties

TimeSeries :


	space
	time
	spectral
	polarization
	velocity
	some moment
	polarization
angle
	photometric
  variable
	uv
coords
	visibilty
dependent
	?
	no
	?
	?
	?
	?
	?
	?
	no
	no
independent / regular
	?
	yes or
yes
	?
	?
	?
	?
	?
	no
	no
	no
independant /sparse
	?
	?
	?
	?
	?
	?
	no
	no
	no
organization
	table


Spectrum

	space
	time
	spectral
	polarization
	velocity
	some moment
	polarization
angle
	photometric
variable
	uv
coords
	visibilty
dependent
	?
	?
	no
	?
	?
	?
	?
	yes
	no
	no
independent / regular
	?
	?
	yes or
yes
	?
	?
	?
	?
	no
	no
	no
independant /sparse
	?
	?
	?
	?
	?
	?
	no
	no
	no
organization
	table or bitmap


Dynamic Spectrum

	space
	time
	spectral
	polarization
	velocity
	some moment
	polarization
angle
	photometric
variable
	uv
coords
	visibilty
dependent
	?
	no
	no
	?
	?
	?
	?
	yes
	no
	no
independent / regular
	?
	yes
	yes
	?
	?
	?
	?
	no
	no
	no
independant /sparse
	?
	no
	no
	?
	?
	?
	?
	no
	no
	no
organization
	bitmap



Light curve :

	space
	time
	spectral
	polarization
	velocity
	some moment
	polarization
angle
	photometric
variable
	uv
coords
	visibilty
dependent
	no
	no
	no
	no
	no
	no
	no
	yes
	no
	no
independent / regular
	no
	yes or
yes
	no
	no
	no
	no
	no
	no
	no
	no
independant /sparse
	no
	no
	no
	no
	no
	no
	no
	no
	no
organization
	table


Velocity curve :

	space
	time
	spectral
	polarization
	velocity
	some moment
	polarization
angle
	photometric
variable
	uv
coords
	visibilty
dependent
	no
	no
	no
	no
	yes
	no
	no
	no
	no
	no
independent / regular
	no
	yes or
yes
	no
	no
	no
	no
	no
	no
	no
	no
independant /sparse
	no
	no
	no
	no
	no
	no
	no
	no
	no
organization
	table


event (event list) : all the measurements fort an event are supposed to 
be independant and sparse.

	space
	time
	spectral
	polarization
	velocity
	some moment
	polarization
angle
	photometric
variable
	uv
coords
	visibilty
dependent
	no
	no
	no
	no
	no
	no
	no
	no
	no
	no
independent / regular
	no
	no
	no
	no
	no
	no
	no
	no
	no
	no
independant /sparse
	?
	?
	?
	?
	?
	?
	?
	?
	?
	?
organization
	table


visibility

	space
	time
	spectral
	polarization
	velocity
	some moment
	polarization
angle
	photometric
variable
	uv
coords
	visibilty
dependent
	no
	no
	no
	no
	no
	no
	no
	no
	no
	yes
independent / regular
	no
	yes
	yes
	yes
	no
	no
	no
	no
	no
	no
independant /sparse
	no
	no
	no
	no
	no
	no
	no
	no
	yes
	no
organization
	table of bitmaps




Do these tables help to organize the terms in the SKOS concept network ? 
Yes every term which is consistent but better defined than another term 
is narrower than it ! For example Dynamic Spectrum is better defined and 
consistent with TimeSeries and spectrum.
Light curve and Velocity curve would have "TimeSeries" as broader term.

Then we can create new SKOS semantics Relations by defining new terms 
for each of these property combination if needed.
For example we could call "whateverQuantity"Mapping any dataproduct 
where the dependent whateverQuantity is a Mapping (ie function) of the 
independent variables.

For example FluxMapping would be :



	space
	time
	spectral
	polarization
	velocity
	some moment
	polarization
angle
	photometric
variable
	uv
coords
	visibilty
dependent
	?
	?
	?
	no
	?
	?
	?
	yes
	no
	no
independent / regular
	?
	?
	?
	?
	?
	?
	?
	no
	no
	no
independant /sparse
	?
	?
	?
	?
	?
	?
	?
	?
	?
	?
organization 	table or bitmap


and VelocityMapping almost the same by inverting velocity and 
photometric variable dependent values in the above tables.

In this case broader terms for LightCurves would be : TimeSeries and 
FluxMap. And for VelocityCurve, TimeSeries and VelocityMap

I'm still wondering about "image" . Should we restrict that to 
FluxMappings ? or are a velocityMap, a momentMap,  a polarization angle 
map also images ?
In the latter  case "image" would be a broad term which will require 
narrower terms at least for radioastronomy.

Conclusion :*I support Markus' current proposal *but I would like to 
know if people agree with the way I propose to build new terms which 
will be obviously needed in the fields I mentioned at the beginning of 
this email and insert them in the SKOS network.

Cheers
François

Le 18/11/2021 à 14:51, Markus Demleitner a écrit :
> Dear Semantics WG,
>
> for Datalink 1.1 (which will be going to RFC fairly soon, I think),
> we ought to have the vocabulary of data product types (spectra, time
> series, images ...) ready.  At the last interop, I had suggested that
> after a by and large failed attempt in spring we ought to have a SKOS
> vocabulary for that; cf.
> https://wiki.ivoa.net/internal/IVOA/InterOpNov2021Sem/product-type.pdf.
>
> I have now prepared this vocabulary based on what obscore lists, plus
> the dynamical spectrum that Baptiste has asked for.  Please have a look:
>
> https://www.ivoa.net/rdf/product-type/
>
> Dynamical-spectrum shows where this is going: If you search for any
> of timeseries or spectrum and have term expansion on, you will get
> dynamical spectra, too (Baptiste: do you perhaps have some of these
> in an obscore table served through a DaCHS that already has the
> gavo_vocmatch UDF?  That would be a nice demo).
>
> If you have product types *in obscore services* (or perhaps those
> new-fangled Datalink content qualifiers) that ought to go in here
> before we go to DAL and the TCG, let me know; at this point we're
> still in the vocabulary construction phase, which means it's easy in
> (and easy out as well, if someone disagrees with a term, whereas a
> non-preliminary term in an accepted vocabulary cannot vanish[1]).
>
> Opinions?  (To give you an idea of the time frame I'm aiming for: My
> current plan is to push this to DAL and the TCG by mid-December so we
> won't hold up the Datalink RFC when it comes).
>
>           -- Markus
>
> [1] Well, in this particular case, I think we can't pull any of the
> obscore terms. However, I can't lie: If I dared, I'd have thrown out
> measurements on grounds of insufficient definition.  As always, it's
> as important to say what a concept covers as it is to say what it
> does not cover.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20220105/3cbcdc41/attachment-0001.html>