Dan O'Donnell wrote:
> Actually, Martin, I think we're more or less on the same page.
> My initial point was simply that "last saved" is a description of a
> revision, and so belongs under revision description, whereas creationApp
> is supposed to be a record of tools used. So I see creationApp as being
> akin to langDesc (if that's what it was called) or characterDesc in P4
> (something that might offer a model, BTW). Adding a date to creationApp
> seems to me likely to imply that the actual date was in someway
> intellectually important. As a result, I can easily see how people might
> want to record multiple uses of the same tool for different purposes
> under creationApp, leading to the presentation of material that more
> properly belongs in revisionDesc. In otherwords, "last saved" if at all
> important, is really part and parcel of a revision (you wouldn't save if
> nothing was done), rather than an intrinsic feature of the apparatus.
> That people don't make good revisionDesc on the whole doesn't seem to me
> to be an argument for moving it here. It seems simple enough to require
> a date be placed in revisionDesc containing information about the tool
> (i.e. the ID referring to the right element in creationApp), the
> operator (the person intellectually responsible), and date and nature of
> the revision (even if this is just "saved").
Herein lies the problem, from my point of view: there's no way for the
app to insist on this, or to know who the user is or what they did.
There's also the issue that we're (I hope) encouraging users to edit the
revision desc manually and extensively; meanwhile, we're hoping that our
application save date will survive this editing intact, and in a format
which can be mechanically read. In addition, I'm a little concerned
about the application placing some data automatically into a region of
the file which we're hoping users will take responsibility for. There
are areas of the file which my application sees fit to control (the
image data, the annotations, the information about the colours, shapes
and categories of annotation, and putatively the creatorApp), and areas
which should I think be under the control of the user (all other areas
of the file, including the teiHeader, with the exceptions above). While
there is no way, and there should be no way, to prevent users from
editing any of the file data in any external editor, it would seem
sensible to keep at least a simple division in the application itself
between elements of the file which it controls, and areas which it
encourages the user to take responsibility for.
So, for example, in the Image Markup Tool you can view and edit the text
of the teiHeader as you like; however, when you do this, the category
information which is stored by the IMT in a special tagsDecl element
when you save the file is not shown. The application creates and adds
this information only when saving the file, and at that point, merges it
with the rest of the teiHeader. When opening a saved file, it reads that
element and then removes it from the header. That tagsDecl element, like
other elements which are the business of the application, is identified
by an xml:id attribute which associates it with the application
(imtAnnotationCategories, imtAnnotatedImage, etc.). This provides a
relatively clean separation between structured information which is
created by the application, and stored in places it knows about, and
freely-editable information which is the business of the user (such as
the rest of the teiHeader). That's why I worry about having the
application write data automatically to an area of the file which I
think users should be concerned to maintain for themselves (albeit many
may ignore it in the real world).
> However, while unhappy about it philosophically, I can see that
> recording the last date on which a tool was used in creationApp might be
> easier and that the date saved would be useful for debugging. So while
> the purist in me wants to see only information about the actual tools
> itself in creationApp, and information about actual dates and actions
> saved in revisionDesc, I'm not one to get in the way of progress, if
> that's what others want.
Me neither, but no-one else is telling us what they want at the moment.
Anyone else want to weigh in?
> I think the idea of a creationApp is an excellent idea. But like I said,
> I think the best model may be the old langDesc.
I've searched the Web and the tei site for this, and I can't find any
mention of an element called langDesc. I don't remember ever using it in
P4. Could you point me at a reference for it? The P5 gaiji model has
charDesc, but that seems to me completely unrelated to the type of
information we're discussing for creator applications. It contains a
couple of elements specific to character/glyph data, and the more
general desc element:
<desc>contains a brief description of the purpose and application for
an element, attribute, attribute value, class, or entity.</desc>
This has pretty unrestricted content (macro.paraContent). Doesn't it
serve our purposes better, when we're recording data which is heavily
constrained and intended to be mechanically readable, to use something
tighter than this?
> On Tue, 2006-30-05 at 09:42 -0700, Martin Holmes wrote:
>> I think we're at cross-purposes here: I'm not intending that the
>> application should add anything to the revision statement. I think the
>> revision statement should be entirely in the hands of the user, who can
>> edit it as they see fit, either inside or outside the application
>> itself. The application would simply add a single creatorApp tag, or if
>> one already exists for its appID, it should modify the existing one; and
>> the creatorApp tag should include a date when the file was last saved by
>> the application. I'm not sure how that differs from a "last used" date;
>> basically I'm assuming that whenever the application saves a file, it
>> will put the date and time of the save into that creatorApp/date tag. If
>> the same app is used repeatedly, the same tag would be overwritten each
>> time with a new date/time.
>> Or am I misunderstanding you?
>> Dan O'Donnell wrote:
>>> It's a minor point. Perhaps in that case having a lastused date rather
>>> than anything else? That still provides debugging information, but
>>> doesn't create the temptation to build a second revision statement if
>>> the same tool is being used repeatedly.
>>> On Tue, 2006-30-05 at 05:12 -0700, Martin Holmes wrote:
>>>> Hi there,
>>>> I take your point, but I think the application should be able to store
>>>> information it (and other applications) can use. A user may not bother
>>>> to add revision information; it may not be important from an
>>>> intellectual point of view when the app last saved the file, but it
>>>> could be important to the application if it's trying to disentangle
>>>> corruptions or conflicts. I think it's reasonable to privilege the last
>>>> usage because that was the last successful editing session (presumably).
>>>> Daniel O'Donnell wrote:
>>>>> On Mon, 2006-29-05 at 12:57 -0700, Martin Holmes wrote:
>>>>> Good enough. But then perhaps last saved doesn't belong here either?
>>>>> I.e. It sounds like this is a storage for information about machines
>>>>> rather than actions. Last saved would also be recoverable from the
>>>>> revision history (or the file date). And including it implies that the
>>>>> tool was used that once... or at least it privileges the last usage.
>>>>> Perhaps this is really like the old Language declarations.
>>>>>> My gut feeling is that this would be overkill. The app itself can only
>>>>>> know when it saved the file; it can't really know what the user's
>>>>>> purpose was in working on the file that day. The user does know that
>>>>>> info, and if it's important, it can go into the teiHeader in the usual
>>>>>> way as part of the revision description; in the IMT, you can edit the
>>>>>> teiHeader as text inside the program, and I think most tools would allow
>>>>>> this sort of thing. "Last saved date" is a mechanical thing, whereas
>>>>>> revision descriptions are intellectual content best left to humans. If
>>>>>> each app which worked on a file left its "last saved" date in its
>>>>>> creatorApp tag, an app such as IMT might be able to provide useful
>>>>>> diagnostic feedback in the event of (say) failure to open a file --
>>>>>> something like this:
>>>>>> "Since this file was last opened in the Image Markup Tool (25/05/06), it
>>>>>> has been edited using Joe's Universal TEI Editor (27/05/06), at which
>>>>>> time key data relating to annotation categories appears to have been
>>>>>> deleted. The Image Markup Tool is no longer able to open this file
>>>>>> normally. Would you like to attempt reconstruction of the missing data?"
>>>>>> (Not that my app has anything that clever in it at the moment ;-) But if
>>>>>> we had a standardized creatorApp module, that sort of thing would be
University of Victoria Humanities Computing and Media Centre
([log in to unmask])
Half-Baked Software, Inc.
([log in to unmask])
[log in to unmask]