Support for a global BibTeX index

Ticket 453 talk about the idea. Your idea is good. I think there maybe are lots of "special wiki page" for citation, then user can use Tag or Wiki to manage them.

I also have some ideas:

1. should we make one wiki page per bibtex item, then the wiki link is citation link
2. should we use ticket to store them. We can use TicketExtPlugin or CustomFieldAdminPlugin to !add bibtex items, or we could build a plugin to do this
3. should we build a whole new bibtex plugin, it can Add, Import, Export, Search, List, Edit, Attach PDF or PS and so on

My whole idea is processing bibtex with Trac's advantages, such as wiki, svn, ticket...

email: pgf00a@gmail.com

I like the release soon, release often philosophy. So that we do not make a too complicated system at the start which will never be implemented.

So maybe the 1. can be a general case for my idea. Similar to Trac templates. Where you can have a default template wiki page and then other templates. So we could make a CiteBibTeX page, but also CiteBibTeX/Knuth, CiteBibTeX/Graham pages and others. And as you have written, if you would make a link to that page, it would be a citation link (so you could also make a citation to multiple resources at the same time if there would be multiple resources on this special page). But you could also cite only one resource through a resource name, as you can do it currently.

I do not really like the 2. idea as I see that as a misuse of a ticketing system (especially if you are using them for project development).

3. is maybe a good idea for the next version.

I do not know. I would be more than glad just to have one page for all citation descriptions in BibTeX format so that it would be easy to manage them. Everything else is somehow too complex and unnecessarily for me (I like simple and minimalistic approaches and that is why I like Trac). For example problem with 1. is wiki page namespace pollution. With 2. misuse of a ticketing system. And with 3. a whole new system to learn (and first to implement).

(I hope my commentary will not be understood negatively, I just like simple plugins with small features which you then combine and not do-everything things. So CiteMacro is really great currently, it is just a little bit hard to manage citation descriptions if you have them spread over multiple (sub)pages.)

Ok, release soon, release often.

I want to make the idea more general, and let it work with CiteMacro:

1. user could select one or more bibtex source for CiteMacro
2. the source could be wiki page, blocks in wiki page, file in svn and so on (not just special wiki page)

Actually, the 1. idea means one Article per wiki page, then the wiki link is "citation link". We can build an import tools to import bibtex...

And the 2. idea is an easy implementation of the 3. idea, we can add, comment, edit, attach file, cite, sort, list, and so on. Maybe a little misuse, but very easy to implement. We also can build an import tools.

I wrote a plugin which can handle bibtex files out of svn, git and wiki attachments.

The intention of the plugin is, that the bitex file is shared like normal sourcecode and locally changed via pybliographer, jabref, etc.
So the bibtex file can't be modified via trac at the moment, but this seems an interesting idea.

Have a look if you want: TracBib

TracBib is great. But I think it is difficult to install python-bibtex on Windows.

I will try some other bibtex parser later.

Maybe I should remove the dependency and include a pure pyhton parser, but until now I could not find an alternative that I like. Maybe I give BibTexParse a chance.

I created a ticket #5234 for this problem.

Replying to Amfortas:

I created a ticket #5234 for this problem.

Yes, BibTexParse? is ok, I tried it before. By the way, please try "use wiki page to store BibTex?". I think it is useful since user can edit it.

switched to bibtex parse, now it should run on windows, please check it and open a ticked here if something goes wrong.

Regarding the wiki page thing, I must confess that I do not like this solution, I know at the moment it is not pssible for users to edit the bibtex file directly IN the wiki but the bibtex file can be changed by commits or by downloading - changing - uploading again.

I have to think about a better integrated solution than such a wiki-page-hack.

Sorry bugreports here.

Great, I will try it.
About better integrated solution, what do you think using ticket to store bibtex?

Why do you see a wiki page solution as a hack? I see it as a normal approach taken also by Trac itself to configure some Trac behaviour (like templates).

Definitely using a repository means that users which would otherwise only have an access to wiki need access to a repository. And using tickets - this is a pollution. And again the problem with granting access for tickets applies.

So to summarize the wikipage idea as I understand it (please correct me):
As a first step you got a wiki page www.whatever/wiki/BibTex and the content of the wiki page are bibtex entries like this:

