Right, but you can provide a platform for solving these problems over time if you make publishing work off of an extensible, data-presentation separate document model. PDF isn't it.

More directly to your point: I agree that the "telling a story" via a x-number page document is important. I'm not arguing for changing the general method by which scientific results are conveyed from an author to the audience (i.e. description of problem, description of approach, description of results, analysis of results and conclusion). It's just that once I've digested your results, I want to analyze them critically, re-use them, integrate them into my work, etc. Publishers should facilitate that.

Why can't I easily copy a list of genes from a table in YOUR paper so that I can check if they are present in MY work. Why don't terms and gene names and genic loci show up as links that take me to the genome browser of my choice when I click on them? These are simple problems to solve once you have a richer document format.

I guess I just much prefer the idea of a "paper" as published being self-contained, and "supplementary" material being separate. A paper shouldn't become incomplete if it is printed on paper or if the links are broken.

> It's just that once I've digested your results, I want to analyze them critically, re-use them, integrate them into my work, etc. Publishers should facilitate that.

I completely agree! But I think this is a separate process from just reading the results, and is best done with separate tools. I think all the things in your last paragraph should be easy to do, but I'm not sure if the best way to do them is to embed them in the same document that's published in the journal.

For example, suppose I publish the results of an analysis on genomes of 100 fruit flies I raised in the lab. Here are some things you might be interested in acquiring:

- the text I published (say as pdf, or some other format) with included figures, references, etc (the thing that appears in the journal) -- say 4 megabytes

- the document used to generate the above document (e.g. LaTeX file) -- less than 1 MB

- high-resolution pictures of the flies' eyes up close -- say 10 more megabytes

- high-resolution plots of data -- say 2 more megabytes

- raw data used for these plots and analogous plots not presented -- lists of genes and statistics -- call it a megabyte.

- source code used to generate this data from the genomes and plot it -- not more than a megabyte.

- raw genomes of all flies in my study -- in the 10s of gigabytes.

Now how much of this data do we want to bundle in as part of the original document? Keep in mind that 95% of readers are only interested in the first item on the list -- the 4-MB document that was published in the journal. Should we also embed in it an additional 15 MB of data for those few who might be interested, and make the document somehow interactive so that this data is accessible by clicking? (Of course, we definitely can't embed the gigabytes of raw genome data, so we'll need a separate solution for distributing that anyway.)

I'd argue that a better solution is to simply bundle all of this "supplementary" stuff separately in a .zip and make it available for download separately. Again, very large files or datasets will still need their own solution -- for instance, I might host the genomes on my website and just provide you with the link.

This isn't to say that pdf itself is the be-all and end-all of portable document formats (although I think it's very good), but I do want to argue against bloating the published report document with what I view as supplementary information, because it's hard to tell where to draw the line, and this imposes a large memory cost on lots of people who don't need it. (As a sidenote, if I want someone's code and data, getting it from within the document by clicking links also seems a bit odd to me -- where in a published article should these links go?) So I really feel like separate downloads is the best solution.

Sorry, I didn't mean to propose that all of this data would be included when you download the document. A downloaded document could be as simple as a hash or a document identification # (or a magnet link :)). You open this document in a program like Papers and, after downloading the main text, presentation style sheet and main figures, could then selectively download whatever you'd like. So, if you want to zoom in on those fly eyes, you right on the image and get a context menu that allows you to see the original image.

These are implementation issues. The document format does not have to contain any supplementary or additional whatsoever. It could contain references to where the ancillary content is found. It is then up to the interpreting program to decide how it wants to allow you to download that additional content (e.g. automatically, selectively, based on heuristics, etc).

The practical upshot of this is that you get to keep all the data related to the paper in one place with one organizational tool, with relational information intact.

Hmm. Sorta like hypertext. We have a pretty popular implementation of that already, what's missing?

Sounds tough to achieve, but that would certainly be a nice goal to shoot for!

I would kill for ubiquitous LaTeX file availability - my e-reader does not reflow PDF well, especially multi-columned. Being able to generate an ePub instead would be worth paying for. To be vaguely on-topic, producing better open-source software tools is exactly the kind of thing the folk at http://www.sciencehackday.com do. Encouraging making the produced tools publicly available might well help.