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

Tue Nov 20 02:47:55 PST 2012

Dear mark,

I registered this morning to the votable mailing list to split the present
discussion in two topics: votable and samp meta data.

2012/11/19 Mark Taylor <m.b.taylor at bristol.ac.uk>

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

Agreed, but I want to insist on the ability to implement standards by
anybody: documents should be clear with no possible confusion and simple
i.e. developers should not guess implicit or missing rules nor choose which
feature to implement.
Ideally a reference standard implementation should help users to use IVOA
standards or get inspired to implement their own.

> One person's simplicity is often another's complexity, and
> getting the standards right is usually a matter of trade-offs.
>

Agreed, but it should also not lead to relaxed standards which satisfies
all wishes and provide too many options.

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

What does mean streaming results in few words ?
Why BINARY is better than other data serialization for such case ?

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

That's not so trivial: I am asking for VOTable clarification /
simplification when handling data and limit optional elements / attributes
i.e. special cases and only enhance SAMP meta data to include current
custom meta data that are worth to be shared.

I thought SAMP meta data were defined as an opened list of key / pair
values defined outside of the SAMP standard itself like MTypes.
I want to describe best practices related to SAMP meta data because the
SAMP standard does not requires any meta data: all are optional.

How to convince application developers to enhance SAMP meta data of their
application(s) if the standards do not require anything ?
Maybe next SAMP standard could at least upgrade its requirements.

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

For interoperability purposes, it is better to build a SAMP meta data
dictionnary with keyword and their meaning (like a data model) and then
expect applications to use them than let anybody create his own custom SAMP
meta data.

Maybe the TCG or DM working group have an opinion on such problems.

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

Great.

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/
> > >
> >
>
> --
> 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/20121120/4429e4fd/attachment-0001.html>