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

[Laurent Bourgès]

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

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 !

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

Best regards,
Laurent

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/apps-samp/attachments/20121116/683c0365/attachment.html>