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

[Andreas Tille-5]

[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@...???).

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


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Wise-3]

This idea of extra metadata storage is really excellent.

I'd like to suggest the following:

Move this thread to debian-devel for a wider discussion.

Move the upstream-metadata.yaml, Homepage, debian/watch out of source
packages since they need to be able to change independently of the
Debian package. Not sure what the right location is, but I'd suggest
UDD could be the canonical location for it and a web interface at
alioth be the way to edit it (like the debtags interface).

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 29/10/09 at 10:29 +0800, Paul Wise wrote:

> This idea of extra metadata storage is really excellent.
>
> I'd like to suggest the following:
>
> Move this thread to debian-devel for a wider discussion.
>
> Move the upstream-metadata.yaml, Homepage, debian/watch out of source
> packages since they need to be able to change independently of the
> Debian package. Not sure what the right location is, but I'd suggest
> UDD could be the canonical location for it and a web interface at
> alioth be the way to edit it (like the debtags interface).

Some comments:
1/ UDD currently can't be the canonical location for this data: there
are no backups of UDD currently, because it's supposed to be possible to
remove the database, create it again, and import everything back in less
than 2 days. So ideally, there would be another place where that data is
stored, and it's simply imported to UDD. Or we would have to talk to DSA
about backups (also possible).

2/ You might be trying to be too generic here. There are not so many
different kinds of packages metadata that would be suitable for this
thing, so you might want to just build it for your purpose (bibtex
metadata) and forget the general picture.

Past efforts for building a unified repository of metadata have
basically failed, because of a lack of interest in the end, I think. It
might be better to store that data directly into packages
(debian/foo.bib), and have an UDD importer that extracts that data from
packages.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...