Re: Gathering package upstream meta-data in the UDD. (was: Re: more formally indicating the registration URL)

[Andreas Tille <andreas@an3as.eu>]

[Moving a thread from debian-med to debian-science because the problem
 originated here some time ago.]

On Wed, Oct 28, 2009 at 07:35:10PM +0900, Charles Plessy wrote:
> 
> That is a good question, that I would rephrase: what should be stored, and
> should everything be exported?

The current use of specific publication data is a good application for
upstream-metadata.yaml and here we actually need single fields of the
BibTeX record.  So whether it should be exported can clearly be answered
with yes.  It is just the question how to store it in UDD.
 
> For the moment the BibTeX stored reference is a rather experimental feature,
> and its purpose is also to test the YAML format.

Sure, thats perfectly all right.  But we have an application for exactly
this *now* and IMHO it makes sense to clarify this in the beginning.

> As you probalbly noticed, the
> key parts of the BibTeX reference that allow to construct a weblink to the
> published article???the digital object identifier (DOI) and the PubMed record
> ID???have their own YAML mapping:

Ahh, good you bring up this point again because I stumbled upon this but
forgot to mention in my reply: I do not consider it a good idea to store
one field two times.  This just sucks.  IMHO DOI and PubMed just are
publication data and mention them twice. is wrong.

> I do not expect the BibTeX reference to be
> extracted and parsed, nor to be exported to SQL.

But that's exactly what I need to do to solve the original problem to
publish the publication data on the tasks pages.  I perfectly agree the
scope of your suggestion is much wider - but if we see a need for
storing the publication data we should clarify in the beginning how they
should be handled and whether the form is apropriately choosen.

> On the other hand, it can be
> easily popped out at build time with a Perl oneliner
> (???http://lists.debian.org/msgid-search/20090808073608.GF17276@kunpuu.plessy.org???).

Well, yes, that presents any YAML field - but you need to parse the
BibTeX format in case you extract the Reference field.
 
> [For further discussion about how to make nice links on the Blends web
> sentinels, I propose to elaborate on another list.]

I'm not sure whether my move to debian-science was the list you had
in mind - but I think it is a wider forum which has an interest in
publication issues.

> There is another volatile meta-data with a much broader scope that could be
> included in the upstream-metadata.yaml file (or whichever smarter name we give
> to it), the Debian watch file. All the objections you made above apply.
> 
> ...
>
> While the last option looks more structured, we should really think twice if it
> makes sense to have the `Watch` metadata in a tabluar SQL database, or if
> simply storing it raw somewhere else is enough. The same conclusion may apply
> to similar resources like the BibTeX reference.

While I perfectly agree that data in watch files are actually
upstream-metadata I do not think that any atempt to move this data to
another place would be really successful.  The rationale why I'm
thinking so is that you try to fix a non existent problem.  Normally you
change something if you realise something is broken.  Even then it is
hard to exchange an established system.  But with watch files nothing is
broken in principle.  (Well, there are issues with uscan and there are
several atempts to enhance this - but this is not a problem *where*
(debian/watch or a different file) the data is stored nor *how* (text or
yaml)).  So if you are atempting to gather agreement for a new control
file (which is reasonable in my opinion ) I would not start with
convincing people to change things which do not really need a change.

Kind regards

     Andreas.

-- 
http://fam-tille.de