Le format BCGCT (Base de Connaissances Graphes Conceptuels Textuelle) permet de représenter sous une forme conjuguant lisibilité et efficacité un support (ensemble partiellement ordonné des types de concepts, des types de relations, des types d'emboîtements, signatures des types de relation et relation de conformité) ainsi que des graphes conceptuels (connexes ou non connexes, simples ou emboîtés) et des règles.
Il est important de faire la distinction entre la grammaire du format BCGCT, et les fonctionnalités de la plate-forme CoGITaNT version 5 qui sont distinctes : CoGITaNT n'implémente pas la totalité du format. Pour une description complète du format BCGCT (sans les extensions récentes), se reporter à [Haemmerlé, 1995]. Il existe différentes variantes du format BCGCT correspondant aux différentes évolutions de la plate-forme CoGITo/CoGITaNT:
Un même fichier BCGCT ne concerne qu'un support. Il permet de définir le support en question et/ou des graphes construits sur ce support. La structure d'un fichier BCGCT est la suivante : le support est décrit, suivi de graphes (et/ou règles) définis sur ce support. Il est toutefois possible et souvent préférable de séparer le stockage du support du stockage des graphes. Dans ce cas, on préférera utiliser l'extension .bcs pour le support, .bcg pour les graphes et .bcr pour les règles.
Un fichier BCGCT à la variante 3 commence par une entête précisant le format de fichier et (éventuellement) l'application à l'origine du fichier. Si cet entête est absent, le fichier est interprété comme étant à la version 2 pour des raisons de compatibilité (ce qui n'est pas conseillé). L'encodage est ensuite précisé, de façon optionnelle. Cogitant est capable de détecter automatiquement l'encodage du fichier (entre UTF-8 et Latin-9), mais celui-ci peut être précisé pour éviter toute ambiguïté. Les valeurs autorisées sont ISO-8859-15 (ou ISO-8859-1) et UTF-8.
Suite à cette entête, figure le mot-clef Begin marquant le début du fichier. Le fichier se termine par le mot-clef End.
Un support est composé d'un ensemble partiellement ordonné des types de concepts, un ensemble partiellement ordonné des types de relations, un ensemble partiellement ordonné des types d'emboîtements, des signatures des types de relation et de relation de conformité. Un système pouvant être amené à manipuler plusieurs supports, un identificateur est donné au support.
La présence du symbole + concaténé à l'identificateur du support signifie que le fichier est un complément à un support existant (cette possibilité n'est évidemment pas obligatoirement utilisée, et dépend de l'application).
Le nom du support est éventuellement suivi d'une liste de 4 entiers représentant respectivement le nombre de types de concepts, types de relations, types d'emboîtements et marqueurs individuels. Ces renseignements sont optionnels mais peuvent permettre d'accélérer le chargement du support.
L'ensemble partiellement ordonné des types de concepts est représenté sous la forme de deux listes de déclarations. La première fournit les identificateurs de tous les types de concepts présents dans l'ensemble. C'est dans la déclaration de cette liste que doivent être spécifiés les éventuelles propriétés des types (voir plus bas pour la description de la grammaire BCGCT). La seconde liste définit la relation d'ordre entre les types de concepts par spécification de couples dont le premier élément est inférieur au second. Cette liste est facultative : elle est absente dans le cas d'un ensemble dans lequel tous les éléments sont incomparables.
Attention : dans la variante 3 du format (et contrairement à la variante 2), les types Universel et Absurde ne sont pas implicites et doivent explicitement être présents dans la première liste pour pouvoir être utilisés.
Remarquer l'expression des traductions des types de concepts, qui sont représentées par une propriété label_xx où xx est l'identifiant de la langue. La même syntaxe est utilisée pour les types de relations, types d'emboîtements et marqueurs individuels. En plus de la traduction des intitulés, des descriptifs dans chacune des langues peuvent être donnés, introduits par descr_xx.
L'ensemble partiellement ordonné des types de relations est représenté sous la forme de 2 listes de déclarations. La première fournit les identificateurs de tous les types de relations présents dans l'ensemble ainsi que leurs éventuelles propriétés et notamment leur arité et leur signature. Si la propriété Signature est absente, le type de relation n'a pas de signature et l'opération de vérification ne détectera aucune erreur sur des sommets relations utilisant ce type quel que soit leur nombre de voisins. Il est donc préférable de définir cette propriété pour tous les types de relations.
La seconde liste permet de définit la relation d'ordre entre les types de relations par spécification de couples dont le premier élément est inférieur au second. Cette liste est facultative : elle est absente dans le cas d'un ensemble dans lequel tous les éléments sont incomparables.
L'ensemble partiellement ordonné des types d'emboîtements est représenté sous la forme de 2 listes de déclarations. La première fournit les identificateurs de tous les types d'emboîtements présents dans l'ensemble ainsi que leurs éventuelles propriétés. La seconde liste permet de définit la relation d'ordre entre les types de relations par spécification de couples dont le premier élément est inférieur au second. Cette liste est facultative : elle est absente dans le cas d'un ensemble dans lequel tous les éléments sont incomparables.
Attention : dans la variante 3 du format (et contrairement à la variante 2), le type Description n'est pas implicite et doit explicitement être présent dans la première liste pour pouvoir être utilisé.
La relation de conformité est représentée par des couples marqueur individuel, identificateur de type de concept signifiant qu'un marqueur a pour type de concept minimum le type de concept spécifié.
La fin de la description du support est représentée par le mot clef EndSupport.
Enfin, le fichier se termine par le mot-clef End.
Le format BCGCT impose d'attribuer un identificateur à tout graphe conceptuel.
Deux autres critères optionnels sont à disposition des concepteurs d'applications et peuvent être utilisés différemment selon les besoins: la nature (mot clef Nature) du graphe (qui peut être fact, query, ...)
et l'ensemble (mot clef Set) qui peut permettre de grouper les graphes par familles ou thèmes.
Le graphe proprement dit est ensuite défini par trois listes : celle des sommets concepts, celle des sommets relations et celle des arêtes liant des sommets relations aux sommets concepts. Pour des graphes non connexes, il est possible de faire figurer autant de sections Concepts Relations Edges que de composantes connexes. Afin de distinguer les différents sommets, un identificateur unique doit être attribué à chacun d'eux. Cette attribution peut être faite manuellement par une personne saisissant une base de connaissances, ou automatiquement par une application sauvegardant ou communiquant une base de connaissances.
Pour la représentation de graphes emboîtés typés, il est nécessaire de représenter dans le troisième champ d'un sommet concept la liste des couples type d'emboîtement, identificateur du graphe emboîté. La définition du graphe emboîté doit précéder l'utilisation de son identificateur signifiant que le graphe est en fait emboîté dans un sommet concept d'un autre graphe.
Le format BCGCT impose d'attribuer un identificateur à toute règle.
La règle elle-même est définie en trois parties : le graphe hypothèse, le graphe conclusion et les liens entre ces deux graphes (points d'attache). L'hypothèse est repérée par le mot clef Hypt. Après ce mot-clef, le graphe hypothèse doit être donné au format BCGCT classique.
La conclusion est repérée par le mot clef Conc, et doit être elle aussi donnée sous la forme d'un graphe BCGCT.
Enfin, la troisième partie de la description d'une règle concerne les points d'attache. Il s'agit d'une liste de couples d'identificateurs de sommets (concepts génériques) dans lequel le premier identificateur repère un sommet du graphe hypothèse et le second un sommet du graphe conclusion. Ces couples de sommets repèrent les points d'attache de la règle. Cette liste de couples se termine par le mot clef EndRule qui termine aussi la représentation de la règle.
L'hypothèse et/ou la conclusion d'une règle peut contenir des graphes emboîtés. Dans ce cas, le graphe de niveau 0 doit être le dernier déclaré dans la partie hypothèse et dans la partie conclusion. La règle ci-dessous (samples/bcgct/bucolic/nestedrule.bcr) peut être interprétée de la façon suivante : Si un tableau x représente une scène qui peut être décrite par une entité composée d'une personne y qui dort, alors le tableau x est bucolique et la personne y pense. Remarquer que dans la section Hypt: comme dans la partie Concl:, le dernier graphe déclaré est celui contenant le tableau. Remarquer aussi la section ConnectionPoints qui contient des couples d'identificateurs de sommets, qui doivent être cohérents avec la structure des graphes hypothèse et conclusion.
Les notations utilisées ci-dessous sont les suivantes :
< > | [ ] { }* { }+
Le format BCGCT utilisant des caractères tels que *[]()+, la lecture de la grammaire dans cette page HTML peut prêter à confusion car HTML ne permet pas de mettre facilement en page un tel document. Il est donc préférable de consulter la documentation LaTeX / PostScript / PDF dans laquelle la grammaire peut être plus facilement interprétée.
<fichier>::=
(1) [<propriétés>]
Begin
[<support>]
{<graphe>|<règle>|<contraintepos>|<contrainteneg>}*
End
<support>::=
Support: [<ident_support>][<propriétés>][<tailles_support>][+];
[ensemble_TCon]
[ensemble_TRel]
[ensemble_TEmb]
[conformité]
[ensemble_TBan]
EndSupport;
<propriétés>::=
{{<entier>|<chaîne>:<entier>|<chaîne>;}*}
<tailles_support>::=
(2) (<entier>, <entier>, <entier>, <entier>)
<ensemble_TCon>::=
EnsTCon:
ConceptTypes:
{<tConcept>;}+
EndConceptTypes;
[<ordre_TCon>]
EndTCon;
<tConcept>::=
<ident_TCon> [<propriétés>]
<ordre_TCon>::=
Order:
{<ident_TCon> < <ident_TCon>;}+
EndOrder;
<ensemble_TRel>::=
EnsTRel:
RelationTypes:
{<tRelation>;}+
EndRelationTypes;
[<ordre_TRel>]
EndTRel;
<tRelation>::=
(3) <ident_TRel> [<propriétés>]
<ordre_TRel>::=
Order:
{<ident_TRel> < <ident_TRel>;}+
EndOrder;
<ensemble_TEmb>::=
EnsTNes:
NestingTypes:
{<tEmboitement>;}+
EndNestingTypes;
[<ordre_TEmb>]
EndTNes;
<tEmboitement>::=
<ident_TEmb> [<propriétés>]
<ordre_TEmb>::=
Order:
{<ident_TEmb> < <ident_TEmb>;}+
EndOrder;
<conformité>::=
Conf:
{<ident_marqueur>, <ident_TCon> [<propriétés>];}*
EndConf;
<ensemble_TBan>::=
BannedTypes:
{<ident_TCon>{,<ident_TCon>}*;}*
EndBannedTypes;
<graphe>::=
(4) Graph: [<ident_gc>][<propriétés>];
[Nature: <ident_nature>;]
[Set: <ident_ensemble>;]
[Pointer: <ident_concept>;]
{Concepts:
{<concept>;}+
Relations:
{<relation>;}*
Edges:
{<arête>;}*
}*
[Extensions: {<ident_ext> <value_ext>;}+]
(4) [<propriétés>]
EndGraph;
<concept>::=
(5) <ident_concept>=[<ident_TCon>{,<ident_TCon>}*[:<référent>[:<description>]][<propriétés>]]
<référent>::=
(6)(7) <ident_marqueur> | * | $<ident_variable> | valeur
<description>::=
(6) {(<ident_TEmb>, <ident_graphe> [<propriétés>])}+ | **
<relation>::=
<ident_relation>=(<ident_TRel>[<propriétés>])
<arête>::=
<ident_relation>, <ident_concept>, <entier>
<règle>::=
Rule: [<ident_règle>][<propriétés>];
Hypt: {<graphe>}*
Conc: {<graphe>}*
ConnectionPoints:
{<couple>;}+
EndRule;
<contraintepos>::=
PositiveConstraint: [<ident_contrainte>][<propriétés>];
Condition: {<graphe>}*
Obligation: {<graphe>}*
ConnectionPoints:
{<couple>;}+
EndPositiveConstraint;
<contrainteneg>::=
NegativeConstraint: [<ident_contrainte>][<propriétés>];
Condition: {<graphe>}*
Interdiction: {<graphe>}*
ConnectionPoints:
{<couple>;}+
EndNegativeConstraint;
<ident_xxx>::=
<chaîne>
<entier>::=
{0..9}+
<chaîne>::=
{a..zA..Z}{a..zA..Z0..9}* | "{a..zA..Z0..9}+"
<couple>::=
(<ident_c1>, <ident_c2> [<propriétés>])
Remarques:
{BCGCT:3;App:CoGITaNT} correspond à un fichier à la version 3 du format et généré par CoGITaNT. Si le numéro de version du format n'est pas présent, le fichier est interprété comme étant à la version 2 (pour des raisons de compatibilité). La principale différence sera l'ajout de deux types de concepts UNIVERSEL et ABSURDE lors de l'interprétation du support, même si le fichier ne mentionne pas ces types. Signature:<entier>{,<ident_TCon>{/<ident_TCon>}*}+. Avec la contrainte suivante : le nombre de types de concepts doit être égal à l'entier (l'arité du type de relation). Chaque type de concept (conjonctif) peut être formé de plusieurs types de concepts (primitifs) : ils sont alors séparés par des /. EndGraph sont celles de l'objet cogitant::InternalGraph racine du graphe. Dans le cas d'un graphe emboîté dans un sommet concept, les propriétés du cogitant::Graph sont perdues alors que celles du cogitant::InternalGraph restent. [ et ]. * repère ici le caractère *. $<ident_variable> (exemple: $x1) permet de représenter les classes de coréférence : tous les sommets d'un graphe ayant le même référent $xxx sont dans la même classe de coréférence. Il est possible d'utiliser des commentaires dans un fichier BCGCT de la même façon qu'en C++, c'est à dire en commençant par un double slash (dans ce cas, le commentaire se finit à la fin de la ligne) ou par un slash et une étoile (dans ce cas, le commentaire se finit par une étoile suivie d'un slash).