@Article{SSS07:eandi,
  Author         = {Schmid, Ulrich and Steininger, Andreas and Sust,
                   Manfred },
  Title          = {{FIT-IT}-{P}rojekt {DARTS}: {D}ezentrale
                   fehlertolerante {T}aktgenerierung},
  year           = 2007

And the corresponding pdfs, ps, dvis are attached to this wiki page and could be found with another keyentry like:

...
attached=file.pdf
...

And then I cite wherever I want.

And as a second step there would be some kind of webinterface to manage these entries and attachments without editing the wiki page directly?

Replying to mitar:

And using tickets - this is a pollution. And again the problem with granting access for tickets applies.

Why? Why can not the article as a ticket?
In a lab, we need article just as a ticket:

• "new ticket" means: we got a new paper to read
• "accept ticket" means: this paper is read
• and so on ...

Since we could add "User define" info in a ticket, we could set article's type...
And, we could "Query", "List", ... ticket then.
Also user can comment it.

---

About the using wiki to store bibtex, maybe use a spical block, such as

{{{
#!bibtex

... bibtex data goes here ...

}}}

then user could put this kind of block in any wiki page.

Another way is "create one wiki per article". (put bibtex block in that wiki page, and write some other info in it) Then user could cite a article use TracLink. And we could attach PDFs as the same way as attach file in wiki page.

What do you think?

Replying to Amfortas:

So to summarize the wikipage idea as I understand it (please correct me):
As a first step you got a wiki page www.whatever/wiki/BibTex and the content of the wiki page are bibtex entries like this:

Yes. I would like to use only one special page with a list of all reference data in BibTeX format. Mostly because of the performance hit if we would to process all wiki pages.

And the corresponding pdfs, ps, dvis are attached to this wiki page and could be found with another keyentry like:

I am not sure if I understand what you mean by finding. You mean add to the entry? Connect with it?

I would maybe rather see a possibility to add to an entry a Trac link (which will cover also attachments, repository files and others) to a (local) PDF.

And then I cite wherever I want.

Yes. And the list of references at the end of a given wiki page would display only those really used in that wiki page.

And if a reference would have an url attribute there would be a link to that (as it is also now). And if there is a Trac link attached that would be displayed as local copy (additional) link.

And as a second step there would be some kind of webinterface to manage these entries and attachments without editing the wiki page directly?

No, why would this be needed? (My) idea is to reduce systems needed to make a reference. To use something you are familiar with when you are writing a wiki page entry - a wiki system. Something like BadContent page is.

Replying to ppggff:

Why? Why can not the article as a ticket?
In a lab, we need article just as a ticket: * "new ticket" means: we got a new paper to read * "accept ticket" means: this paper is read * and so on ...

Hm, there are different uses of Trac. In my example I am using Trac also for developing and project management of a software project. So I would like to use tickets and repository just for that. But I would like to use wiki for documentation (of project and also of design choices and also for (wikified) articles which describe the project). And in that documentation I would like to be able to use references to articles. And I would like that I have to define those articles only once. And the easiest way from my point of view is to have a special wiki page which would have all those references defined. And for linking to PDFs I would like to define two of them on that wiki page. One would be a BibTeX link to an original PDF URL, the other would be a link to a local copy of it (and that link would be Trac link, so anything would go, link to a that wiki attachment, link to repository file, etc.). So it would be nice to be able to attach this info to the BibTeX entry.

I can also imagine a setup where different persons are writing user documentation and different persons are developing and even different persons are doing technical support for the project. And you would like to use citations only in the documentation without a need for tickets or repository checkout/checking just to make a new reference. You are used to (and maybe have privileges just for) wiki and you would like to make a reference, but you would like to have a central page for all those reference data, so you do not have to define references again and again.

then user could put this kind of block in any wiki page.

Then the plugin will have to read (and parse) all wiki pages to get an actual list of possible citations? Or am I missing something? Or will those pages have some common prefix so they will be separate to other wiki pages?

Another way is "create one wiki per article". (put bibtex block in that wiki page, and write some other info in it) Then user could cite a article use TracLink. And we could attach PDFs as the same way as attach file in wiki page.

So the idea is that BibTeX block would be available only in those special pages with article description/PDF link/attachment? Maybe this should be configurable (do you want that all pages are parsed or if you want only one page).

Maybe one way to go would be to define extension points so that other plugins could extend reference data? So we would have one plugin/macro which would be used to cite and display references at the end of the wiki page. And then we would be able to insert data in different ways to that plugin. From repositories, from wiki pages, from multiple wiki pages...

(Sorry for long comment.)

Back after a long break,

Thanks for all the input. I rewrote the plugin and in the new version a lot of new things are possible. Check out [TracBibPlugin] for details

A short overview: Ressources can be loaded in these ways now:

[[BibAdd(source:path/to/file[@rev])]]  # add a file from source 
[[BibAdd(attachment:[wikipage/]file)]] # add a file from a wiki attachment        
[[BibAdd(wiki:page)]]                  # use a wiki page 

Make sure to put your bibtex entries into a code block when they are on a wiki page like this:

%inserte entries here

You can use BibAdd? multiple times on a wiki page and load from different sources.

I also considered the BadContent Idea. The Wiki Page [BibTex?] is invoked automatically if it exists.

Give it a try and report if you find bugs or have ohter ideas which you want to see.

In a next step I'd like to add the possibility to add BibTex? files from ticket attachments or from a ticket itself. But be patient with me..;)

Uuu. Thanks! Will check it out.