> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
