[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.gf17...@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 -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
