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

Mark Taylor m.b.taylor at bristol.ac.uk
Fri Oct 19 09:30:29 PDT 2012


On Thu, 18 Oct 2012, Sylvain LAFRASSE wrote:

> >>> In general: my feeling is that it is worthwhile to have well-known
> >>> keys for those metadata items which are intended to be used by
> >>> software (e.g. jnlp.url), but for those items which are essentially
> >>> directed at humans (e.g. authors) it doesn't serve any
> >>> particular purpose to standardise them, especially in view of the
> >>> fact that it's going to be hard to come up with a one-size-fits-all
> >>> list of metadata items appropriate for all (SAMP or general) applications.
> >> 
> >> I disagree. Such data are fairly standard across SAMP applications today.
> >> So why not propose a standard in order to let software harvest those data too ?
> > 
> > I'm happy to have those keys listed centrally so that tools
> > which find them applicable can use them rather than everybody
> > making up their own (so, for instance, we don't get some people
> > writing release.date and others writing Release-Date).
> > 
> > However if you take the standardisation seriously you get a load of
> > questions like what if the relase notes are only in a PDF as part
> > of a larger document, what if the affiliation has a contact email but
> > not a web page, what if there's a pre-release JNLP that isn't exactly
> > a beta, what if the tool has multiple affiliations...
> > And there will always be important bits of metadata not covered
> > by the ones you've thought of, so you won't capture everything.
> > Writing normative text that attempts to address this sort of thing
> > can be a lot of effort and always ends up not answering all the
> > questions that come up in practice.
> 
> I really understand all those issues. And my propositions will undoubtedly not fill all needs (but seems to already lots of SAMP apps meta-data AppLauncher embed).
> But if the community waits endlessly for the perfect solution (the one that would fit all use-cases) to arise from "we don't now where", nothing happened at all.

I agree that's true.

> So a good trade-off would then be to (at least) add/update the listed x-samp keywords the community consider relevant in each official SAMP standard to come.

I'm hoping that the next SAMP version will not be for a while yet.
So for now let's leave that list in place, and revisit the question
of making it official if/when the next revision looks imminent.

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

Mark

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


More information about the apps-samp mailing list