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

[Sylvain LAFRASSE]

On 17 oct. 2012, at 16:39, Mark Taylor wrote:

> 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.

I really understand all those issues. And my propositions will undoubtedly not fill all needs (but seems to already lots of SAMP apps meta-data AppLauncher embed).
But if the community waits endlessly for the perfect solution (the one that would fit all use-cases) to arise from "we don't now where", nothing happened at all.
So a good trade-off would then be to (at least) add/update the listed x-samp keywords the community consider relevant in each official SAMP standard to come.

> 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.

Except for meta-data harvesting, indexing and publication !

> 
>>> 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/