for some time i thought odf might be this format, but i’m leaning more and more towards xhtml, in particular because – as you noted – a lot of our value-adding could simply be done with jquery.

i actually particularly like the aspect of xhtml as a package format. they you can reference – or include – external material is just so well integrated with the web

Most noticeably, the Award Winners were focussed on the presentation rather than the authoring aspect of publication. This reflected the aim of the competition – maybe an aim which didn’t want to really question how journals and article production/editing/publication really fits in this post 1992 world. Roger Clark has an interesting view on this at http://www.rogerclarke.com/EC/ePublAc.html. So, in terms of the competition, your points about writing to requirements regarding headings, styles and linked data during authorship aren’t directly met in these 3 entries but the display of such output is.

General display points: Whilst your post and Inigo’s solution display the whole article as a linear piece, it is interesting that Stuart Chalk’s [Update: I fixed this name for Duncan: ptsefton] system appears to break the article into chunks. This would appear to be straight-forward with each paragraph being referencable – I think Inigo’s solution could match this with simple transformations. The use of auto-generated TOC’s is spot on and something we have in ICE. The journal site layout (URIs) in Inigo’s solution and ICE make the web presence “Cooler” but are still based in the volume/issue framework.

Accessible design is a must and we see it in Inigo’s solution and ICE. Use of well-defined styles is crucial here and should be a part of the floor. In fact, it should be the concrete floor. How data is delivered in an accessible format is something worth thinking about.

Inigo’s linkable paragraphs allows the paragraph to be specifically referred to by both people and machines. I know ICE uses pilcrows (Inigo uses #) to place comments but ICE doesn’t appear to make the paragraph actually referencable (correct me if I’m wrong). By doing this, we could then link the keywords to the paragraph and ontologies to the keywords. We could also find the paragraph-level context in which citations are made. Could we also cite not just a whole article but a specific part of it – is that useful? This perhaps suits Stuart Chalk’s idea and allows us to move around the context of an article.

Inigo’s inline reference display is a good idea and this is something we have running in ICE for footnotes. It’s just sensible for electronic publishing. The citations should really be linked data – whether you create a shiny new linking scheme for triples or use RDFa or a suplemental RDF document. The author/publisher should be responsible for the links but readers might also know of citations that are appropriate and add these as paragraph-level comments – “This is disputed by Smith(2007)”. When the user hovers on the reference, display the citation, when they click on the reference, let them explore the cited article and its linked data – hopefully it won’t be locked away.

Regarding reference management, Inigo provides a References section that can have DOI assertions placed against each citation. Under your scheme, a URL is all the author need provide and the interface should then format the citation as needed. The difference appears to be how you each see the publishing model.

Inigo’s authority-based comments are a good idea. This could even open the editorial team’s ideas up for viewing (I’ve been told that this will never happen). If we linked the OpenID aspect to this, the publisher doesn’t need to determine authority, the reader could. It would also be great to allow annotations to carry linked data as well.

Image annotation would be quite useful when preparing an article and when reviewing/citing. This means that you don’t reference a figure but a region within the image. So we select a region (with the more Facebook-like image region sizing) and refer to Fig 1#4 where #4 refers to a region within Figure 1. For print output we could include a clean figure and one with the regions (including numbers) and an associated index. Inigo gets someway to this and the idea can grow.

Stuart Chalk’s UI provided a keywords index to give a facet-style view into the article. This could provide links to ontologies as well – perhaps reducing the impact within the readable text. So the author/editor/publisher selects the relevant keywords (as usual) and provide ontology link points for them. Would this cure the Potter syndrome?

The winners had a variety of good ideas and I like the fact that there was some money in this. In the end, I think the Article 2.0 idea should be broader than just presenting articles. I think this is really one part of a collaborative researcher workbench that allows work to really exist across a network and as linked data from the get-go. It would be great if a publisher was looking at the entire workflow but, failing that, such systems would still be more expansive than word processor documents alone.

ps. Can we stop calling every evolution 2.0, 3.0 etc? I thought it was a pony tailed marketeering thing.

On RDFa, he was only thinking aloud, but you might like the post on Bryan Lawrence’s blog on implementing RDFa in his wiki, see http://home.badc.rl.ac.uk/lawrence/blog/2008/04/23/creating_rdfa.

Lots more thoughts, more later!