Modify

Opened 5 years ago

Closed 2 years ago

Last modified 2 years ago

#5175 closed enhancement (fixed)

Support for a global BibTeX index

Reported by: mitar Owned by: lcordier
Priority: normal Component: CiteMacro
Severity: normal Keywords:
Cc: mmitar@… Trac Release: 0.11

Description

Support for a global BibTeX index so that it would be possible to have all citation descriptions on one place (preferably in the BibTeX format), for example on one special wiki page (like CiteBibTeX page), which would then be possible to cite on all other wiki pages.

So an user would create a CiteBibTeX wiki page with a BibTeX content and would then be able just to cite that in wiki pages. It would not be necessary to enter citation description on a page where the user wants a citation.

Attachments (0)

Change History (18)

comment:1 Changed 5 years ago by ppggff

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@…

comment:2 Changed 5 years ago by mitar

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.)

comment:3 Changed 5 years ago by ppggff

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.

comment:4 Changed 5 years ago by Amfortas

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

comment:5 Changed 5 years ago by ppggff

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

I will try some other bibtex parser later.

comment:6 Changed 5 years ago by Amfortas

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.

comment:7 follow-up: Changed 5 years ago by Amfortas

I created a ticket #5234 for this problem.

comment:8 in reply to: ↑ 7 Changed 5 years ago by ppggff

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.

comment:9 Changed 5 years ago by Amfortas

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.

comment:10 follow-up: Changed 5 years ago by Amfortas

Sorry bugreports here.

comment:11 in reply to: ↑ 10 Changed 5 years ago by ppggff

Great, I will try it.

About better integrated solution, what do you think
using ticket to store bibtex?

comment:12 follow-up: Changed 5 years ago by mitar

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.

comment:13 follow-up: Changed 5 years ago by 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:

@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?

comment:14 in reply to: ↑ 12 Changed 5 years ago by ppggff

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?

comment:15 in reply to: ↑ 13 Changed 5 years ago by mitar

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.)

comment:16 Changed 5 years ago by Amfortas

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..;)

comment:17 Changed 2 years ago by Amfortas

  • Resolution set to fixed
  • Status changed from new to closed

comment:18 Changed 2 years ago by mitar

Uuu. Thanks! Will check it out.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.