XML language (eXtensible Markup Language) allows representation of structured data. An XML document is a tree like representation of objects. It can be considered as valid and well formed. Valid means that it is in accordance to a DTD (Document Type Definition). A DTD is used to define the structure and the type of the tags of an XML document. To be valid, the XML document must respect the definitions set up in its DTD.
The CoGXML format allows representation of conceptual graphs in the format of XML documents. The defined DTD allows representation of supports (a support is a set of partially ordered concept types, relation types, nested types, signature of relation types and conformity relations), representation of graphs (connexe or non connexe, simple or nested) and representation of rules.
What was called CGXML in previous versions of Cogitant, is now called CoGXML. Originally, they were 2 formats named CGXML, both allowing represention of conceptual graphs in XML documents (http://tockit.sourceforge.net/cgxml/). However the formats were differen. Therefore to avoid confusion, CGXML was renamed CoGXML.
As any XLM files, a CoGXML file contains an XML header specifying the XML version and the DTD associated. Then comes the <CoGXML> tag. This tag contains declarations of supports, graphs and rules. The GoGXML file is ended by a </CoGXML> tag.
The objects of the model are represented by different tags and attributes. The CoGXML format offers the possibility to locate information concerning objects ( for example : concept type, relation type, nesting type) thanks to an explicit labelling and identifying system. As show in the example below, concerning the description of objects linked to concept types, the relation of order between concept types can be described either by a set of tags order having attributes id1 and id2 (identifiers of concept types) or by a set of tags order having attributes label1 and label2. The later example is describing the concept types by their full name.
As in any XML files, predefined entities allow representations of special characters so they are not mistaken with tags. Characters such as & < > ' and " have to be represented respectively by & < > ' and ".
A support is made of a set of partially ordered concept types, a set of partially ordered relation types, a set of partially ordered nesting types, signatures of relation types and a conformity relation.
As a system can use several supports, an identifier is given to each support via the name attribute.
A set of partially ordered concept types is represented by the element conceptTypes in which are included elements ctype and order. The ctype elements describe identifiers and labels of all concept types in the set. ctype contains the attributes id (identifiers in the CoGXML file) and label (label of concept types). As an option, a ctype element can contain a translation element which stores translations of concept types in different languages. The language used is indicated in the lang attribute and the actual translation is given in the label attribute. Another optional attribute is descr. it allows to describe the language used.
The order elements define a relation of order between concept types in specifying pairs of which the first element in less than the second. The order elements are optional and are not found if elements of a set are not comparable. Every order element contains either the id1 et id2 attributes (identifiers of concept types) or the label1 et label2 attributes (labels of concept types).
In one file, all order elements must be defined in the same manner.
A set of partially ordered relation types is represented by the tag relationTypes in which are included tags rtype and order. The rtype tag describe the identifier and the label of a relation types and its signature in the set (the signature is optional). The signature property can be described either by the idSignature attribute or by the labelSignature attribute. The tag rtype also contains id and label attributes. Translation in different languages are indicated in a similar way as for concept types, using the translation element.
The order tags define a relation of order between relation types in specifying pairs of which the first element in less than the second. These tags are optional and are not found if elements of a set are not comparable.
In one file, all order tags must be defined in the same manner.
Concerning the definition of the relation type signature by the concept type labels (attribute labelSignature), if a concept type label contains one or more spaces, those spaces will have to be preceded by antislash. In fact, spaces are used to separate different concept type labels, in the attribute value labelSignature, therefore inside a concept type label, spaces have been replaced by escape characters. As a consequence, all occurrences of the antislash character would have to be protected by another antislash. If some types of a signature are conjunctive types, primitive types that compose the conjunctive type are separated by ;.
A set of partially ordered nesting types is represented by the tag nestingTypes in which are included tags ntype and order. The ntype tag describes the identifiers and the labels of nesting types in the set. The ntype tag also contains id and label attributes. Translations in different languages are indicated in a similar way as for other types of support. The order tags define a relation of order between nesting types in specifying pairs of which the first element in less than the second. These tags are optional and are not found if elements of a set are not comparable. Every order element contains either the id1 and id2 attributes or the label1 et label2 attributes.
In one file, all order tags must be defined in the same manner.
The conformity relation is represented by pairs made of an individual marker and an identifier of concept type. This means that a marker has for mimimum concept type, the specified concept type.
The marker tag contains the following attributes: id, label as well as idType or labelType depending on the type of representation. idType et labelType attributes are optional, this allowing declaration of an individual marker that would be not link to any concept types. If the declaration does not conform to the model, they may be benefits in not using the individual marker type, in the phase of the construction of the support.
A graph is made of a set of concept vertices, relation vertices and edges linking relation vertices and concept vertices.
In order to differentiate the different vertices, an unique identifier is given to every vertex. This can be done manually by the person keying in the graphs or automatically by a software saving or communicating with graphs. ??? .
The id attribute identifies the graph. Two other attributes are available: nature indicates the nature of the graph and set to group graphs by family or theme.
The concept vertices of a conceptual graph are represented by concept tag containing the following attributes:
Concerning the representation of typed and nested graphs, the list of nestings contained in a concept summit must be represented by pairs of (nesting type and identifier of nested graph). The nesting tag with the idType or labelType attributes (identifier or label of nesting type) and the nestGraph attribute (identifier of the nested graph) describe the nesting type and the nested graph. The definition of the nested graph must come before the use of its identifier.
The relation vertices of a conceptual graph are represented by relation tags containing the following attributes:
Edges linking relation vertices with concept vertices of a conceptual graph are represented by edge tags including the following attributes:
The rule of a conceptual graph is represented by a rule tag. Each rule has an identifier indicated by the id attribute.
A rule is made of three parts: the hypothesis graph, the conclusion graph and the links between these two graphs (anchorage points).
The hypothesis is recognised by the hypt tag. The hypt tags surround the graph description and tags.
The conclusion is recognised by the conc tag surrounding the graph description and tags.
The third part identify the anchorage points. It is identified by the conPts tags which surround couple tags. It lits pairs of vertice identifiers (generic concept) in which the first identifier in idC1 represent the vertice of the hypothesis graph and the second identifier idC2 represents a vertice of the conclusion graph. These pairs of vertices identify the anchorage points of the rule.
The hypothesis and/or the conclusion of a rule can contain nested graphs. In which case, the level 0 graph must be the last one declared in the hypothesis section and in the conclusion section. The rule below samples/xml/bucolic/nestedrule.xml) 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 the section ConnectionPoints which contains the pairs of identifiers of vertices. Those identifiers must be coherent with the structure of the hypothesis graphs and the conclusion graphs.
To refer to the CoGXML DTD when creating files in this format, please use the following syntax:
The latest version of the DTD can be fount at : http://cogitant.sourceforge.net/cogxml.dtd
The format is as follows:
<?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*)>
As in XML, the CoGXML format imposes to define only one value for a given attribute in a given tag. However the CoGITaNT library allows several values for the same type of property, for a given object (see cogitant::PropertySet) if each value has a unique identifier. The set of properties is then sliped up in several subsets. Each subset is identified by an iSet. It is represented, in CoGXML format, by using <subprop> tags. Every <subprop> tag has a mandatory attribute (subid) which is the iSet. The other attributes represent the properties of corresponding property subsets. In CoGITaNT, this parcticality is used for backing up graphical properties of an element which do not correspond to CoGITaNT objects cogitant::CogitantObject.
One of the particularities of the CoGXML DTD is to be able to easily add new attributes without changing the DTD structure. This facility applies to all objects in the format.
More precisely, xxxExtensions entities declared at the beginning of the DTE can be specified to represent characteristics of new tag attributes. For example, the following DTD, based on CoGXML, add the font attributes to concept vertices.
<!ENTITY % conceptExtensions "font CDATA #IMPLIED" > <!ENTITY % cogxmlDTD PUBLIC "-//COGITANT/CoGXML Format Specification 1.1//EN" "http://cogitant.sourceforge.net/cogxml.dtd" > %cogxmlDTD;
A file using this DTD could contain declarations of concept vertices such as:
Supplementary attributes are understood as properties of objects defined in the library. As such, the value of the font attribute will be accessible from similar call:
The analysis tool provided with the library ignores DTD and does not check that attributes in files are in accordance with the ones declared in the DTD. For the same reasons, default values present in an DTD CoGXML extension will be ignored (and would have to be explicitly dealt within a program).
