SAMP meta-data extensions ?

[Mark Taylor]

Hi Sylvain,

here are my comments.

On Mon, 24 Sep 2012, Sylvain LAFRASSE wrote:

> Following JMMC AppLauncher release last may, we greatly enhanced x-samp keywords described at http://wiki.ivoa.net/twiki/bin/view/IVOA/SampXSamp , in order to automatically gather and exploit SAMP applications meta-data:
>  - x-samp.affiliation.name : the name of the organization delivering the software.
>  - x-samp.affiliation.url : the web homepage of the organization delivering the software.
>  - x-samp.affiliation.contact : the contact web page of the organization delivering the software.
>  - x-samp.jnlp.url : in the same way as =samp.icon.url=, for Java-based application startup.
>  - x-samp.jnlp.beta.url : in the same way as =x-samp.jnlp.url=, for beta release application startup.
>  - x-samp.webapp.url : in the same way as =x-samp.jnlp.url=, for web-based application startup.
>  - x-samp.homepage.url : application homepage URL.
>  - x-samp.releasenotes.url : application release notes URL.
>  - x-samp.rss.url : application RSS feed URL.
>  - x-samp.faq.url : application FAQ URL.
>  - x-samp.authors : application authors.
>  - x-samp.release.version : application version identifier.
>  - x-samp.release.date : application release date.
> 
> We would really need some of them to become mandatory, such as x-samp.jnlp.url or x-samp.webapp.url when applicable.

It doesn't seem to make much sense to have something like jnlp.url as
mandatory, since non-java applications can't supply it.  It could be
strongly encouraged (where applicable) though.

In general: my feeling is that it is worthwhile to have well-known
keys for those metadata items which are intended to be used by
software (e.g. jnlp.url), but for those items which are essentially
directed at humans (e.g. authors) it doesn't serve any
particular purpose to standardise them, especially in view of the
fact that it's going to be hard to come up with a one-size-fits-all
list of metadata items appropriate for all (SAMP or general) applications.
For the human-directed metadata, a human-readable list of key-value
pairs is likely to be a more digestible way to pass on the information.

> We also envision such meta-data to become the root of an open VO application registry data model, with a first working prototype hosted here at JMMC.

A (VO) application registry has as you know been discussed off and on
between the IVOA Registry and Applications WGs for a while.
So far the conclusion seems to be that hosting this information in
an IVOA registry would not provide a particularly useful service.
That's my feeling too, but I think the debate can be re-opened if
people have more to say about it.

In particular if you are proposing a working prototype of a repository
for this information at JMMC, by all means go ahead; it will be
interesting to see what uses people find for it.

Mark

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