I’ve been arguing with Jim Pitman about how abstracts are different from summaries. The audience, I think, determines whether a text is suitable to be used as a summary.
This seems like a good example:
Lumley, J., Gimson, R., & Rees, O. (2007). Endless documents: a publication as a continual function. In Proceedings of the 2007 ACM symposium on Document engineering (pp. 174-176). Winnipeg, Manitoba, Canada: ACM. doi: 10.1145/1284420.1284463
Variable data can be considered as functions of their bindings to values. The Document Description Framework (DDF) treats documents in this manner, using XSLT semantics to describe document functionality and a variety of related mechanisms to support layout, reference and so forth. But the result of evaluation of a function could itself be a function: can variable data documents behave likewise? We show that documents can be treated as simple continuations within that framework with minor modifications. We demonstrate this on a perpetual diary.
This is a really interesting article from a team at HP Bristol (UK). They seem to be talking about the benefit of publishing as you go along (i.e. blogs or medical records). They call these “continual documents”.
I picked it up ((I came across a conference on ‘document engineering’ [ACM digital library, may have a paywall] while sifting through articles for my literature review. ‘Document engineering’ includes lots of stuff that’s out of scope. Some material, on structural markup,may be relevant to online argumentation.)) because the abstract seemed bizarre, but the topic seemed interesting. “Continual documents” struck me as “continual functions”. And the mention of XSLT hinted at transforming a document using its underlying structure.
Surely, I thought, this abstract couldn’t describe its contents. After glancing through it, I’m not sure: This abstract may well summarize the contents of the article. But for me, the abstract really didn’t serve as a summary: I don’t know the field, so the terminology (e.g. document engineering, Document Description Framework ((One interesting line stands out: “In DDF documents most program elements are <xslt:template/> trees.”))) didn’t clue me in.
This difference gets at what AcaWiki is trying to do: provide a place for people to discuss/summarize research articles, in the way that Wikipedia is a place to discuss/summarize topics. Neither is a place for research but both are places for experts to share knowledge, for would-be-experts to describe what they know, and for non-experts to glean a deeper sense of the world than they might have had otherwise.
I don’t think that’s an argument that an abstract isn’t a summary. Rather it’s an argument (which I agree with) that any abstract/summary is written for a certain audience, it’s hard and sometimes impossible to write one that will serve ANY audience well.
Also, some abstract/sumamries are definitely better than others. Perhaps an especially good one can serve more audiences tan a poor one (and the poorest don’t even serve a single audience well. :) )
I don’t think in general authors are the best ones to write their own abstract/summaries. They’re too close to it, they’re going to end up writing only for the audience of THEMSELVES. Plus, if some abstract/summaries are better than others, that probably means it’s a skill that some are better at than others. But most venues for publication probably can’t afford to pay abstracting specialists to write abstracts, they just take the authors.
At the Code4Lib Journal I’ve always advocated that editors should write the abstract, not authors.