FW: UCD requests from CASDA Project

Wed Jun 22 05:53:29 CEST 2016

Hi Frederick

Thanks for your message and comments. 

We do agree and understand that the UCDs can’t cover everything. It's clearly a very difficult challenge to get the vocabulary 'right' and to find the balance between being overly lean and overly fat. The list we've sent is the specific list used for CASDA so far - we can certainly change some of the terms if there are better options and/or keep some terms in the ASKAP name space. 

As a general comment though, at present the vocabulary is lacking some terms that are widely used in radio astronomy and with ASKAP, MeerKAT and SKA coming up it would be good to do some updates for this. We note here that large-scale polarisation studies are key science goals for these facilities. 

In response to your comments, we have been through the list again and have added two extra columns (D) and (E) to show the items that you have marked as 'obviously  needed'. We have also identified  the more specialised items that we could keep in our own name space and the ones we would still like the IVOA to consider further - as describing terms that are widely used. The revised list (those with a yes in col D) now suggests a total of 15 new terms. 

We would welcome any further discussion. Hopefully this version gives a better separation of flowers from weeds.

Thanks again,

Cheers

Jessica

-----Original Message-----
From: Frederic V. Hessman [mailto:hessman at astro.physik.uni-goettingen.de] 
Sent: Tuesday, 21 June 2016 8:25 PM
To: Chapman, Jessica (CASS, Marsfield) <Jessica.Chapman at csiro.au>
Cc: mireille.louys at unistra.fr; semantics at ivoa.net; Dempsey, James (IM&T, Yarralumla) <James.Dempsey at csiro.au>; Whiting, Matthew (CASS, Marsfield) <Matthew.Whiting at csiro.au>
Subject: Re: UCD requests from CASDA Project

Dear Jessica et al.:

Currently, the UCD’s are a mixed bag, semantically, where one notices that they have grown organicallly out of need rather than from a planned semantic scheme.  Straight-forward terms like

	arith.integrated
	meta.deconvolved
	meta.corrected
	stat.centroid
	stat.fwhm
	stat.rms
	phys.polarization.stokes.I							
	phys.polarization.stokes.Q										
	phys.polarization.stokes.U										
	phys.polarization.stokes.V

are obviously needed.  

Highly specialized terms like

	spect.curvature										
	em.wl.squared		Wavelength squared' is used in polarisation studies as it relates to Faraday rotation.

are best kept within a specialized vocabulary - UCD can’t possibly cover everything

Similarly, the highly specialized composite term

	instr.rmsf			Rotation measure and the rotation measure spread function are used in radio astronomy polarisation studies					
is really “rotation-measure” + “spread-function”, i.e. a better generic description would be

	phys.polarisation.rotMeasure;stat.pdf

(I’ve added the new UCD “stat.pdf” for a “probability distribution function”, for which I couldn’t find a reasonable composite replacement)

Other composite terms like

	spect.line.width20	Spectral line width at 20 per cent of peak

(concept plus a numerical value) are trickier - why not then spect.line.width10? spect.line.width.5? spect.line.width.12.345?   Perhaps we can assume that 1, 5, 10, and … limits on a PDF are common enough that we need standard terms.  Or how does one attach metadata to this metadata without using totally new metadata links?  Something like

	spect.line.width;value=20

rather than a more complex solution like

	<param ucd=“spect.line.width name=“linewidth">1.2345</param>
	<param ucd=“stat.pdf.margin” ref=“linewidth">20</param>

(whoops - another new term, “stat.pdf.margin”).

Similar problem in

	src.asymmetry.2d	measure of 2-d asymmetry										
	src.asymmetry.3d	measure of 3-d asymmetry

i.e. what about src.asymmetry.4d?   Composite equivalent would be more like

	src.morph;stat.asymmetry

(whoops - another new term, “stat.asymmetry”).

The term

	em.freq.width				measure of width in frequency

follows generic UCD use, but we see how there’s *.width creep taking place here: where do we stop?  How about “phot.color.excess.width”?

## Radio astronomy almost always provides width/bandwidth measures in frequency or velocity - not wavelength terms. The terms 'color index' and 'color excess' are just not used in radio astronomy and I think would be quite confusing in this context.  So we do request the .width

I’m not even sure what

	spect.dopplerVeloc.width	Measure of spectral width in velocity

is supposed to mean: the velocity width of a spectra feature caused solely by Doppler shifts (as opposed to other broadening mechanisms)?  Why not then 

	spect.line.broad;phys.doppler

(again had to invent “phys.doppler”)?

The problem with “pixel” and “voxel” is that pixel is a subset of voxels, interpreting the latter as a generalized n-dimensional “pixel” (even though it is most often used as a 3-D volumic “pixel”).  Thus, everywhere where one uses “pixel” one could just as easily use “voxel” - unless we need a new generic term …. “genxel”?   ;-D  In the interest of generality, we do then need

	instr.voxel

and really should be removing “pixel”.

With

	phot.flux.density.voxel		flux density of a voxel

do we then need "phot.flux.density.pixel”? or shouldn’t one use

	phot.flux.density;instr.voxel

or isn’t there hidden complexity here: flux-density PER voxel or somehow associated with voxels (e.g. measuring using voxels)?  How about

	phot.flux.density;instr.voxel;artih.ratio

to indicate “flux-density per voxel”?

The problem of extending UCD is that we can either

	- keep it lean (well, the present fat is there to stay….), forcing groups like CASDA to define their own (a good thing which forces everyone to acknowledge that the astronomical semantic world is complex so we have to deal with it rather than ignoring it or waiting for the IVOA to solve everyone’s problems); or

	- let it expand to cover everyone’s needs, a lazy and chaotic way of solving the problem; or

	- let it grow infinitesimally, knowing that our garden will always contain some weeds; or

	- plant but ALSO prune propitiously so that we only have generic flowers, letting others worry about the weeds.

Rick

> On 21 Jun 2016, at 01:42, <Jessica.Chapman at csiro.au> <Jessica.Chapman at csiro.au> wrote:
> 
> Dear Mireille and IVOA semantics group
> 
> This is to send you a request now to consider some additional UCD terms. I'm attaching an excel file with a list of the terms we have needed for CASDA (so far) that are not in the standard vocabulary. 
> 
> If you have questions or need any additional information do contact us. 
> 
> Thanks and best wishes
> 
> Jessica
> 
> 
> Dr Jessica Chapman
> CSIRO Astronomy and Space Science
> Data Management Leader
> PO Box 76, Epping, NSW 1710
> 
> T: 02 9372 4196
> E: Jessica.Chapman at csiro.au
> W: www.atnf.csiro.au
> 
> 
> 
> -----Original Message-----
> From: Mireille Louys [mailto:mireille.louys at unistra.fr] 
> Sent: Tuesday, 10 May 2016 10:21 PM
> To: Chapman, Jessica (CASS, Marsfield) <Jessica.Chapman at csiro.au>
> Subject: follow-up of Cape town semantics sesison
> 
> Dear Jessica ,
> 
> We'll set up a service for users to request new UCD terms after this meeting.
> In the mean time , would you mind to send the request for new terms as proposed in your ASKAP name space to the semantics at ivoa.net list ?
> 
> I suggest to provide a short request entry with the new term , a short definition for this new term , and a short description for the context.
> This would help to launch the process.
> 
> Thank you for pointing this need and opening for a better uptake for radio data.
> 
> Best regards , Mireille Louys
> 
> <ASKAP_UCDs.xlsx>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ASKAP_UCDs_version2.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 12242 bytes
Desc: ASKAP_UCDs_version2.xlsx
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20160622/7c870ca9/attachment-0001.xlsx>