New Annotum preview release / question about bibtex

[Carl Leubsdorf, Jr.]

Greetings,

Annotum twitter followers may have seen a recent tweet regarding a preview release of Annotum (copied below).  This is simply the latest Github code installed into a stand-alone wordpress/apache/mysql/php setup based on Server2Go.  I'm excited about this sort of distribution, because it allows users to set up a complete, working, customized wordpress installation with one click.  This is a PC-only approach at present however there is a beta Mac version of Server2Go that I'm looking into as well.

You may find Server2Go very useful in your own wordpress projects.

As for the Annotum preview release, please note that we've made significant progress in the editor (though many bugs -- some quite significant --remain at present), but there is still a ways to go with features such as PDF and XML handling, and references, and we're still adding significant improvements in editor functionality in the coming weeks.  

As always any feedback is particularly welcomed.

Also, a question for this group:  

We're currently storing reference information as serialized php arrays (text), but we are likely going to refactor this storage and instead use bibtex format, with the idea that a future import/export feature would be rather simple to add. 

Any thoughts on that? At this stage the code would simply convert between bibtex and the internal representation we have for references (and ultimately to HTML when viewing an article and XML when exporting to NLM-dtd). 

I have looked at the various plugins available and read discussions of different formats, but I'd be interested in any suggestions or other feedback about this approach.  Should we consider some other format for internal storage?  Any issues with bibtex that would make this approach unworkable?

 

Thanks in advance for your feedback. 

Regards,

-C

[tweet follows]

@annotumAnnotum

New downloadgithub.com/downloads/Anno… - Latest pre-beta + self-contained WAMP+WP stack for stand-alone operation. Readme:gist.github.com/1180028

--

[Fenner...@mh-hannover.de]

Carl,

 

thank you for the update. Peter Sefton has already answered your question on the Beyond the PDF mailing list, so I only add my thoughts briefly here:

 

1) I would use an internal format based on JSON. This could be the CSL input schema https://github.com/citation-style-language/schema/blob/master/csl-data.json.  This makes it easy to format references in CSL, but also to talk to various APIs (e.g. Mendeley, Microsoft Academic Search) and to format references in HTML/CSS/NLM-DTD.

2) I would build BibTex Import/Export filters to make it easy to exchange references with reference managers.

3) I hope that the Wordpress for Scientists community comes up with a standard format and standard location for storing references, so that the various Wordpress plugins can better talk to each other, and to external sources.

 

Best,

 

Martin

 

---

Von: wordpress-fo...@googlegroups.com [mailto:wordpress-fo...@googlegroups.com] Im Auftrag von Carl Leubsdorf, Jr.
Gesendet: Dienstag, 30. August 2011 18:08
An: wordpress-fo...@googlegroups.com
Betreff: New Annotum preview release / question about bibtex

[Phillip Lord]

"Carl Leubsdorf, Jr." <ca...@solvitor.com> writes:
> We're currently storing reference information as serialized php arrays
> (text), but we are likely going to refactor this storage and instead use
> bibtex format, with the idea that a future import/export feature would be
> rather simple to add.

Bibtex is not a simple format, especially if you support it fully (which
you probably wouldn't).

Internally, for kcite, I use PhP objects and a JSON format from
citeproc.js. The PhP objects were useful because I can initialize
sensible defaults and are good for debugging. However, I am not
convinced that this is a good enough reason, and may move to passing
around JSON.

> Any thoughts on that? At this stage the code would simply convert between
> bibtex and the internal representation we have for references (and
> ultimately to HTML when viewing an article and XML when exporting to
> NLM-dtd).
>
> I have looked at the various plugins available and read discussions of
> different formats, but I'd be interested in any suggestions or other
> feedback about this approach. Should we consider some other format for
> internal storage? Any issues with bibtex that would make this approach
> unworkable?

We are in need of a PhP library which encapsulates all of this. I took
my approach because kcite recieves its references in XML (obviously in
two totally unrelated schema, because otherwise it would be too easy)
and outputs in HTML or JSON for citeproc. This sort of thing should be
sharable.

Phil

[Peter Sefton]

A quick comment from me without really thinking about it.

> We are in need of a PhP library which encapsulates all of this. I took
> my approach because kcite recieves its references in XML (obviously in
> two totally unrelated schema, because otherwise it would be too easy)
> and outputs in HTML or JSON for citeproc. This sort of thing should be
> sharable.
>
> Phil

Do we really need a PHP solution for _all_ of this? What if the PHP
took care of an agreed declarative way of representing citations, and
serving citation data, and we used Javascript for the UI part - ie
displayin refernences in different formats etc. This would make it
easier to get stuff that worked across all the different CMS and
repository systems.

--
-------------------------------
Peter Sefton +61410326955 p...@ptsefton.com http://ptsefton.com
Gmail, Twitter & Skype name: ptsefton

[Phillip Lord]

Peter Sefton <ptse...@gmail.com> writes:

> A quick comment from me without really thinking about it.
>
>> We are in need of a PhP library which encapsulates all of this. I took
>> my approach because kcite recieves its references in XML (obviously in
>> two totally unrelated schema, because otherwise it would be too easy)
>> and outputs in HTML or JSON for citeproc. This sort of thing should be
>> sharable.
>>
>> Phil
>
> Do we really need a PHP solution for _all_ of this? What if the PHP
> took care of an agreed declarative way of representing citations, and
> serving citation data, and we used Javascript for the UI part - ie
> displayin refernences in different formats etc. This would make it
> easier to get stuff that worked across all the different CMS and
> repository systems.

Yes, I agree, and this is what I am working on. The idea for kcite is
this....

1) article has DOI/PMID/URL
2) PhP queries PM, crossref, URL gets back, er, something.
3) PhP reconciles and integrates something into JSON
4) PhP serves blogpost and JSON
5) Citeproc generates bibliography and in-text citation client-side.

In the ideal world, of course, PM, crossref or a URL would all return
JSON or better still JSONP. Step 2 would happen in the browser, Steps 3
and 4 would disappear, and issues like caching of query results would
become someone elses problem (which is surely the best kind of problem).

Having said this, doing lots of cleverness in javascript has its
drawbacks. It requires a proper browser client-side (which is going to
make ePuB or PDF export hard), and it's even going to cause issues for
archiving.

So, as far as I can see, the data integration layer at least is stuck
server side for the moment.

Phil

[Peter Sefton]

> Having said this, doing lots of cleverness in javascript has its
> drawbacks. It requires a proper browser client-side (which is going to
> make ePuB or PDF export hard), and it's even going to cause issues for
> archiving.

Not necessarily - how about a nodejs server set up as a service that
can run the client side code - that way you could write stuff like
citation formatting once in one language, with the extra cost of
someone having to provide the service of course. A plugin could run
once to produce a default formatted version for EPUB and for non
javascript browsers. I'll raise the idea of this kind of service on
the JISCHTML5 project.

[Phillip Lord]

Peter Sefton <ptse...@gmail.com> writes:
>> Having said this, doing lots of cleverness in javascript has its
>> drawbacks. It requires a proper browser client-side (which is going to
>> make ePuB or PDF export hard), and it's even going to cause issues for
>> archiving.
> Not necessarily - how about a nodejs server set up as a service that
> can run the client side code - that way you could write stuff like
> citation formatting once in one language, with the extra cost of
> someone having to provide the service of course. A plugin could run
> once to produce a default formatted version for EPUB and for non
> javascript browsers. I'll raise the idea of this kind of service on
> the JISCHTML5 project.

This is true, and I did think about this. The disadvantage as you say is
needing the service to do this. Again, if something is provided, I would
leap at the opportunity of using it.

Phil