x-samp namespace suggestion

[Mark Taylor]

On Thu, 29 Sep 2011, Laurent Bourgès wrote:

> Dear all,
> 
> few comments below:
> 
> 2011/9/27 Mark Taylor <m.b.taylor at bristol.ac.uk>:
> > On Tue, 27 Sep 2011, Sylvain LAFRASSE wrote:
> >
> >> >    1. Is the x-samp convention a good idea?
> >>
> >> It sounds a litlle bit conservatve to me, but should be a a good workaround to the heavy standard updating process.
> 
> Agreed. I propose also to have one wiki page giving the complete list
> of application meta data keywords used among all SAMP applications
> worldwide. I am convinced that such keywords are subject to change
> that's why it can become boring / difficult to maintain the SAMP
> standard document every time a new keyword is needed. What do you
> think to externalize this part of the specification (section 3.6) into
> one wiki page that will act as one official extension of the SAMP
> standard ?

Having an external wiki page is a good idea, but I wouldn't externalise
the whole thing - I still think it makes sense to split the metadata
keys (and other cases where extensible vocabularies are used) into
three basic categories:

   1. samp.*:
       Well-known, agreed, stable, will not change
   2. x-samp.*:
       Suggested for possible future promotion to samp.*
   3. (others):
       Used by some clients, but no requirement to be well-known

Items in classes 1 and 2 are intended for programmatic manipulation
by general SAMP clients that understand their semantics; for instance
the samp.name and samp.icon.url will often be used to identify a 
client to users in a GUI.
Items in class 3 fall into two categories: either they are intended
for use by other "friendly" applications, by arrangement between
the developers involved, or they are intended mainly for human
consumption.  Something like TOPCAT's author.affiliation is
intentionally in category 3; it's just there for interested readers,
it's not expected that SAMP hubs/clients will do anything special with
this other than present it as an opaque piece of metadata to human
users or other consumers.

So I think class 1 should stay defined within the SAMP standard.
Class 2 should have their own wiki page, I've set up the page
SampXSamp (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampXSamp)
as a placeholder for this, it should perhaps be subdivided for the
different vocabularies (metadata keys, lockfile keys, etc).
I don't think there's much value in trying to standardise all
possible metadata keys (or other vocabulary items).
Whether a particular item (such as software version) belongs in 
class 2 or 3 is a question which can be argued separately, but
my feeling is that unless there is some specific reason that
software needs to understand the semantics of a particular item,
there is little value in standardising it.  Items like JNLP URL
are clearly in class 2, since to be useful, clients have to 
know how to find it.

> >> >    2. Should the imminent version (1.3) of the standard include a
> >> >       new metadata item samp.application-identifier (or something
> >> >       else along similar lines, and if so what)?
> >>
> >> Our point was twofold.
> >> The straight forward one is that samp.application.name should be MANDATORY.
> >
> > A mandatory metadata item does not make much sense, since clients
> > are not obliged to declare metadata at all.  Of the existing metadata
> > items, none is mandatory, but samp.name is "strongly RECOMMENDED",
> > and as far as I know nearly all clients provide it.  If your tool
> > has a requirement for one or more particular metadata items, it seems
> > reasonable that it just won't work for clients which don't
> > provide them.
> 
> As you said: "as far as I know nearly all clients provide it", I
> propose to modify the standard to make application meta data MANDATORY
> with at least (samp.application.name and
> x-samp.application.identifier) and one new recommended keyword
> x-samp.application.link that points to an URI describing the
> application (home page for example).

We can't make x-samp.application.identifier mandatory at the moment,
since the ApplicationRegExt standard that it would need to make sense
doesn't exist yet.  I think it would be a bad idea in any case, since
you might just put together a tiny temporary test client for which it
makes no sense to have an application registration.

> >> Then, our projects would need a keyword to point to a download page for any application (preferably a JNLP URL ;). The definite solution would of course be having a universal app identifier that points to a registry entry with all the application details !
> 
> We also need - as sylvain said - the JNLP (Java web start application)
> URL; I propose the keyword x-samp.application.link.jnlp
> 
> >
> > Given that we go ahead with the x-samp business, you could suggest
> > one or more metadata keys and the SAMP community could experiment
> > with adopting them.  If they look like they are useful, we can
> > make them official in a future version of the standard.
> > I've added a new wiki page
> > http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampXSamp
> > for listing/discussing such things.
> 
> Great; maybe someone (mark ? us at jmmc) should gather all known
> non-standard keywords into such wiki pages to propose new xsamp
> keywords ...
> 
> I mean topcat, aladin and our applications already use non-standard
> keywords curation (affiliation, author, email), description (home
> page, documentation / support web pages ...) and one very important:
> application.version (public, beta, 0.9.0 ...)

If you want to collate this list and suggest corresponding x-samp
keys on or near the SampXSamp wiki page then go ahead.
As I say I feel that standardisation only brings benefits for those 
keys for which clients have some need of semantic understanding.
Probably some of the keys currently in use do fall into that category,
but I'm sure some don't.

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/