Re: Turning debian/upstream into BibTeX (Was: Tasks pages (close to) fixed; Bibref does not seem to be updated automatically)
> Published-Authors: Alois Schlögl, Clemens Brunner
> Published-DOI: 10.1109/MC.2008.407
> Published-In: Computer, 41(10): 44-50
> Published-Title: BioSig: A Free and Open Source Software Library for BCI Research
> Published-URL: http://pub.ist.ac.at/~schloegl/publications/Schloegl2007_BCI_Software.pdf
> Published-Year: 2008
> Published-Authors: Some other Author
> Published-Title: Some stupid title
> ...
> value text NOT NULL,
> rank int NOT NULL,
> PRIMARY KEY (package,key,rank)
> );
> >...<
> In short: If we really want to support multiple references we need to
> clarify the use cases and the implementation details first. I'm
> personally not really convinced that we could not go with one major
> reference per package and whether the trouble we need to deal with is
> worth the effort for some exceptions.
What about adding an explicit 'Key' field, e.g.
Published-Key: IntroPaper
or may be even (I guess uglier -- just throwing ideas) using the key
within field name:
Published-IntroPaper-Authors:
...
Published-Method-Authors:
Then bib entry could get an entry code as 'Package:Key'
For the task pages, you can indeed take the first or the last entry
> > ;-)
> BTW, every developer is free to mention debian/upstream in debian/docs
> for the moment - we just missed to do this.
I should start introducing it to my packages following
http://wiki.debian.org/UpstreamMetadata
specs
> fine. The only thing we should decide when finding a name would be
> whether we want to restrict it explicitely to bibliography or whether
> we rather stick to a more generic "upstream" name which enables more
> flexibility in case we need to handle some other upstream data.
rright -- what other use cases do you see behind such tools?
> > IIRC I have looked for such a place and there were no suitable one (I
> > could be wrong), so in that preliminary debian-bibliography
> > package we placed /usr/share/bib/debian.bib with the intent to seek
> > adding /usr/share/bib into default BIBINPUTS.
> I do not consider /usr/share as the right place to put autogenerated
> data and the method I described is autogenerated.
yeap -- I got that aspect ;-) But if we would be to hunt adjusting
default BIBINPUTS we could extend it with /var location as well.... or
we could just symlink it under /usr/share/bib -- it seems to be not
uncommon to symlink /var stuff under /usr
> So this is rather a manually compiled list of references and is
> something else than what we discussed before about fetching the
> bibliographic data from debian/upstream right?
yeap -- although for debian policy, dev ref we might just get /upstream
I still see some cases (e.g. those references from the debian wiki)
where statically generated file might be worth... or another side could
be -- is it really worth demanding installing debian-policy and dev-ref
packages just to get their bib entries for citation?
> Or do you want to freeze
> the bibliographic data at some certain point in time inside a source
> package and then upload this package with the references? I'd regard
> this method as a possible alternative with the drawback of beeing not
> perfectly up to date - just to make sure I do understand you correctly.
once again -- that one was intended to be complimentary to 'software'
bibliography
as for "frozen version" -- we indeed might like to generate the ultimate
.bib file through harvesting full archive
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
Reply to: