concept representation/displaying language?

[Mark Taylor]

On Wed, 3 Jun 2009, Carlos Rodrigo Blanco wrote:

> 
> As we are talking about vocabularies I've remembered a question that I posted
> to the semantics group and I didn't get much help about...
> 
> In some cases, we have to include in VOTables quantities (params, fields...)
> that are not predefined in a protocol or data model or whatever (the point is:
> no application will have a precoded way to
> handle it)
> 
> I would like to be able to tell the client (application) how that quantity
> should be displayed (formated). To give a simple example, I would like to be
> able to tell the application that this parameter that I call teff should be
> writen as T_{eff} (latex notation). In this teff case it is not very
> important, but in other cases it is... it's quite ugly to write
> alpha_gamma_square when you can write \frac{\alpha}{\gamma}^2 (again latex
> notation). And I think that applications should be as friendly to users as
> posible.
> 
> I can point to vocabularies telling the definition of quantities and relation
> between quantities, I know, but it doesn't help.
> 
> Does any one have any idea about such a thing? (You always can include a table
> with fields saying how other fields must be represented using <!CDATA... and
> so but, being it a solution, it seems to be just a patch as the application, a
> priori, wouldn't know that it has to look for the information there)

Carlos,

there's a proposal to add a new attribute to VOTable FIELD and PARAM
elements in VOTable 1.2; called something like xtype or extendeddatatype.
Thus something like:

   <PARAM datatype="char" arraysize="*" value="T_{\rm eff}"
          extendeddatatype="latex"/>

could work.  Of course the receiving application will need to understand
the value "latex" of the extendeddatatype attribute.
It may be required to add a namespacing prefix to the attribute
value, and define its semantics somewhere else.

I think this would be a reasonable solution to what you want,
though note it's only going to work for FIELD or PARAM values,
not, e.g. column names (FIELD or PARAM names).
However the proposal is still to be drafted and accepted, so
this won't work now, and depending on the form in which it
makes it into the standard, may or may not in the future.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/