With readability and efficiency, the BCGCT format (Textual Knowledge Base of Conceptual Graphs; Base de Connaissances Graphes Conceptuels Textuelle) allows representations of supports (set of partially ordered concept types, relation types, nesting types, signature of relation types and conformity types), conceptuel graphs (connex or not, simple or nested) and rules.
It is important to differentiate between the grammar of the BCGCT format and the functionalities of the CoGITaNT Version 5 plateform. CoGITaNT does not implement the complete format. For a exhaustive description of CoGITaNT format (except for the latest extension), see [Haemmerlé, 1995].
Several versions of the BCGCT format exist, according to the evolution of the CoGITo/CoGITaNT plateform :
One single BCGCT file contains only one support. It describes the support and/or the graphs that make it. The structure of a BCGCT file is as follows: it combines the description of the support and the description of its graphs and/or rules. However, it is possible and sometimes preferable to stored separately support and graphs. If this is the case, it is advisable to use the extension .bcs for the support, .bcg for the graphs and .bcr for the rules.
A BCGCT files according to variant 3 start with a header describing the file format and eventually the application that is at the origin of the file. In the absence of a header, the file is understood to be of version 2 for compatibility reasons (but this is not advisable). Encoding mode is optionally added. Cogitant is automatically detecting the encoding mode (either UTF-8 or Latin-9), but it can be explicitly given to avoid ambiguity. Authorised values are ISO-8859-15 (or ISO-8859-1) and UTF-8.
After the header, the key word Begin is shown. It indicates the start of the file. The key word End indicates the end of the file.
A support is made of a partlially ordered set of concept types, a partlially ordered set of relation types, a partlially ordered set of nesting types, signatures of relation types, conformity relations. As a system can use several supports, a unique identifier is given to the support.
The presence of the symbol +, concatenated to the support identifier, means that the file is complementary to an already existing support. (This feature is not always used and depends on the application).
The name of the support can eventually be followed by 4 integers respectively representing the number of concept types, relation types, nesting types and individual markers. This information is optional but allows speeding up the support loading process.
A partially ordered set of concept types is represented under the shape of 2 lists of declarations. The first list shows the identifiers of all concept types present in the set. It is in this list that potential propriety of types must be declared (see below for the description of the BCGCT grammar).
The second list defines a relation of order between concept types in specifying pairs of witch the first element in less than the second. This list is optional and sometimes does not exist if elements of a set are not comparable.
Caution: in the variant 3 of the format (and by opposition to variant 2), the types Universel and Absurde are not implicit and must be explicitly given in the first list, in order to be used.
Please note how translations are carried out in concept types. They are represented by the property label_xx where xx is the language identifier. The same principle is used to translate relation types, nesting types and individual markers. Additionally to the label translation, the translation of descriptions can be added using descr_xx.
The partially ordered set of relation types is represented within 2 lists of declarations. The first list specifies the identifiers of all relation types present in the set as well as their eventual properties, number of arguments and their signature. If the property Signature is not mentioned, the relation type has no signature and the verifying process will not detect possible errors on relation vertices despite the presence of neighbours. It is therefore best to define this property for all relation types.
The second list defines a relation of order between relation types in specifying pairs of witch the first element in less than the second. This list is optional and sometimes does not exist if elements of a set are not comparable.
The partially ordered set of nesting types is represented within 2 lists of declarations. The first list specifies the identifiers of all nesting types present in the set as well as their eventual properties. The second list defines a relation of order between relation types in specifying pairs of witch the first element in less than the second. This list is optional and sometimes does not exist if elements of a set are not comparable.
Caution: in the variant 3 of the format (and by opposition to variant 2), the types Description is not implicit and must be explicitly given in the first list, in order to be used.
The conformity relation is represented by pairs individual marker, identifier of concept types which means that a marker has, as minimum concept type, the specified concept type.
The end of the support description is indicated by the key word EndSupport.
And last, the file is ended by the key word End.
In the BCGCT format, all conceptual graphs must have an indentifier.
Application designers have 2 more optional choices. They can be used in different ways according to needs: nature of the graph (key word Nature) (wich can be fact, query, ...)
and the set (key word Set) which allow grouping of graphs by family or theme.
The graph itself is defined by 3 lists: the concept vertices list, the relation vertices list and the edges list which links relation vertices to concept vertices. Non connex graphs can have as many sections Concepts Relations Edges as connex components. In order to distinguish the different vertices, a unique identifier must be given to each of them. It can be done manually by entering a unique number in a data base or automatically by an application which will storing the identifier in a data base.
For representing typed nested graph, it is necessary to indicate in the third field of a vertice concept, the list of pairs nesting type, identifier or nested graph. The definition of a nested graph must be given before referencing its identifier. This indicates that the graph is nested in the concept vertice of another graph.
In the BCGCT format, all rules must have an indentifier.
Hypt. After the key word, the hypothesis graph must be written in the classical BCGCT format. Conc. It must also be written under the format of a BCGCG graph.
EndRule which also ends the description of the rule.
The hypothesis and/or the conclusion of a rule can contain nested graphs. In this case, level 0 of the graph must be declared last in the part reserved for the hypothesis and in the part reserved for the conclusion. The following rule (samples/bcgct/bucolic/nestedrule.bcr) can be interpreted as follows: if a painting x represents a scene that can be described by an entity made of a person y who is sleeping, then the painting x is bucolic and the person y is thinking. Please note that in the section Hypt: as well as in the section Concl:, the last declared graph is the one of the painting. Please also note that the section ConnectionPoints which contains pairs of vertice identifiers. Those identifiers must be coherent with the structure of the hypothesis graphs and the conclusion graphs.
Meaning of the notations used below:
< > | [ ] { }* { }*
Because the BCGCT format is using characters such as *[]()+, reading HTML code in this page can be confusing. It is therefore advisable to read the LaTeX / PostScript / PDF documentation which grammar can be interpreted more easily.
<fichier>::=
(1) [<propriétés>]
Begin
[<support>]
{<graphe>|<règle>}*
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>;]
{Concepts:
{<concept>;}+
Relations:
{<relation>;}*
Edges:
{<arête>;}*
}*
(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>
<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;
<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>])
Notes:
{BCGCT:3;App:CoGITaNT} corresponds to the format version 3 of a file, generated by CoGITaNT. If the format version number is not indicated, the file is understood as version 2 (for compatibility reasons). The main difference will be the addition of two concept types UNIVERSEL and ABSURDE when interpreting the support, even if the file does not mention these types. Signature:<entier>{,<ident_TCon>{/<ident_TCon>}*}+, with the following constraint : the number of concept types must be equal to the integer (number of argument of the relation type). Each (conjunctive) concept type may be formed by several (primitive) concept types: these primitive types are then separated by /. EndGraph apply to the object cogitant::InternalGraph, root of the graph. In the case of a nested graph in a concept vertice, properties of cogitant::Graph are lost but properties of cogitant::InternalGraph remain. [ and ]. * indicate here the character *. $<ident_variable> (example: $x1) allow representation of the coreference classes. i.e.: All the vertices of a graph having the same referent $xxx are in the same coreference class. Like C++, BCGCF files allow comments. They can start with a double slash (and in this case, the comment ends at the end of the line) or they can start by a single slash followed by a star (in this case the end of the comment is indicated by a star followed by a slash).