x-samp namespace suggestion

[Mark Taylor]

Hi Laurent,

On Fri, 30 Sep 2011, Laurent Bourgès wrote:

> > 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).
> 
> I think it is worth to indicate possible keywords in order to let
> developpers reuse some of them. For example, the contact (email) could
> be useful to let the user send an email to the application's author
> ...

Yes but ... it only needs standardisation if the consumer of that
metadata item is a machine and not a human.  In the case of the
email that means if the software is going to offer a button labelled
"mail the author of this software".  If we're going to allow that,
then really it's not sufficient to have the author email address
because that might not be an appropriate recipient for general
emails, so we should also define a mailing list support address if 
one exists, or maybe there's no email but a WWW page with a form
for queries etc... it gets complicated both in the definitions and in
the usage.

If it's not mediated by software, then a human is quite capable of looking
through the metadata list - which is intended to be human-readable -
and spotting something that looks like a suitable email address 
or other contact point if one exists, and standardisation is not required.

There might be other examples of metadata keywords which could benefit
from this kind of standardisation, but I can't think of (m)any.
Arguably, we have already defined too many - of the 5 samp.* 
application metadata items in sec 3.6, I don't think that 
samp.description.text or (especially) samp.description.html 
are widely used, though I am not suggesting we remove them.

> > 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.
> 
> Ok; let's fill the wiki SampXSamp ...

yes.

> >> >> >    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).
> 
> My proposal has two aspects:
> 1/ change SAMP standard section 3.6:  make application meta data
> MANDATORY with at least the keyword samp.application.name which
> becomes REQUIRED)

Given that samp.application.name is already strongly RECOMMENDED I 
don't follow what purpose making it mandatory would serve.
Of course, clients which do not supply this metadata must not
be surprised if some things don't work well.  In some cases they don't
care: for instance a small non-callable client which just registers,
sends a message, and unregisters.  I'd say it's good practice even
for that to supply a name, but if it doesn't, why does it matter?

> 2/ In my proposal, I just want one new keyword
> x-samp.application.identifier containing only alpha numeric characters
> in upper case [ASPRO2] that is related to the application name but is
> an identifier (no white space / punctuation characters) in order to
> let SAMP client application identify one specific application without
> parsing its name (free field - unspecified) that can evolve or contain
> variable information like:
> - "Aspro 2" (upper case and lower case)
> - "Aspro 2 - 0.9.1" (name and version)
> 
> If you prefer you can modify the SAMP standard to impose constraints
> on samp.application.name ...

samp.application.name already is already defined as:

   "A one word title for the application"

The case is not specified (why should it be?), and it may or may not 
be an identifier in any given syntax, but given that it's one word 
I don't think you'd expect it to change/evolve for (e.g. different
versions of) the same application.  So, I think it's suitable for
use as an opaque token for string matching.  Are there any further
constraints you'd like to suggest for the definition?

> > 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.
> 
> In the future (i.e. when the AppRegExt will be one public IVOA
> standard), another identifier could emerge like
> x-samp.application.ivoId containing one valid ivoId value (see xml
> type for its format)

OK yes.

> >> >> 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.
> 
> According to me, it is often difficult to guess the developper needs
> or usages i.e. probably several clients could need keywords having the
> same semantic meaning like author, email ... that's why it will be
> very useful to let developpers inform others using the Samp wiki page
> which official and unofficial keywords are defined.

Yes, you're right. if it becomes clear that some of the existing keys 
(or some new ones) really would benefit from standardisation, 
we can go ahead with that.  Letting these things arise from 
successful usage patterns rather then decreeing up front how people
are going to do things is IMHO a productive way to do this sort of thing.

As you can tell, I'm generally reluctant to add new requirements to
the standard itself.  For some things of course it is necessary.
But if in doubt, I think that it's more agile and works better if
such conventions are outside of the standard.  This is in line with
the history of SAMP.  For instance initially the proposal was that 
the MType vocabulary (samp.load.votable or something) would be a
formally agreed part of the standard.  I think that the flexibility
and success it's had so far have a lot to do with leaving these things
to evolve on their own.

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/