[okfn-discuss] A question of history

Thu May 25 10:11:46 UTC 2006

Matthew Brett wrote:
[snip]
>> Yes. I think to simplify here we have the following requirements
>>
>> 1. Ability to store raw manuscript (and versions thereof)
>> 2. Ability to compare this manuscript against other manuscript
>> 3. Ability to annotate a munuscript
> 
> 
> Well, yes.  The problem here is that this enterprise is the ordinary
> stuff of this type of history, so there are several projects that are
> well down the line.  In practice there is virtually never a raw raw
> stage when you just have the document in text without any annotations,
> and I believe it would not be very useful in that state.  The

But that must be what you start with and while I would agree that would 
not necessarily be what you want to look at is it not useful for seeing 
what decisions were made?

> annotations start very early in the process of creating the document.
> An example is here:
> 
> http://wtfaculty.wtamu.edu/~bbrasington/panormia.html

I've taken a look and now, unsurprisinly!, have a much better idea about 
the matter at hand and it seems the textual requirements are pretty simple:
   * the texts are plain ascii
   * the annotations are simple footnotes

> In fact, funnily enough, Martin started off using tex for markup, many
> year ago, thus freaking out his more technophobic colleagues, and
> making things rather difficult for him too.  He then moved to MS Word
> - which is the source of the pdfs you see above.

In the long run whatever one does it would seem sensible to move away 
from word since the format is obfuscated and therefore ends up tying the 
data to the tool -- definitely not what one wants here. The obvious 
thing would be go initially to OpenOffice: it can import .doc without 
problem, is very similar to Word in appearance for those used to Word, 
has PDF export built in and, most importantly, has a back end xml format 
that is well-documented and fairly easy to manipulate with standard 
tools (xsl etc).

> I suppose the obvious response is, that y'all wouldn't have started
> from here if y'all were me, but, given the example above is fairly
> typical of the state of a fairly large number of works-in-progress,
> the practical question becomes, can anyone think of a way to go, from
> these Word documents, with the huge amount of work that they contain,
> that will make it easier in the long term to get to a good
> well-thought out solution?

Stepping back from the technical issues raised in my previous response 
here are some more immediate things to do:

1. (social issue) Agree on an open license

2. (social/tech issue) Start releasing the work both source 
(word/openoffice/text ...) and compiled (pdf) -- this already seems to 
be in progress though one might want to have version numbers to identify 
newer and older stages of work

3. Move away from .doc as a storage format to something open such as 
open document format (odf) which is used by open office (see above)

4. Try and produce simple and clear use cases as to what one would 
/like/ to be able to do -- with particular focus on what is not possible 
using the present tools. These use cases should be 'valued' (given a 
number say between 1 and 10). This way we have a clear idea of what will 
deliver value to users.

No-one is going to alter their current way of working unless they can 
clearly see what the benefits are and the use-cases can help identify 
those benefits.

Examples of use-cases (put ultra-simply) might be:
   * allow the comparison of two versions of the same text
   * allow collaborative /decentralized/ annotation of a given text

Does seem more practical and more useful?

Regards,

Rufus