[okfn-discuss] A question of history
Rufus Pollock
rufus.pollock at okfn.org
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
More information about the okfn-discuss
mailing list