Creating an Endnote(/BibTeX)-Killer
Art Rhyno has an interesting blog on library-oriented technology, and some thoughts on some of the pieces necessary for an Endnote-killer.
Having thought about this deeply for the past year or so, I think it best to start fresh. Certainly it is important to learn from existing solutions, but it would be a mistake to think there are not better ideas floating around.
My key argument would be that it is time to get rid of monolithic applications. Like Word, Endnote is a monolithic application. It is a database for reference data, it is an online search/and query tool, and it is a citation formatter. These functions need not all be included in a single application, and we’ll get to where we need to go quicker and with greater flexibility if we can not just recognize that, but exploit it.
So here are the pieces we need:
- A formatting engine independent of any particular data model. Whether the thing is written in Perl, or C, or Java, or – as Bibliofile (soon to be renamed BiblioX) is – XSLT, the sole job of this engine ought to be to suck in XML data, and spit out formatted citations. The formatting style specification must itself be XML. Aside from that it ought to be open to any format for which one can write an input driver. If anyone has XSLT skills and is willing to contribute, Bibliofile is the best place to start.
- Rich metadata serialized in XML and representable in RDF. BibTeX is not the place to start here; its data model is simply wrong. Likewise, the data model in applications like Endnote is also broken.
- An online query/download utility. Like the above, this should focus on acquiring metadata in XML if possible, and passing it to other applications and tools.
All of the above have the common theme that they are small and task-focused, and based on open metadata. They also must be open source. Different projects – OpenOffice, Chandler, etc. – can contribute unique end-user experience by drawing on those tools.
Thanks, I had forgot about Chandler. I think the key is XML, there are tools like JAFER which fit well within an XML framework to provide the extra functions like Z39.50. Cocoon can be a great backend to OpenOffice, and has components for transforming XML content to everything from calendar formats to images. But the data model is a big piece of the puzzle, and I am wondering if some combination of DocBook and MODS provide enough metadata muscle for citations.
Hmm … Cocoon + OpenOffice? How would you see that working? As an option for the bibliographic project to explore, or as an alternative for workgroup settings?
The addition of the new biblioref element to DocBook adds the missing piece of the document puzzle. With respect to bibliographic metadata, MODS is certainly rich enough for my needs. I just need some XSLT tools to actually transform them into something useful! This is why bibliofile/x is important. The idea ultimately is that a user could optionally (perhaps with a parameter option) use it with default DocBook stylesheets. Norm Walsh has joined the development list, so maybe there’s some hope there. The style spec for the processor is still too much influenced by BibTeX for tastes though…
Cocoon would allow storing OpenOffice content on a server in a way that the content could easily be re-purposed. For example, you could create citations in OpenOffice, and make them available in PDF, SVG, RTF, and a slew of other formats. Or at least it seems possible, there are projects that use Cocoon on the back end with OpenOffice but so far the only application I have used in this manner is Mozilla’s calendar. Ideally, I would like to feed Mozilla’s calendar and bookmarks, other browser bookmarks and OpenOffice into Cocoon as XML streams.
What’s wrong with bibtex?
(La)TeX-only, poor data model, no unicode support, obtuse style specification language, etc.