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

[Mark Taylor]

Dear Laurent,

On Fri, 16 Nov 2012, Laurent Bourgès wrote:

> Dear mark,
> 
> I am very fed up with IVOA members always working more on their own
> projects than for the community:
> 
> I mean having loose (too relaxed) IVOA standards is not the right answer to
> interoperability issues because only the minimal required subset is then
> implemented and interoperability is minimal.
> 
> For example: VOTable is for me a loose standard because there is too many
> way to provide data (TABLEDATA, FITS, BINARY, BINARY2 ...) with all their
> own options (several encoding ...).
>
> Please KEEP IT SIMPLE as currently implementing VOTABLE completely is a
> very complex task because of its many cases and only partial
> implementations exists for now (maybe topcat is one of the best one but it
> is not perfect).

Unfortunately it is easier to call for simplicity than to achieve it.
One person's simplicity is often another's complexity, and
getting the standards right is usually a matter of trade-offs.

The changes to the VOTable standard currently under way, including the
introduction of BINARY2, have been motivated by complaints from people
attempting to write VOTables (particularly streaming results from TAP)
that it was too complicated to do so given the constraints of VOTable 1.2.
I have tried to conduct the debate about the best way to address that 
as much as possible in public on the mailing list and at IVOA meetings
over the last year or so, though public engagement especially on the
mailing list has not been very wide.

> Concerning SAMP meta data, it's the same problem: loose standard i.e. SAMP
> meta data have no data model (DM WG) whereas it was done few years ago in
> Application Registry DM !

It looks to me like the opposite problem (if problem is the right term);
you're asking for a smaller VOTable standard and a larger SAMP one.

> Moreover, SAMP meta data are all optional and no mandatory even the samp
> application name.
> 
> Why do you encourage such things ? Why SIMPLE, concrete and explicit
> standards fears you ?
> 
> Our SAMP meta proposal consists in extending and making the SAMP meta data
> explicit and in future defined in an uniform way: our ultimate goal is to
> provide a VO software center (app store) to the community as we started by
> providing JMMC AppLauncher: http://www.mariotti.fr/applauncher_page.htm

I'm not trying to squash this proposal, but before adding more
content to the SAMP standard I'd like to be clear what the benefit
of it is supposed to be.

I see the presentation of metadata per application in the applauncher;
it is clearly useful to have per-application information available
for presentation, but it's not obvious to me why information items
like releasenotes.url, rss.url, affiliation.contact are better
provided in a way which is mandated by the standard rather than
as ad-hoc metadata items decided on by each application.
The problem with mandating the provided metadata items centrally
is getting the content right; some applications won't have an RSS
feed, and some will have a twitter account - which ones go in the
official list?  If it's down to the applications what metadata
items to provide, the problem doesn't arise.

But, I'm happy to have the discussion about it and see how other
people feel; if there is general acceptance that incorporation of
this data model into SAMP is a good thing, I'd be pleased to
support it.

Mark


> 2012/11/15 Mark Taylor <m.b.taylor at bristol.ac.uk>
> 
> > On Thu, 15 Nov 2012, Sylvain LAFRASSE wrote:
> >
> > > >>> 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 !
> > > >
> > > > I think the thing I don't understand is: what actual problems does this
> > > > solve?  Harvesting, indexing and publishing metadata is not an end
> > > > in itself, so what useful things does it allow you to do that you
> > > > couldn't do otherwise?
> > >
> > > For example if you want to present harvested data consistently across
> > all applications, and so on.
> > > You can't guess the mining of meta-data without standardizing keywords
> > first (especially for non-machine stuff, like authors list, descriptions,
> > ....)
> >
> > That's certainly true as far as it goes.  But what I'm asking is,
> > what are the (scientific?) use cases for presenting harvested data
> > in that way?  From a data consumer's point of view, why is it useful
> > or important to be able to access the (e.g.) the location of release
> > notes for a range of different applications in a uniform way?
> >
> > --
> > 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/
> >
> 

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