Print

Print


On Tue, 2006-30-05 at 11:09 -0700, Martin Holmes wrote:
> Hi Dan,
> 
> Dan O'Donnell wrote:
<snip and summarise>
Re: explanation for putting the last saved date in. Your explanation
certainly makes practical sense and I was being a purist.

As more tools are developed perhaps this needs serious thought, however,
as I suspect this kind of information will become crucial (especially
given the kind of havoc Joe's Universal TEI editor seemed to cause in
your fantasy example). Early on in this discussion, people argued
against putting tools in the revision statement because there was no
intellectual responsibility involved. But the more sophisticated the
tool the more important the revision record, I'd think.

Certainly your solution is a good interim one. But ultimately, I think
we are going to have to think more about how tools are like and not like
people.

<more snip>

> > 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. 

My mistake, I meant langusage:

<langusage>
    <language id="ENG">English, Present Day (Canadian Standard Spelling)</language>
</langusage>

This is a model for what I think you are doing because it provides
metadata about something that can be referred to elsewhere (I suppose it
might be a specialised kind of FS). Of course creationApp is not quite
the same thing, because you presumably wouldn't use it in the way you
used to use tei:@lang (i.e. marking individual elements as made by a
specific tool in the main text (though I suppose you could). But it
would, for example, allow you to identify those tagsDecl elements imt is
adding and removing to the header (or to harp on a point, information
about revisions introduced by the tool ;-) ) in the same way in P4 you
could indicate that a specific element contained text in Old High
German, e.g.:

<tagsDecl tool="imt" ... >

Obviously in your case, you are adding more children, but the principle
seems the same to me.

> 
> Cheers,
> Martin
> 
> > -d
> > 
> > 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?
> >>
> >> Cheers,
> >> Martin
> >>
> >> 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.
> >>>
> >>> -d
> >>>
> >>> 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).
> >>>>
> >>>> Cheers,
> >>>> Martin
> >>>>
> >>>> 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 
> >>>>>> possible.)
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Martin
> 
-- 
Daniel Paul O'Donnell
Associate Professor and Chair of English
Director, Digital Medievalist Project
<http://www.digitalmedievalist.org/>
University of Lethbridge
Lethbridge AB T1K 3M4
Canada

Vox +1 403 329-2377
Fax +1 403 382-7191

:@caedmon/ubuntu