Cette documentation concerne IBM Watson® Knowledge Studio on IBM Cloud®. Pour consulter la documentation de la version précédente de Knowledge Studio on IBM Marketplace, cliquez sur ce lien.
Configuration d'annotation
Les documents doivent être annotés par des utilisateurs ayant une connaissance du secteur concerné et de sa langue.
Effectuez les tâches suivantes pour permettre aux annotateurs humains d'accéder à l'espace de travail :
-
Invitez des spécialistes du domaine à l'instance Knowledge Studio que vous utilisez.
-
Associez des annotateurs humains au(x) jeu(x) d'annotations que vous souhaitez leur confier.
-
Créez une tâche affectant ces annotateurs humains à l'annotation des documents de ces jeux.
Ce n'est qu'à compter du moment où vous leur affectez explicitement une tâche d'annotation que les annotateurs humains peuvent voir votre espace de travail lorsqu'ils se connectent à Knowledge Studio.
Vos utilisateurs (les annotateurs humains) devront être familiarisés avec le guide d'annotation de documents, qui contient des informations détaillées sur la façon d'annoter correctement les documents.
Cycle de vie du modèle
Le modèle que vous créez avec Knowledge Studio est un composant logiciel que vous pouvez connecter à un pipeline de traitement automatique du langage naturel (NLP, de l'anglais 'natural language processing').
Avec Knowledge Studio, vous pouvez créer, évaluer et améliorer des modèles s'appliquant à de nouveaux domaines. Un modèle ajoute des annotations (métadonnées) au texte qui apparaît dans un contenu en langage naturel. Les annotations, qui identifient les mentions d'entités d'intérêt dans votre domaine, les relations entre elles et les mentions qui constituent des coréférences à une même entité, peuvent être utilisées par des applications pour automatiser l'analyse de textes et leur traitement. Les utilisateurs de ces applications profitent de ce niveau d'analyse et peuvent extraire du sens, découvrir des perspectives et obtenir des réponses dans un contexte de langage naturel.
La création d'un modèle est un processus itératif en plusieurs étapes qui comprend plusieurs phases : organisation des connaissances, génération des données de référence, développement du modèle, évaluation du modèle et déploiement en environnement d'exécution.
Adaptation au domaine de bout en bout
Le diagramme suivant schématise les interactions entre ces cinq phases du développement d'un modèle et les activités qui y sont généralement effectuées.
Figure 2. Récapitulatif des cinq étapes du développement d'un modèle et des activités qui se produisent à chaque étape.
Organisation des connaissances
Egalement appelée 'curation', cette phase est extérieure à Knowledge Studio. Elle consiste à sélectionner, collecter, conserver et tenir à jour les contenus pertinents dans un domaine spécifique. Elle transforme les données en information fiable et en connaissances.
Génération des données de référence
Cette phase consiste à utiliser les outils de Knowledge Studio et diverses bonnes pratiques pour produire une collection de données validées qui puissent être utilisées pour adapter une solution Watson à un domaine particulier. L'exactitude de ces données validées, que l'on appelle données de référence ou documents étalon-or, est essentielle, car toute inexactitude sera corrélée à une incertitude dans les applications qui s'appuient dessus.
Une partie essentielle de l'enseignement d'un nouveau domaine à Watson implique de lui fournir la connaissance des entités d'intérêt dans les contenus de ce domaine, des relations entre ces entités et de la manière dont elles sont coréférencées. Le recueil de cette connaissance comprend les activités suivantes :
-
Impliquer les experts du domaine dans la création des ressources suivantes, ou identifier des ressources existantes pouvant être réutilisées ou modifiées en fonction du domaine :
- Directives et exemples d'annotation pour aider les annotateurs humains à apprendre à annoter les mots et les passages dans les contenus relatifs au domaine.
- Système de types définissant les types (objets) et les caractéristiques (classes de données) spécifiques du domaine, qui peuvent être découverts par l'analyse du texte des documents relatifs au domaine. C'est le système de types qui détermine les types d'annotations qu'un annotateur humain peut ajouter aux documents.
- Dictionnaires de termes devant être traités comme des termes équivalents dans les contenus relatifs à votre domaine.
-
Créer un corpus de documents représentatifs des contenus relatifs à votre domaine.
-
Pré-annoter des documents sur la base de dictionnaires que vous ajoutez à un espace de travail Knowledge Studio. Après avoir créé un modèle d'apprentissage automatique, vous pouvez utiliser celui-ci pour pré-annoter de nouveaux documents que vous ajoutez au corpus. La pré-annotation est un processus d'annotation machine d'un document dans toute la mesure du possible avant qu'un modèle d'apprentissage automatique ne soit disponible pour le faire. Elle réduit le travail d'annotation humaine en remplaçant une part de celui-ci par la simple vérification de l'exactitude des annotations ajoutées par la machine.
-
Division des documents en plusieurs petits jeux de documents distribués à différents annotateurs humains, qui utilisent ensuite l'outil éditeur de données de référence d'IBM Watson® Knowledge Studio pour ajouter manuellement des annotations aux jeux de documents qui leur sont confiés.
-
Comparer les résultats de l'annotation humaine et résoudre les conflits. Un arbitrage est nécessaire à ce stade pour garantir l'exactitude et la cohérence des documents annotés avant qu'ils ne soient promus au rang de données de référence et ne puissent servir à entraîner et tester un modèle d'apprentissage automatique.
Développement du modèle
Cette phase consiste à utiliser les outils de Knowledge Studio pour créer un modèle. Après l'établissement des données de référence, les résultats de l'annotation humaine peuvent servir à entraîner un algorithme en vue d'ajouter automatiquement des annotations à de grandes collections de documents qui peuvent comprendre des millions de documents.
Evaluation du modèle
Cette phase consiste à utiliser les outils de Knowledge Studio pour affiner le modèle et améliorer ses performances. Les résultats générés par le modèle sont évalués par rapport à un jeu de test constitué de documents de référence. Une analyse de l'exactitude identifie les causes d'erreurs d'annotation. Une analyse de la marge de progression (headroom) vous aide à déterminer quelles erreurs nécessitent une attention particulière et où les améliorations du modèle peuvent avoir le plus grand impact. Des ajustements peuvent être effectués à répétition pour améliorer les performances jusqu'à l'obtention d'un niveau d'exactitude satisfaisant.
Déploiement de modèle
Cette phase consiste à exporter les composants qui permettent au modèle de fonctionner dans un environnement d'exécution d'apprentissage automatique et de rendre le modèle accessible aux autres applications cognitives Watson. Par exemple, vous pouvez déployer le modèle d'apprentissage automatique pour son utilisation par IBM Watson® Natural Language Understanding ou IBM Watson® Discovery ou l'exporter pour qu'il puisse être exploité dans IBM Watson Explorer.
Créer une tâche d'annotation
Avant que des annotateurs humains ne puissent commencer à ajouter des annotations aux documents, le gestionnaire des processus d'annotation doit créer une tâche d'annotation.
Les administrateurs et les chefs de projet peuvent annoter directement les jeux de documents de référence. Voir Annotation de jeux de documents directement.
A propos de cette tâche
La tâche d'annotation indique quels documents doivent être annotés. Pour comparer les performances des annotateurs humains et voir avec quelle cohérence ils appliquent les directives d'annotation, vous devez en inclure au moins deux dans la tâche. Il faut aussi qu'un certain pourcentage des documents apparaissent dans tous les jeux d'annotations que vous ajoutez à la tâche (vous spécifiez le pourcentage de chevauchement au moment de créer les jeux d'annotations).
Important
- Une tâche d'annotation est temporaire. Son rôle est de permettre aux annotateurs humains d'annoter du texte dans des espaces isolés. Elle garantit aussi que seules des annotations approuvées sont promues au rang de données de référence.
- Un jeu d'annotations ne peut être actif que dans une seule tâche à la fois. Si un jeu d'annotations est actif dans une tâche, pour pouvoir l'ajouter à une autre tâche, vous devez d'abord supprimer la tâche dans laquelle il est actif.
- Si vous supprimez le compte d'utilisateur d'un annotateur humain, cela affecte aussi les annotations de celui-ci. Plus précisément, cela supprime toutes les annotations qu'il a ajoutées aux documents qui lui ont été affectés mais qui n'ont pas encore été promues au rang de données de référence.
- En cas de changements dans le système de types ou les réglages de l'éditeur de données de référence après la création d'une tâche d'annotation humaine, vous devez décider s'il faut ou non propager ces changements à la tâche. Les changements opérés dans le système de types peuvent affecter les annotations ; cela veut dire que les annotateurs humains doivent peut-être revoir et mettre à jour les annotations qu'ils ont ajoutées à leurs documents.
- Si des changements sont apportés aux dictionnaires, ils ne sont pas reflétés dans la tâche d'annotation en cours. Pour appliquer les changements subis par les ressources aux données de référence, vous devez créer une nouvelle tâche d'annotation.
- Vous pouvez avoir jusqu'à 256 tâches d'annotation par espace de travail.
Procédure
Pour créer une tâche d'annotation :
-
Connectez-vous en tant qu'administrateur Knowledge Studio et sélectionnez votre espace de travail.
-
Sélectionnez la page Modèle d'apprentissage automatique > Annotations, puis cliquez sur l'onglet Tâches d'annotation.
-
Cliquez sur Ajouter une tâche.
-
Indiquez un nom de tâche descriptif et sélectionnez la date à laquelle la tâche doit être terminée.
-
Si aucun jeu d'annotations n'est disponible, cliquez sur Créer des jeux d'annotations.
-
Pour le jeu de base, sélectionnez le jeu de documents ou le jeu d'annotations que vous voulez diviser en jeux d'annotations.
-
Pour la valeur de chevauchement, spécifiez le pourcentage de documents que vous voulez inclure dans chaque jeu d'annotations. Les scores de convergence entre annotateurs ne peuvent être calculés qu'à partir du moment où au moins deux annotateurs humains annotent les mêmes documents. Par exemple, si vous spécifiez une valeur de chevauchement de 20 % pour un corpus de 30 documents et que vous divisez celui-ci en trois jeux de documents, 6 documents (soit 20 %) seront annotés par tous les annotateurs humains. Les 24 documents restants seront répartis entre les trois annotateurs humains (8 chacun). Chaque annotateur recevra donc 14 documents à annoter (6 + 8).
Un jeu d'annotations que vous prévoyez d'utiliser pour entraîner un modèle d'apprentissage automatique doit contenir au moins 10 documents annotés.
-
Sélectionnez un nom d'utilisateur dans la liste des annotateurs humains.
-
Donnez un nom au jeu d'annotations.
Vous pouvez choisir, pour le jeu d'annotations, un nom qui identifie l'annotateur humain auquel il sera confié. Cela vous permettra d'évaluer le travail de cet annotateur au fil des progrès réalisés dans l'espace de travail. Vous ne pouvez pas changer le nom d'un jeu d'annotations une fois celui-ci créé.
La taille maximale du nom du jeu d'annotation est de 256 caractères.
-
Cliquez sur Générer.
-
-
La liste des jeux d'annotations disponibles s'affiche sous Jeux disponibles, avec les noms des annotateurs humains qui leur sont affectés. Pour ajouter des jeux disponibles à votre tâche d'annotation, cliquez sur Ajouter à la tâche.
-
Assurez-vous que tous les jeux d'annotations que vous voulez inclure dans la tâche s'affichent sous Jeux sélectionnés, puis cliquez sur Sauvegarder pour créer la tâche.
Etape suivante
Une fois la tâche créée, vous pouvez revenir à l'onglet Tâches d'annotation sur la page Modèle d'apprentissage automatique > Annotations pour afficher la progression de chaque annotateur humain. Vous pouvez aussi effectuer les tâches suivantes :
- Pour résoudre les éventuels conflits d'annotations, vérifiez les documents approuvés qui constituent un chevauchement entre les jeux d'annotations.
- Ouvrez une tâche pour y ajouter des jeux d'annotations. Assurez-vous que les jeux d'annotations que vous ajoutez incluent les documents qui se chevauchent avec des documents des jeux d'annotations d'origine.
A partir de l'onglet Paramètres de la navigation principale, vous pouvez spécifier les informations suivantes :
- Spécifier vos préférences d'utilisation des couleurs et des raccourcis clavier dans l'éditeur de données de référence.
- Fixer un seuil de convergence entre annotateurs, puis ouvrir une tâche pour voir avec quelle cohérence plusieurs annotateurs humains ont annoté les mêmes documents.
- Spécifiez une URL pour rendre vos directives d'annotation accessibles à partir de l'éditeur de données de référence.
Configurer les préférences de l'éditeur de données de référence
Un chef de projet peut spécifier ses préférences d'utilisation des couleurs et des raccourcis clavier dans l'éditeur de données de référence.
Procédure
Pour spécifier les préférences visuelles pour le travail dans l'éditeur de données de référence :
-
Connectez-vous en tant qu'administrateur Knowledge Studio et sélectionnez votre espace de travail.
-
Dans la navigation gauche, sélectionnez Paramètres > Paramètres d'annotation de document.
-
Sélectionnez l'onglet Types d'entités ou Types de relations.
-
Sélectionnez le type d'entité ou le type de relation que vous voulez changer, puis cliquez sur Editer les raccourcis clavier et les couleurs. Pour chaque type, vous pouvez définir :
- un accourci clavier, ce qui signifie qu'un utilisateur peut entrer
<key>pour appliquer l'étiquette de type au texte surligné. Par exemple, si vous définissezocomme raccourci clavier pourORGANIZATION, un utilisateur peut sélectionner du texte, puis appuyer sur la toucheopour appliquer le type d'entitéORGANIZATIONau texte surligné. Si vous attribuez une lettre majuscule, vous devez appuyer surShift+<key>. - Une couleur de texte. Veillez à choisir une couleur suffisamment contrastée par rapport à la couleur d'arrière-plan afin que le texte reste bien visible une fois étiqueté.
- Une couleur d'arrière-plan. C'est la couleur de l'étiquette qui est appliquée à l'entité une fois que vous l'avez annotée.
Lorsqu'ils annotent des documents, les annotateurs humains peuvent utiliser les raccourcis clavier pour ajouter rapidement des annotations. Les couleurs d'étiquette et de texte aident aussi les annotateurs à reconnaître instantanément les types une fois les annotations ajoutées à un document.
- S'il y a des types d'entités ou de relations que vous ne voulez pas voir affecter aux mentions par les annotateurs humains, vous pouvez les masquer de l'éditeur de données de référence. La liste des types disponibles que les utilisateurs verront sera ainsi plus courte. Pour ce faire, décochez la case Actif de chaque type concerné.
Lorsque vous choisissez de nouveaux raccourcis clavier et de nouvelles couleurs, vous pouvez prévisualiser vos changements.
- un accourci clavier, ce qui signifie qu'un utilisateur peut entrer
-
Vous pouvez aussi changer la couleur de sélection du texte. Il s'agit de la couleur de la bordure affichée autour du texte une fois celui-ci sélectionné par l'annotateur humain. Par défaut, il s'agit du bleu clair, mais vous pouvez en changer sous l'onglet Mise en évidence de la sélection pour faciliter l'identification des limites du texte sélectionné.
Fixer le seuil de convergence entre annotateurs
Pour vous aider à décider si un jeu de documents doit être accepté ou refusé, vous pouvez spécifier un seuil de convergence entre annotateurs (IAA, de l'anglais inter-annotator agreement). Cela permet de déterminer où se situe la convergence entre annotateurs par rapport au score de convergence entre annotateurs calculé par le système.
A propos de cette tâche
Pour comparer comment les annotateurs humains ont annoté les mêmes documents, spécifiez un seuil d'évaluation. Si les annotations effectuées par un annotateur humain diffèrent de celles d'un autre annotateur humain à un point tel qu'il en résulte un mauvais score, on peut en déduire que les deux annotateurs ne sont pas d'accord. Ce désaccord doit alors être investigué et résolu.
Procédure
Pour fixer le seuil de convergence entre annotateurs :
- Connectez-vous en tant qu'administrateur Knowledge Studio et sélectionnez votre espace de travail.
- Sélectionnez l'onglet Paramètres > Paramètres IAA.
- Spécifiez une valeur entre 0 et 1, telle que
.5ou.8, puis cliquez sur Sauvegarder.
Connecter l'éditeur aux directives d'annotation
Une fois que vous avez créé des directives d'annotation pour votre projet, vous pouvez configurer Knowledge Studio pour qu'il s'y connecte. De cette manière, s'ils ont besoin d'aide pour choisir l'annotation correcte à appliquer, les annotateurs humains pourront consulter ces directives pendant qu'ils annotent des documents. Les administrateurs pourront aussi s'y référer s'ils ont besoin d'aide lors de la résolution des conflits dans les documents chevauchants.
Procédure
Pour connecter l'éditeur de données de référence et l'outil d'arbitrage à vos directives d'annotation :
- Connectez-vous en tant qu'administrateur Knowledge Studio et sélectionnez votre espace de travail.
- Sélectionnez l'onglet Paramètres > Directives d'annotation.
- Spécifiez l'URL de l'endroit où sont hébergées vos directives.
- Cliquez sur Sauvegarder. Le système connecte l'éditeur de données de référence et l'outil d'arbitrage à vos directives d'annotation. Il est possible que les annotateurs humains et les administrateurs de l'espace de travail soient autorisés à mettre à jour vos directives d'annotation après les avoir ouvertes, par exemple, pour ajouter des clarifications et des exemples. Cela dépend si vous avez prévu ou non de leur donner des droits d'accès lorsque vous avez créé les directives.
Directives d'annotation
Il n'existe pas de format imposé pour l'écriture des directives, mais il est important qu'elles incluent des exemples détaillés. Les annotateurs humains ont besoin de comprendre quel type d'entité appliquer à une mention compte tenu du contexte et de savoir quels types de relations sont valides pour une paire particulière de mentions. Les exemples tirés des contenus relatifs à votre domaine sont souvent le meilleur moyen de faire connaître les bons choix d'annotations.
Les directives d'annotation ne sont pas statiques. A mesure que votre projet évolue, vous découvrirez certainement des cas de mentions et de relations qui ne sont pas strictement reflétés dans vos directives. Et vous découvrirez probablement des divergences entre les multiples annotateurs humains qui interprètent différemment vos consignes. En mettant à jour vos directives dès que de telles situations se présentent, vous contribuerez à améliorer l'exactitude et l'uniformité des annotations au fil du temps.
Avant que des documents ne soient considérés comme données de référence, tout conflit sur la façon dont différents annotateurs humains ont annoté les mêmes documents doit être résolu. L'un des principaux moyens de résoudre les conflits est de discuter de ce qui a causé la confusion, aidant ainsi les annotateurs humains à apprendre de leurs erreurs. Améliorer et clarifier les directives aident à minimiser les conflits et contribuent à ce que des documents annotés avec exactitude et uniformité soient promus au rang de données de référence.
Pour gérer au mieux vos directives, vous pouvez peut-être les décomposer en plusieurs parties telles que des consignes d'annotation des entités, des consignes d'annotation des relations et une partie consacrée à l'annotation des façons dont les mentions peuvent être coréférencées. Les changements que vous apportez dans un domaine doivent être évalués et coordonnés avec les changements que vous apportez dans un autre domaine. Par exemple, si vous ajoutez un type d'entité à votre système de types, revoyez les consignes d'annotation des types de relations et spécifiez de quelle manière le nouveau type d'entité peut être relié à d'autres types d'entités.
Exemple de directives d'annotation
Pour que les annotateurs humains parviennent à un bon niveau de cohésion dans leur façon d'annoter les textes, il faut, dans la plupart des cas, des consignes d'annotation très détaillées et avec beaucoup d'exemples.
L'exemple présenté ici est un guide simple qui a été créé pour un petit domaine dont les contenus sont constitués de rapports d'accidents de la circulation.
Objectifs de la tâche
- En tant que membre du projet, se familiariser avec le processus itératif d'annotation manuelle et l'affinage du modèle d'apprentissage automatique.
- Annoter des documents du secteur de l'automobile avec l'éditeur de données de référence et utiliser les annotations résultantes pour entraîner un modèle d'apprentissage automatique. Annoter les types d'entités et les types de relations et coréférencer les entités selon nécessité.
Notations utilisées dans le guide
-
Les crochets [ ] indiquent l'étendue de l'annotation lorsque le texte cité n'est pas annoté dans son intégralité.
Incluez les négations nécessaires, par exemple
[no injuries]ACCIDENT_OUTCOME. Le système de types n'utilise pas de classe d'entité pour représenter la négation.
Types d'entité
Le système de types n'utilise pas de sous-types ou rôles d'entités ni de types de mentions ou de classes.
| Types d'entité | Instructions | Exemples |
|---|---|---|
| ACCIDENT_OUTCOME | Conséquence d'un accident. S'applique à la fois aux humains (par exemple, décès) et aux véhicules (par exemple, dommages matériels). Peut inclure "remorqué" et "déclenchement des airbags" comme indicateurs de la gravité des dommages matériels, et "transporté | |
| à l'hôpital" (mais pas 'à la morgue') comme indicateurs de la gravité des blessures. Peut inclure la négation. | "[accident]", "[blessure]", "[perte totale] subie", "[aucune blessure]", "[remorqué] en raison de [dommages invalidants]", [non remorqué], "l'airbag ne s'est [pas déployé]" (l'airbag lui-même doit être PART_OF_CAR, lié par sufferedFrom à cet ACCIDENT_OUTCOME), et indications de gravité. | |
| Condition | Conditions météorologiques ou routières, ou état de la chaussée ; | |
| un aspect de la scène qui pourrait influer sur la probabilité d'un accident et qui pourrait changer d'un jour à l'autre, mais qui ne concerne pas le véhicule | ||
| ou le conducteur. Peut être une erreur du conducteur ou une défaillance mécanique, et |
||
| doit apparaître problématique. Doit exclure STRUCTURE. | "sec", "pluvieux", "construction", "trafic intense", "lumière du jour", mais pas "herbeux" ou "intoxiqué". "pneu crevé", "surcorrection" (comme dans la direction), "endormi", "intoxiqué", "[n'a pas réussi à négocier]CONDITION un [virage]STRUCTURE", "[a quitté] la voie" ou l'accotement, mais pas "tentative de dépassement" à moins que cette phrase ne soit accompagnée de "sans assez de place" ou quelque chose de similaire, ni "sortie de route", qui est un INCIDENT. |
|
| INCIDENT | Une mention d'une collision ou d'un mouvement du véhicule qui est clairement inadéquat et probablement destructeur, par exemple une sortie | |
| de route ou tout autre incident entraînant des dommages matériels, comme un incendie du véhicule. Vous |
||
| ne devez pas coréférencer des mouvements qui ne sont pas identiques, tels que "a heurté", "projection par l'arrière" et | ||
| "s'est immobilisé", même s'ils sont étroitement liés. Exclure la STRUCTURE de l'étendue; par exemple, "[s'est immobiliséINCIDENT] dans un [fosséSTRUCTURE] " ou "[est resté en contactINCIDENT] avec la [glissière de sécuritéSTRUCTURE] ". |
||
| MANUFACTURER | L'entreprise qui fabrique le véhicule | Toyota, Mazda, General Motors |
| MODEL | Modèle spécifique de véhicule de la marque. Excluez les termes superflus et autres indications de finition ou de motorisation telles | |
| que "LX" ou "SE" (par exemple, annotez seulement "Xterra" dans "Xterra | ||
| SE"). | Camry | |
| MODEL_YEAR | Année modèle ou millésime faisant partie du nom du véhicule (mention spécifique aux pays anglo-saxons, donnée plus rarement citée en France). | 99, 2001 |
| PART_OF_CAR | Partie ou pièce d'un véhicule, | |
| intérieure ou extérieure, qu'elle soit ou non impliquée spécifiquement dans l'accident. Excluez la liste des caractéristiques ou capacités de telles pièces. Incluez l'indication de l'endroit du véhicule où se situe la pièce ou, | ||
| lorsqu'il ne s'agit pas d'une pièce spécifique, de la partie du | ||
| véhicule (avant gauche, arrière droit, etc.) Peut être pluriel. Peut inclure une spécification de position dans le véhicule, telle que « [airbag conducteur] », « [porte RF] » (c'est-à-dire avant droite), « passager [RR] », « [airbags LF et RF] », « [dispositifs de retenue passifs/automatiques de première rangée] », « [système de sécurité] avec capacités EDR ». Incluez les embarcations remorquées, citernes, etc. excepté les semi-remorques, dont le millésime, le |
||
| modèle et le constructeur | ||
| sont distincts de ceux du véhicule tracteur. | Profil, plan avant, pneu, volant, airbag, etc. | |
| PERSON | Toute personne décrite ou citée dans un rapport d'accident | |
| (peut être un conducteur ou un passager/occupant d'un véhicule, un piéton ou un témoin). N'annotez pas les adjectifs, donc n'annotez pas « un [homme de 69 ans] a conduit », mais annotez « un [homme] de 69 ans a conduit ». Peut être au pluriel, par exemple, "[occupants] ArG et AvD". Exclut les personnes qui arrivent après l'incident. >En l'absence d'un type d'entité "animal", utilisez PERSON pour étiqueter les animaux sauvages impliqués dans des collisions ou qui en sont la cause, car leur capacité à se déplacer les rapproche davantage d'une PERSONNE que d'une STRUCTURE. Note: "airbag passager" est un élément de la voiture; il n'implique pas la présence d'une personne. |
||
| STRUCTURE | Elément de structure qui est sur une route, à proximité de celle-ci ou qui en fait partie. Incluez les adjectifs en rapport avec la chaussée ou la route qui sont susceptibles | |
| d'être pertinents dans la description de la configuration d'un accident. Omettez les autres adjectifs. | [route à deux voies, à double sens], [voie de gauche], [voie] en direction de l'est, [fossé] de 60 cm, [ligne de la voie de droite], [rampe de sortie], [poteau], [arbre], [talus] à forte pente | |
| VEHICLE | Toute référence à un véhicule autre que MODEL, MANUFACTURER et MODEL_YEAR. Peut être pluriel, auquel | |
| cas les coréférences sont très improbables. | "[camion]", "[voiture]", "[V1]"s" |
Types de relations
Le système de types utilise des types de relations, mais pas des classes de relations ni d'autres attributs des relations. La négation n'est pas codée par une classe de relation, mais plutôt par les extensités des mentions, par exemple, [aucun occupant]PERSON n'a été [hospitalisé]ACCIDENT_OUTCOME avec les deux mentions liées par le type de relation sufferedFrom.
| Types d'entités possibles pour la première mention | Type de relation | Types d'entités possibles pour la seconde mention |
|---|---|---|
| VEHICLE, MODEL, MANUFACTURER 2 | hasProperty | MANUFACTURER, MODEL, MODEL_YEAR |
| PERSON | occupantOf | VEHICLE, MODEL, MANUFACTURER, MODEL_YEAR 1, PART_OF_CAR, STRUCTURE |
| PERSON, PART_OF_CAR, STRUCTURE, VEHICLE, MODEL, MANUFACTURER, MODEL_YEAR 1 | sufferedFrom | ACCIDENT_OUTCOME |
| VEHICLE | driveUnder | CONDITION, ACCIDENT_CAUSE |
| PART_OF_CAR | locatedOn | VEHICLE, MODEL, MANUFACTURER, MODEL_YEAR 1 |
| ACCIDENT_OUTCOME | outcomeOf | INCIDENT |
| INCIDENT | causedBy | CONDITION, ACCIDENT_CAUSE (rappel : nécessite une preuve textuelle de la causalité) |
| INCIDENT | impactPoint | Personne, partie de voiture, structure, véhicule, fabricant, modèle ou année du modèle 1 touché ou impliqué dans l'accident. Le point d'impact de la structure ne comprend pas de simples indications sur le lieu d'un impact qui n'implique pas cette structure. Il ne s'applique donc pas à deux véhicules entrant en collision à une [intersection]STRUCTURE, mais s'applique à un véhicule heurtant un [talus]STRUCTURE. |
Notes du tableau
- Les notations VEHICLE, MODEL, MANUFACTURER et MODEL_YEAR font référence à une mention d'un véhicule. Les trois dernières sont respectivement pour les cas dans lesquels le texte contient quelque chose comme "l'Accord", "la Honda" ou, plus rarement, "la modèle 99". Ces quatre types d'entités sont cités par ordre de priorité. Par conséquent, dans "le conducteur de la Honda Accord modèle 99", la relation serait conducteur (en tant que PERSON) occupantOf Accord (en tant que MODEL), auquel cas Accord aurait la relation hasProperty avec Honda et modèle 99.
- MODEL et MANUFACTURER ne peuvent être le premier argument de la relation hasProperty que lorsqu'ils apparaissent comme des noms (références à un véhicule). MODEL peut avoir la relation hasProperty à MANUFACTURER et MODEL_YEAR, comme dans "la Honda Accord modèle 99". MANUFACTURER ne peut avoir une relation hasProperty qu'à MODEL_YEAR, comme dans "la Honda modèle 99".