Hello Serge,

> I propose that the mentioned need to associate a tool version number to
> a specific element in the document, even if the element is the entire
> text, is similar to the need to bind a responsibility to a particular
> change in the text. And this is already provided.

I completly agree that it is a good starting point and that, generally
speaking, Certainty/Responsibility is the closest mechanism to the
question of linking application-specific information to annotation.

An "app" attribute may be somewhat similar to the "resp" attribute, but
pointing to an application in appInfo desclared in the document header,
rather than a "person":

      <valDesc>a pointer to one of the identifiers declared in the
      document header, associated with a person asserted as
      responsible for some aspect of the text's creation,
      transcription, editing, or encoding</valDesc>

in attDef/@ident="resp"

> Section B is relative to the various parameters that could be needed
> to process the text by a particular tool.
> For example, in the analysis tools we build here, we would need to encode
> the following parameters :
> - specific tokenization rules, including character classes definitions and
> particular element roles definition : elements composing or delimiting
> words (num, abbr, w...), reading choosing rules (choice, corr, sic...),
> etc. ;
> - specific text processing parameters :
> -- like "not to be processed"  rule definitions : focusing on elements
> like gap, note... ;
> -- like "specific indexes" rule definitions : focusing on elements like
> head, foreign, hi... ;
> - application specific parameters :
> -- like text/corpus partitionning definitions, section referencing policy,
> etc.

Why your application could not record, in every
encodingDesc/tagsDecl/tagUsage element, a fs of your own, containing an
REFID toward an ID identifing your application, and where your application
may record the information it need?

> As that kind of CONTEXTUAL information about a text or a corpus
> is something new in the TEI Header, I would suggest to create a new
> child element named *processingDesc* sibling of fileDesc, encodingDesc,
> profileDesc and revisionDesc.

Creating a new element for recording information already defined in
existing part of the header look a bad idea for me (up to now :).

> Please note that *any* software should be able to store information
> there. For example, even general editors could store informations like :
> - printed by
> - last print date
> - editing duration
> - total editing duration
> - document model used
> - autoload on/off
> - etc.
> as can be seen in the metadata part of the ODT file format for example.

I think that every comparison with an existing format is dangerous because
the TEI is not associated with one application (or at least one
well-defined class of application), as the ODT format is. Moreover, I'm
not sure that a word-processor format goal is that closed to the TEI
format goal.


Sylvain Loiseau
[log in to unmask]

On peut pratiquer objectivement, c'est-à-dire impartialement,
une recherche dont l'objet ne peut être conçu et construit
sans rapport à une qualification positive et négative, dont
l'objet n'est donc pas tant un fait qu'une valeur.

Canguilhem, /Le normal et le pathologique/, p. 157

Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre