Encodage des dates

La date d'un acte (ou d'une dépêche) est composée idéalement de deux éléments : une date de temps (en nouveau style) et une date de lieu. Ces deux informations sont inégalement disponibles selon les documents et peuvent se trouver sous des formats variés.

L'éditeur s'efforcera donc de fournir les informations de datation les plus précises disponibles (par examen interne de l'acte ou par recours à des sources externes) dans l'ordre suivant: millésime, quantième et mois et encodera séparément les dates de temps et de lieu.

<docDate>

<placeName>Saint-Germain-en-Laye</placeName>

<date when="1570-08-31">31 août 1570</date>

</docDate>

D'autres usages, moins normalisés, ont parfois cours dans les éditions anciennes, en particulier au XIX^e siècle. Le présent schéma propose également des solutions pour encoder les dates telles qu'elles peuvent être présentées dans ces éditions: « Donné le ... à ... ». En cas de reprise d'une édition ancienne, le balisage doit normaliser certaines usages de ponctuation

• Retirer les parenthèses :  (  1er janvier ou 25 mars 1190 - fin 1190  ) 
• Conserver les crochets (dates reconstituées) : [Vers 1176]

Le reste de la ponctuation peut être conservée et insérée entre les différents éléments utilisés.

<docDate>à <placeName>Senlis</placeName>. <date when="0866-01-16">16 janvier 866</date></docDate>

Date de temps avec attributs de normalisation (jour, mois, année, intervalles, approximations)

<dc:date>, 1 ou 2, à inférer des combinaisons @when, @notBefore, @notAfter, et @scope.

Une normalisation de la date de temps proposée par le diplomatiste est indispensable : elle permet d'en faciliter l'exploitation lors des requêtes sur le corpus concerné (par exemple pour visualiser la répartition d'un mot selon les siècles ou pour définir des sous-ensembles chronologiques).

Cette normalisation portera à la fois sur les dates fournies par les actes et sur les dates reconstituées. Toutefois, si elle est aisée lorsque la date est complète, elle peut parfois s'avérer plus délicate pour les dates reconstituées partiellement ou encore en raison de problèmes de conversion des styles anciens de datation.

De fait, l'éditeur peut offrir à son lecteur maintes nuances pour décrire une date de temps. Cette finesse est destinée à la lecture humaine, pas à la machine. L'encodage XML doit éviter de perdre de l'information, tout en visant des requêtes efficaces de type base de données.

Les dates sont normalisées selon le patron ISO AAAA-MM-JJ, en arrêtant la précision selon ce qui est possible, à l'année, au mois ou au jour près. La mention de l'année est obligatoirement requise : AAAA(-MM(-JJ)?)?.

<date when="0950">950</date>

<date when="1048-04-17">1048, 17 avril</date>

Les formats de type --01-01 sont donc à proscrire : ils servent normalement à signifier des dates récurrentes (tous les 1^er janvier). Pour une date dont on ne connait pas l'année mais seulement le jour, il vaut mieux ne rien écrire, car les applications ne pourront pas exploiter utilement l'information. L'utilisation de points d'interrogation, sur le modèle 12??, est également à proscrire : non seulement elle ne permet pas de fournir un intervalle précis, mais elle compliquerait les traitements. On encouragera plutôt l'éditeur électronique à déterminer un intervalle chronologique précis et explicite.

Problèmes de conversion de style

Le soin des éditeurs pour convertir les dates en nouveau style (style du 1^er janvier) est variable : il n'est donc pas toujours possible de se fier aux dates inscrites par l'éditeur. Aussi on se gardera d'exprimer une date sous le format @when="AAAA-MM-JJ" tant qu'il reste un doute sur le style de datation. Afin d'alerter les applications qu'une décision éditoriale n'a pas été prise, on adoptera un encodage sous forme d'un intervalle (voir ci-dessous).

Intervalles

Il est fréquent qu'une date de temps soit formulée sous forme d'un intervalle en raison d'un problème de conversion de style ou d'une reconstitution de la date grâce des sources extérieures. Par ailleurs dans le cas d'une date réduite au seul millésime, cet intervalle s'exprimera à partir d'une année-pivot (pas avant ni après cette même année).

<date notBefore="1123-03-26" notAfter="1123-08-03">26 Mars-3 Août 1123</date>

<date notBefore="1090" notAfter="1096">Entre 1090 et 1096</date>

<date notBefore="1148-09" notAfter="1150-09">Automne 1148 — Été 1150</date>

<date notBefore="1138" notAfter="1138">1138</date>

Les alternatives entre plusieurs dates (1330 ou 1331, 3 avril ; 1330, 25 mars ou 1331, 3 avril) seront également traitées sous forme d'un intervalle contenant l'ensemble des dates possibles.

<date notBefore="1211-01-01" notAfter="1212-03-25">1er janvier ou 3 avril 1211 - 1er janvier ou 25 mars 1212</date>

<date notBefore="1171-01-25" notAfter="1181-01-25">Frascati, 25 janvier, 1171-1181</date>

L'intervalle proposé par l'historien peut également être extrêmement imprécis, faute de renseignements suffisants. Dans ce cas, il faut envisager l'intervalle le plus large possible.

<date notBefore="1100" notAfter="1150">Début du xiie siècle</date>

<date notBefore="1150" notAfter="1200">Fin xiie siècle</date>

<date notBefore="1100" notAfter="1200">xiie siècle</date>

Dates approximatives (vers, circa)

L'historien tient parfois à signaler qu'une date est proche, mais qu'elle ne peut être précisée plus. L'attribut @scope est utilisé pour indiquer ce doute. Cet attribut peut être employé pour une date réduite au seul millésime ou non.

L'étendue de la période définie par cette approximation n'est pas à préciser au moment de l'édition du document : si elle pouvait être déterminée avec certitude, il conviendrait de recourir à un intervalle sous la forme @notAfter, @notBefore. Ce sera plutôt aux moteurs de recherche et aux applications de diffusion de déterminer l'interprétation à faire de cete date approximative, selon le corpus et l'usage que l'on veut en donner (par exemple, considérer que les dates approximatives doivent être traitées comme un intervalle de 5 ans de part et d'autre de la date fournie).

<date when="1220" scope="circa">Circa 1220</date>

<date when="1196-09-16" scope="circa">Avant et après le 16 septembre 1196</date>

<date when="1148-03-25" scope="circa">25 Mars, vers 1148</date>

Terminus a quo, terminus ante quem

Lors de la reconstitution d'une date, il n'est pas toujours possible de définir un intervalle de dates précis : un seul terminus peut être connu.

Comme pour les dates approximatives, c'est aux moteurs de recherche ou à l'application de diffusion de déterminer automatiquement, selon les besoins, le terminus manquant : même si certaines formules laissent parfois penser que l'écart peut être de moins d'un an, en l'absence de toute recherche complémentaire, on ne saurait fixer un terminus particulier dans ces cas.

<date notAfter="1206">Ante a. 1206</date>

<date notBefore="1181-06">Post. jun. 1181</date>

<date notBefore="1207-04-22">1207, peu après le 22 avril</date>

<date notBefore="1122-09-11">Peu après le 11 septembre 1122</date>

Sans date ?

L'historien souhaitera évidemment laisser le moins possible de documents non datés.

Lors de l'encodage d'une édition imprimée, il arrive parfois que la balisage automatique ne retrouve pas une date. C'est très rarement un acte non daté : tantôt on peut par exemple lire Même date, tantôt la date est mentionnée en note. On conseillera d'ajouter cette information de manière invisible (sans modifier le texte encodé), afin qu'elle puisse renseigner l'application, par exemple avec un élément vide comme <date when="1202"/>. Lorsque l'acte ne peut réellement être daté, même approximativement, aucune information ne doit être indiquée, même un élément <date> vide. L'interprétation de l'absence est laissée à l'application de publication.

Date de lieu sous sa forme moderne si elle a pu être identifiée ou à défaut sous sa forme originelle. Si l'acte ne donne pas de date de lieu, on ne cherchera pas à la restituer, à moins que l'omission ne présente un caractère exceptionnel, la date de lieu devant alors être insérée entre crochets.

La date de lieu, tout comme la date de temps, peut être normalisée afin de faciliter l'exploitation d'un corpus en fonction du lieu d'émission des actes à l'aide d'un attribut @key.

<placeName key="Valence-Fr">Valence</placeName>