Le langage XML (eXtensible Markup Language) est un langage de représentation de données adapté pour représenter des données structurées. Un document XML est comme une arborescence d'objets, ayant des attributs et contenant éventuellement du texte. Il peut être de deux catégories : valide et bien formé. La vailidité se rapporte à la dépendance d'une DTD (Document Type Definition). Une DTD est utilisée pour décrire la structure et le type de balises utilisés dans un document XML, qui, pour être déclaré valide, devra respecter la définition donnée dans la DTD.
Le format CoGXML permet de représenter des graphes conceptuels sous la forme de documents XML. La DTD qui a été définie permet la représentation de supports (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é), de graphes (connexes ou non connexes, simples ou emboîtés) et de règles.
Le format CoGXML était appelé CGXML dans les précédentes versions de Cogitant. Ce format a été établi parallèlement à un autre format qui permet de représenter des graphes conceptuels sous la forme de documents XML, et ce format s'appelle aussi CGXML (http://tockit.sourceforge.net/cgxml/). Or, ces deux formats sont différents, et les opérations de lecture/écriture sont incompatibles. Afin d'éviter toute confusion, le format CGXML "de Cogitant" a donc été renommé en CoGXML.
Comme tout fichier XML, un fichier CoGXML comporte une entête de déclaration de version XML et de la DTD associée. Vient ensuite, dans tout fichier CoGXML, la balise <CoGXML>. À l'intérieur de cette balise, figurent les déclarations propres aux supports, aux graphes et aux règles. Le fichier se termine par la fin de balise </CoGXML>.
Les objets du modèle sont représentés par différentes balises et attributs. Le format CoGXML offre la possibilité de repérer certaines informations sur les objets (par exemple : type de concept, type de relation, type d'emboîtement) sous la forme du libellé explicite de l'objet ou sous la forme d'un identificateur. Par exemple (voir ci-dessous), pour la description des objets liés aux types de concepts, on peut décrire la relation d'ordre entre les types de concepts soit par un ensemble de balises order ayant les attributs id1 et id2 (identificateurs des types de concepts), soit par un ensemble de balises order ayant les attributs label1 et label2, ces derniers désignant les types de concepts par leur libellé complet.
Comme dans tout fichier XML, des entités prédéfinies permettent de représenter des caractères spéciaux sous une forme particulière afin qu'ils ne soient pas confondus avec les caractères de balisage. Ainsi les caractères & < > ' et " doivent être représentés (respectivement) par & < > ' et ".
Un support est composé d'un ensemble partiellement ordonné de types de concepts, un ensemble partiellement ordonné de types de relations, un ensemble partiellement ordonné de types d'emboîtements, des signatures des types de relation et de la relation de conformité.
Un système pouvant être amené à manipuler plusieurs supports, un identificateur est donné au support au travers de l'attribut name.
L'ensemble partiellement ordonné des types de concepts est représenté par l'élément conceptTypes incluant les éléments ctype et order. Les éléments ctype décrivent les identificateurs et les libellés de tous les types de concepts présents dans l'ensemble. Cet élément contient les attributs id (identificateur dans le fichier CoGXML) et label (intitulé du type de concept). De façon optionnelle, l'élément ctype peut contenir des éléments translation afin de stocker les traductions de l'intitulé du type de concept dans différentes langues, dans ce cas, chaque élément translation doit contenir un attribut lang représentant l'identifiant de la langue, et un attribut label donnant la traduction dans la langue en question. L'attribut optionnel descr de translation permet de donner une description du type dans la langue en question.
Les éléments order permettent de définir la relation d'ordre entre les types de concepts par spécification de couples dont le premier élément est inférieur au second. Les éléments order sont facultatifs : ils sont absents dans le cas d'un ensemble dans lequel tous les éléments sont incomparables. Chaque élément order est renseigné avec les attributs id1 et id2 (identificateurs de types de concepts) ou les attributs label1 et label2 (intitulés de types de concepts).
Dans un même fichier, tous les éléments order doivent être définis de la même façon.
L'ensemble partiellement ordonné des types de relations est représenté par la balise relationTypes incluant les balises rtype et order. Chaque balise rtype décrit l'identificateur et l'intitulé d'un type de relation présents dans l'ensemble ainsi que sa signature (optionnelle). La propriété signature peut être décrite soit par l'attribut idSignature soit par l'attribut labelSignature. Un ensemble de balises type ne peut avoir à la fois des attributs idSignature et des attributs labelSignature. La balise rtype contient aussi les attributs id et label. Les traductions dans différentes langues peuvent être représentées de la même façon que dans le cas d'un type de concept à l'aide d'éléments translation.
Les balises order permettent de définir la relation d'ordre entre les types de relations par spécification de couples dont le premier élément est inférieur au second. Ces balises sont facultatives : elles sont absentes dans le cas d'un ensemble dans lequel tous les éléments sont incomparables.
Dans un même fichier, toutes les balises order doivent être définies de la même façon.
Dans le cas de la définition de la signature d'un type de relation par les intitulés des types de concepts (attribut labelSignature), si un intitulé de type de concept contient un ou plusieurs caractères blancs, ceux-ci devront être précédés d'un antislash. En effet, le caractère blanc étant utilisé pour séparer les différents intitulés des types de concepts dans la valeur de l'attribut labelSignature, il était nécessaire de prévoir un caractère d'échappement pour représenter le caractère blanc à l'interieur d'un intitulé de type de concept. Évidemment, toute occurrence du caractère antislash devra elle aussi être protégée par le caractère d'échappement antislash. Dans le cas où certains types de la signature sont conjonctifs, les types primitifs composant le type conjonctif sont séparés par le caractère ;.
L'ensemble partiellement ordonné des types d'emboîtements est représenté par la balise nestingTypes incluant les balises ntype et order. Les balises ntype décrivent les identificateurs et intitulés des types d'emboîtements présents dans l'ensemble. Cette balise contient les attributs id et label. La représentation des traductions se fait de la même façon que pour les autres ensembles de types du support. Les balises order permettent de définir la relation d'ordre entre les types d'emboîtements par spécification de couples dont le premier élément est inférieur au second. Les balises order sont facultatives : elles sont absentes dans le cas d'un ensemble dans lequel tous les éléments sont incomparables. Chaque balise order est renseignée avec les attributs id1 et id2 ou les attributs label1 et label2. Dans un même fichier, toutes les balises order doivent être définies de la même façon.
Dans un même fichier, toutes les balises order doivent être définies de la même façon.
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 balise marker présente les attributs id, label ainsi que idType ou labelType suivant le type de représentation choisi. Les attributs idType et labelType sont optionnels, ce qui permet de déclarer un marqueur individuel qui n'est lié à aucun type de concept. Si une telle déclaration n'est pas conforme au modèle, il peut être utile de ne pas préciser le type d'un marqueur individuel dans une phase de constuction du support.
Un graphe est composé d'un ensemble de sommets concepts, de sommets relations et d'arêtes liant les sommets relations aux sommets concepts.
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 des graphes, ou automatiquement par une application sauvegardant ou communiquant des graphes.
Un identificateur est donné au graphe par l'attribut id. Deux autres critères optionnels sont à disposition : l'attribut nature pour la nature du graphe et l'attribut set qui permet de regrouper les graphes par familles ou par thèmes.
Les sommets concepts d'un graphe conceptuel sont représentés par les balises concept décrivant les attributs :
Pour la représentation de graphes emboîtés typés, il est nécessaire de représenter la liste des emboîtements contenus dans un sommet concept sous la forme de couples (type d'emboîtement, identificateur du graphe emboîté). La balise nesting avec les attributs idType ou labelType (identificateur ou intitulé du type d'emboîtement) et nestGraph (identificateur du graphe emboîté) permet de décrire le type d'emboîtement et le graphe emboîté. La définition du graphe emboîté doit précéder l'utilisation de son identificateur signifiant que le graphe est emboîté dans un sommet concept d'un autre graphe.
Les sommets relations d'un graphe conceptuel sont représentés par des balises relation décrivant les attributs :
Les arêtes liant les sommets relations aux sommets concepts d'un graphe conceptuel sont représentées par des balises edge décrivant les attributs :
Une règle de graphes conceptuels est représentée par une balise rule. Chaque règle est repérée par un identificateur donné par l'attribut id.
La règle 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 désignée par la balise hypt. Celle-ci encadre une description de graphe avec balises adéquates.
La conclusion est décrite par la balise conc encadrant, elle aussi, une description de graphe avec balises adéquates.
La troisième partie désigne les points d'attache. Elle est repérée par la balise conPts encadrant des balises couple. Il s'agit d'une liste de couples d'identificateurs de sommets (concepts génériques) dans lequel le premier identificateur présenté par l'attribut idC1 repère un sommet du graphe hypothèse et le second présenté par l'attribut idC2, un sommet du graphe conclusion. Ces couples de sommets repèrent les points d'attache 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/xml/bucolic/nestedrule.xml) 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.
Pour se référer à la DTD CoGXML lors de la création de fichiers à ce format, utiliser la syntaxe suivante :
La dernière version de la DTD peut être retrouvée à l'URL : http://cogitant.sourceforge.net/cogxml.dtd
Le format est défini de la façon suivante :
<?xml version="1.0" encoding="UTF-8"?> <!-- DTD CoGXML 1.5 This DTD allow representation of a support, representation of a conceptual graph and representation of graph rules. To apply this DTD, use the following syntax: <!DOCTYPE CoGXML PUBLIC "-//COGITANT//CoGXML Format Specification 1.4//EN" "http://cogitant.sourceforge.net/cogxml.dtd"> This file is part of Cogitant which is a library facilitating construction of applications using conceptual graphs. It is under GPL licence. http://cogitant.sourceforge.net Cogitant version 5.2.91 - Last change of the DTD : 2011-04-18 --> <!-- Attribute Extensions of standard tags. --> <!ENTITY % cogxmlExtensions ""> <!ENTITY % supportExtensions ""> <!ENTITY % conceptTypesExtensions ""> <!ENTITY % relationTypesExtensions ""> <!ENTITY % nestingTypesExtensions ""> <!ENTITY % conformityExtensions ""> <!ENTITY % bannedTypesExtensions ""> <!ENTITY % allBannedExtensions ""> <!ENTITY % supportObjectExtensions ""> <!ENTITY % ctypeExtensions ""> <!ENTITY % rtypeExtensions ""> <!ENTITY % ntypeExtensions ""> <!ENTITY % markerExtensions ""> <!ENTITY % orderExtensions ""> <!ENTITY % bannedTypeExtensions ""> <!ENTITY % modulesExtensions ""> <!ENTITY % moduleExtensions ""> <!ENTITY % graphExtensions ""> <!ENTITY % environmentObjectExtensions ""> <!ENTITY % nodeExtensions ""> <!ENTITY % conceptExtensions ""> <!ENTITY % nestingExtensions ""> <!ENTITY % relationExtensions ""> <!ENTITY % edgeExtensions ""> <!ENTITY % ruleExtensions ""> <!ENTITY % positiveConstraintExtensions ""> <!ENTITY % negativeConstraintExtensions ""> <!ENTITY % conPtsExtensions ""> <!ENTITY % coupleExtensions ""> <!ENTITY % subPropExtensions ""> <!-- Document. --> <!ELEMENT cogxml (support?, (graph | rule | positiveConstraint | negativeConstraint)*)> <!ATTLIST cogxml app CDATA #IMPLIED %cogxmlExtensions; > <!-- Additional properties for each object of the model --> <!ELEMENT subprop EMPTY> <!ATTLIST subprop subid CDATA #REQUIRED %subPropExtensions; > <!-- Translation of an objet of the model. --> <!ELEMENT translation EMPTY> <!ATTLIST translation lang CDATA #REQUIRED label CDATA #REQUIRED descr CDATA #IMPLIED > <!-- Support. Add Attribute: if set to true, elements of the support are added to the previously loaded support. If set to false (or not set at all), the elements of the support replace all previously loaded elements.--> <!ELEMENT support (conceptTypes, relationTypes?, nestingTypes?, conformity?, bannedTypes?, modules?, subprop*)> <!ATTLIST support name CDATA #IMPLIED add (true|false) "false" %supportExtensions; > <!ELEMENT conceptTypes (ctype*, order*)> <!ATTLIST conceptTypes %conceptTypesExtensions; > <!ELEMENT ctype (translation*, subprop*)> <!ATTLIST ctype id ID #IMPLIED label CDATA #REQUIRED %supportObjectExtensions; %ctypeExtensions; > <!ELEMENT order EMPTY> <!ATTLIST order id1 IDREF #IMPLIED id2 IDREF #IMPLIED label1 CDATA #IMPLIED label2 CDATA #IMPLIED > <!ELEMENT relationTypes (rtype*, order*)> <!ATTLIST relationTypes %relationTypesExtensions; > <!ELEMENT rtype (translation*, subprop*)> <!ATTLIST rtype id ID #IMPLIED label CDATA #REQUIRED idSignature CDATA #IMPLIED labelSignature CDATA #IMPLIED %supportObjectExtensions; %rtypeExtensions; > <!ELEMENT nestingTypes (ntype*, order*)> <!ATTLIST nestingTypes %nestingTypesExtensions; > <!ELEMENT ntype (translation*, subprop*)> <!ATTLIST ntype id ID #IMPLIED label CDATA #REQUIRED %supportObjectExtensions; %ntypeExtensions; > <!ELEMENT conformity (marker*)> <!ATTLIST conformity %conformityExtensions; > <!ELEMENT marker (translation*, subprop*)> <!ATTLIST marker id ID #IMPLIED label CDATA #REQUIRED idType IDREF #IMPLIED labelType CDATA #IMPLIED %supportObjectExtensions; %markerExtensions; > <!ELEMENT bannedTypes (bannedType | allBanned)*> <!ATTLIST bannedTypes %bannedTypesExtensions; > <!ELEMENT bannedType (type*)> <!ATTLIST bannedType %bannedTypeExtensions; > <!ELEMENT allBanned (type*)> <!ATTLIST allBanned %allBannedExtensions; > <!ELEMENT type EMPTY> <!ATTLIST type id CDATA #IMPLIED label CDATA #IMPLIED > <!ELEMENT modules (module*)> <!ATTLIST modules %modulesExtensions; > <!ELEMENT module (conceptTypes, relationTypes?, nestingTypes?)> <!ATTLIST module id ID #IMPLIED label CDATA #REQUIRED %moduleExtensions; > <!-- Graph --> <!ELEMENT graph (concept*, relation*, edge*, subprop*)> <!-- Attributes pointer and pointerMarker are forbidden when nature is not "individual". --> <!ATTLIST graph id ID #REQUIRED nature CDATA #IMPLIED set CDATA #IMPLIED pointer IDREF #IMPLIED pointerMarker CDATA #IMPLIED %environmentObjectExtensions; %nodeExtensions; %graphExtensions; > <!ELEMENT concept (type*, value?, nesting*, subprop*)> <!-- If the concept type is conjunctive, idType and labelType attributes are not stated but "type" elements are nested in the "concept" element. For an untyped value, idDatatype attribute has to be used with an empty value. --> <!ATTLIST concept id ID #REQUIRED idType CDATA #IMPLIED labelType CDATA #IMPLIED idDatatype CDATA #IMPLIED coreferenceClass CDATA #IMPLIED referent (generic|individual|variable|value|genericvalue) "generic" idMarker CDATA #IMPLIED labelMarker CDATA #IMPLIED %nodeExtensions; %conceptExtensions; > <!ELEMENT value (#PCDATA)> <!ATTLIST value > <!ELEMENT nesting (subprop*)> <!ATTLIST nesting idType CDATA #IMPLIED labelType CDATA #IMPLIED nestGraph CDATA #REQUIRED %nodeExtensions; %nestingExtensions; > <!ELEMENT relation (subprop*)> <!ATTLIST relation id ID #REQUIRED idType CDATA #IMPLIED labelType CDATA #IMPLIED %nodeExtensions; %relationExtensions; > <!ELEMENT edge EMPTY> <!ATTLIST edge rid IDREF #REQUIRED cid IDREF #REQUIRED label CDATA #REQUIRED %edgeExtensions; > <!-- Rule. --> <!ELEMENT rule (hypt, conc, conPts, subprop*)> <!ATTLIST rule id ID #REQUIRED %environmentObjectExtensions; %ruleExtensions; > <!ELEMENT hypt (graph*)> <!ELEMENT conc (graph*)> <!ELEMENT conPts (couple*)> <!ATTLIST conPts %conPtsExtensions; > <!ELEMENT couple EMPTY> <!ATTLIST couple idC1 IDREF #REQUIRED idC2 IDREF #REQUIRED %coupleExtensions; > <!-- Constraint. --> <!ELEMENT positiveConstraint (condition, obligation, conPts, subprop*)> <!ATTLIST positiveConstraint id ID #REQUIRED %environmentObjectExtensions; %positiveConstraintExtensions; > <!ELEMENT negativeConstraint (condition?, interdiction, conPts, subprop*)> <!ATTLIST negativeConstraint id ID #REQUIRED %environmentObjectExtensions; %negativeConstraintExtensions; > <!ELEMENT condition (graph*)> <!ELEMENT obligation (graph*)> <!ELEMENT interdiction (graph*)>
Comme avec le format XML, le respect du format CoGXML impose de ne définir qu'une seule valeur pour un attribut donné d'une balise donnée. La bibliothèque CoGITaNT permet toutefois de définir plusieurs valeurs pour un même type de propriété, pour un objet donné (voir cogitant::PropertySet) à condition d'associer à chaque valeur un identifiant unique. L'ensemble de propriétés est alors décomposé en plusieurs sous ensembles, chaque sous ensemble étant identifié par un iSet. Ceci peut être représenté dans le format CoGXML par l'utilisation de balises <subprop>. Chacune de ses balises a un attribut obligatoire (subid) qui représente le iSet, et les autres attributs représentent les propriétés du sous-ensemble de propriétés correspondant. Dans CoGITaNT, cette fonctionnalité est utilisée pour la sauvegarde des propriétés graphiques de éléments de dessin qui ne correspondent pas à des cogitant::CogitantObject.
Une des particularités de la DTD CoGXML est de pouvoir y ajouter facilement de nouveaux attributs sans que la structure de la DTD soit à reprendre. Cette facilité d'ajout a été prévue pour tous les objets qui peuvent être représentés dans le format.
Plus précisément, les entités xxxExtensions déclarées au début de la DTD peuvent être définies pour représenter les caractéristiques de nouveaux attributs des balises. Par exemple, la DTD ci-dessous, basée sur CoGXML, rajoute l'attribut font aux sommets concepts.
<!ENTITY % conceptExtensions "font CDATA #IMPLIED" > <!ENTITY % cogxmlDTD PUBLIC "-//COGITANT/CoGXML Format Specification 1.1//EN" "http://cogitant.sourceforge.net/cogxml.dtd" > %cogxmlDTD;
Un fichier utilisant cette DTD pourra alors contenir des déclarations de sommets concepts du type :
Ces attributs supplémentaires sont lus comme des propriétés des objets définis dans la bibliothèque. Ainsi, la valeur de l'attribut font sera accessible par un appel du type :
L'analyseur fourni avec la bibliothèque ignore les DTD et ne vérifie donc pas que les attributs présents dans un fichier sont conformes à ceux déclarés dans la DTD. Pour la même raison, des valeurs par défaut présentes dans une extension de la DTD CoGXML seront ignorées (et devront être gérées explicitement par programme).
