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

[Sylvain LAFRASSE]

Hello,

On 19 oct. 2012, at 18:30, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:

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

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

Sylvain

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