[jmmc-tech-group] SAMP meta-data extensions ?

[Mark Taylor]

Hi Sylvain,

On Wed, 17 Oct 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.
> 
> Of course !
> My idea was obviously to make it mandatory when applicable.

OK, I think it's a difference of terminology.

> > 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.
> 
> I disagree. Such data are fairly standard across SAMP applications today.
> So why not propose a standard in order to let software harvest those data too ?

I'm happy to have those keys listed centrally so that tools
which find them applicable can use them rather than everybody
making up their own (so, for instance, we don't get some people
writing release.date and others writing Release-Date).

However if you take the standardisation seriously you get a load of
questions like what if the relase notes are only in a PDF as part
of a larger document, what if the affiliation has a contact email but
not a web page, what if there's a pre-release JNLP that isn't exactly
a beta, what if the tool has multiple affiliations...
And there will always be important bits of metadata not covered
by the ones you've thought of, so you won't capture everything.
Writing normative text that attempts to address this sort of thing
can be a lot of effort and always ends up not answering all the
questions that come up in practice.

The DM WG tries to tackle this sort of problem for things
like spectral characterisation which actually need to be
machine-readable in order to drive processing (at least, I believe
that's the idea), and it's a lot of work.  A couple of the
proposed items (JNLP URL, maybe homepage URL) listed above do
fall into that category, they can be used by software.
But in most cases here the use of the items will be to present
them to humans to read, so the normalisation of the data isn't
really doing useful work.

> > 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.
> 
> AppLauncher is here to prove this wrong !
> I know lots of astronomers simply ignore existing VO tools.
> Thus a centralized list of them (with their capabilities) would be of great help to enhance VO tools outreach.

As I said, the conclusion seems to be that hosting this information
in an *IVOA Registry* (i.e. the thing overseen by the Registry WG and
accessed using the IVOA RI 1.0 protocol and perhaps its successors)
is not obviously desirable; the lots of astronomers who don't use
VO tools presumably don't access the IVOA Registry much either.

However, providing this information in some form that astronomers
can get at could indeed be very helpful as you say.  One of the
tentative conclusions of earlier discussions was that a
human-readable and human-curated web page listing VO tools might
be a good way to go.  However, if you think a more structured
way of centralising this information can be made to work well,
please go ahead.

Mark

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