concept representation/displaying language?

[Carlos Rodrigo Blanco]

I find that solution very nice!

What do you think of something similar to what I use for the 
astrosismology example?  It has the advantage of not making the original 
votable bigger and not changing the votable specification.

But the posibility that you suggest fits perfectly my needs.

Carlos

On Fri, 5 Jun 2009, Francois Ochsenbein wrote:

>
> Hi Carlos,
>
> Your message is not messy at all -- I think I understand more or
> less your wish -- and effectively the solution (C) looks as most
> appropriate.
>
> Just a suggestion in your example: instead of
>     <PARAM name="concepts" value="http:/:...">
> the <LINK> seems to be more appropriate, like
>     <LINK content-role="doc" href="http://...">
>     (the 'doc' value of the content-role would better
>     be replaced by 'concepts' or 'context', it would
>     require a slight modification of the schema)
>
> There is however a difficulty if the suggestion is to have
> <LABEL> as a child of <DESCRIPTION>, since an element may
> *either* contain text *or* sub-elements -- a mixing of
> text and elements (like an HTML text) cannot work easily.
>
> But an alternative, which I find more attractive, would be
> to allow several descriptions and several labels, something
> like:
>
> <DESCRIPTION context='latex'> Derived from $\nabla.\vec{E}=0$ </DESCRIPTION>
> <DESCRIPTION> Derived from Maxwell equation <DESCRIPTION>
> <LABEL context='latex'>$E_\perp$</LABEL>
> <LABEL context='html'><![CDATA[E<sub>&#x22a5;</sub>]]></LABEL>
>
> [notice the CDATA is required due to the mixing of text and elements]
>
> I'm not sure everybody would agree, but it should not be impossible...
>
> --Francois
>
>>
>> Hi Francois
>>
>> I think that your suggestions are really creative and all of them are
>> quite useful (also the idea by Mark is)
>>
>> (at the end of this long and messy mail I give an example of the way I'm
>> doing it now so please, if you are interested try to reach the end of the
>> mail ;)
>>
>> I find some difficulties associated to each of them, though.
>>
>>> A) either the name (name="\frac{\alpha}{\gamma}^2" is quite
>>>   possible);
>>
>>> B) or embed in the <DESCRIPTION>, (e.g.
>>>   <DESCRIPTION>[latex_label=$\frac{\alpha}{\gamma}^2$]
>>>      Commputed value of...
>>>   </DESCRIPTION>
>>
>> Having such an expression as a PARAM name sounds weird (I guess that some
>> applications can be using the param names to store values or things like
>> that). Having it in the description is, like you say, a convention. It
>> means that people shold be aware of it and not showing the latex_label
>> together with the description.
>>
>>> C) or VOTable has to define another element or attribute to
>>>   convey this info; if such details would have to be added,
>>>   I would prefer to define of a new element like <TITLE>
>>>   or <LABEL> or <CAPTION> which could exist in addition to
>>>   (or as a complement to) <DESCRIPTION>, something which
>>>   could look like
>>>      <LABEL context="latex">\frac{\alpha}{\gamma}^2</LABEL>
>>
>> This third option (offering a better structured way to do it) would imply
>> adding something new to the VOTable specification (which people will be
>> reluctact to, although I think that, with time, some other additions will
>> be done)
>>
>> The problem about all of this is that, the same way that I would like to
>> have this option for the param or field name I would also like to have it
>> for the description (sometimes it is even more important because it is in
>> the description where it is most likely to have, for instance,
>> mathematical formulae).
>>
>> In that case:
>>
>> solution (A) doesn't work.
>>
>> Solution (B) would imply adding a convention to include a funny structure
>> inside the <description> element so that you can give the formatting both
>> for the param label and its description (It would fit my intentions and
>> even other posibilities, but I don't know if it is a solution, it looks
>> more like a patch; at least unless we ended up a new "description element
>> content language" or something like that).
>>
>> Option (C) would be perfect if the <LABEL> element could be a child both
>> of a <PARAM> and <DESCRIPTION> or being able to have different labels for
>> the same param... It seems a big change in votable (although useful).
>>
>> (and, in any case, this means adding information to the votable, making it
>> heavier to download and maybe not useful at all for some users/clients
>> that will download more information without needing it)
>>
>> I think that the nicest way for something like this would be
>> to do something similar to what is done for ontologies, vocabularies,
>> namespaces and so. I'm not an expert on those things, so please correct me
>> where I'm wrong.
>>
>> I would have some xfd (Xml Formatting Definition or whatever, I've just
>> invented the term) document following a TBD specification. In that
>> document I would have:
>>
>> <concept name=teff>
>>   <label context=latex>T\_{eff}</label>
>>   <desc context=latex>....</desc>
>>   <label context=html>T<sub>eff</sub></label>
>> ...
>> </concept>
>>
>> or something similar (I just want to suggest the main idea)
>>
>> And, in the votable tag I would add the address of this document in the
>> usual fashion, somethinkg like <votable xfd:http:...> (or even a INFO
>> element could be given in the votable telling the address of this
>> document?)
>>
>> In that way, somebody can download the simple votable and, if he is
>> interested in displaying, he can download the xfd document and do the
>> matching. I don't know if the matching should be done by the parameter
>> name or by some utype or whatever (how is it done in SKOS vocabularies and
>> those things? I actually think that this thing that I'm asking for could
>> be an addition to vocabularies: not only giving "definitions" and
>> relations, but only suggesting the correct displaying in several contexts)
>>
>> I can show the "solution" that I'm using right now for one case that I'm
>> interested in (I dont find it to be the more elegant posibility, is just
>> an easy way to do it).
>>
>> Take this VOTable:
>> http://svo.laeff.inta.es/theory/astrosism/s3p.php
>> (it contains the metadata for some astrosismology model)
>>
>> it includes this:
>> <PARAM name="concepts"
>> value="http://svo.laeff.inta.es/theory/astrosism/concepts.php"/>
>>
>> Given that my applications are the only ones accesing the service (by now)
>> I know that this parameter means that in that document (the one pointed
>> by the url) I can find information on how to display each concept).
>>
>> You can download that document (another votable) and use the information
>> in it.
>>
>> I just would like to do such a thing in a more elegant way (or a more
>> standard way) if possible.
>>
>> Sorry for the long and messy mail (I hope it is readable)
>>
>> Carlos
>>
>> > I don't think the 'xtype' (or 'xdatatype', to be finalized)
>>> is meant for this kind of info -- I would rather suggest
>>> the following possibilities:
>>>
>>> A) either the name (name="\frac{\alpha}{\gamma}^2" is quite
>>>   possible);
>>>
>>> B) or embed in the <DESCRIPTION>, (e.g.
>>>   <DESCRIPTION>[latex_label=$\frac{\alpha}{\gamma}^2$]
>>>      Commputed value of...
>>>   </DESCRIPTION>
>>>
>>> C) or VOTable has to define another element or attribute to
>>>   convey this info; if such details would have to be added,
>>>   I would prefer to define of a new element like <TITLE>
>>>   or <LABEL> or <CAPTION> which could exist in addition to
>>>   (or as a complement to) <DESCRIPTION>, something which
>>>   could look like
>>>      <LABEL context="latex">\frac{\alpha}{\gamma}^2</LABEL>
>>>
>>> Pros and cons:
>>> A) is readily available, but may be in conflict with VOTable
>>>   usage in some contexts (e.g. results of cone search)
>>> B) is also readily available; but it is just a convention
>>>   which can't be enforced, and requires some extra parsing
>>>   from applications to extract this information
>>> C) requires a modification of the VOTable schema -- it could
>>>   be done if a strong requirement is expressed in the
>>>   immediate future...
>>>
>>> Any other comment / suggestion ?
>>>
>>> Cheers, francois
>>>
>
> =======================================================================
> Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
>   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24 24 29
> Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24 24 17
> =======================================================================
>