Appendix 2. Textual format



This Appendix describes both the current version and further improvements of the TROEPS textual format. A good idea is to follow the syntax used in the real-estate.bdf example which is provided with TROEPS. Note that many changes have occurred (the whole loader have been rewritten between version 1.0 and 1.1) and complies now with the specifications. So your old bases will not work anymore. The main differences are the following:

Principles

In TROEPS, the language is one mean (among others) and not an end. The system is defined through a set of basic notions which are accessible through TROEPS API. However, for reasons of textual dumping of a knowledge base into a file, of quick acquisition of data from another source and of global creation by a skilled user, TROEPS provides a textual format for defining knowledge bases.
Since it is not primitive, this format is subject to change but the TROEPS team warrants that, from one version of TROEPS to another, it will be able to translate from one format to another. The format is divided into a scheme format, used to describe concepts, viewpoints, classes, fields and bridges, and an instance format used for describing objects.

The base description file

A base description file contains the description of a knowledge base. Its name is terminated by a ".bdf" extension. It refers to the other knowledge bases (.bdf), lexicon (.ldf), annotation files (.adf), TALK files (.t) which have to be loaded, describe types and concepts to be declared inside the knowledge base and instance files (.idf) that must be loaded after these declarations.
Concepts in a knowledge base can only refer to concepts and types which have been declared either in the imported knowledge bases or in the present knowledge base. Of course, there cannot be any circularity between the references (but through link fields).

Figure 15: The knowledge base B1 contains the bases B2, B3 and B4 plus the instance file I1.
Usually, an application is made of several of these knowledge bases, one by concept to be declared (B k1,...Bkn), several ones which are built by referring to these concepts (B k'1,...Bk'm) and one application knowledge base (B) which gathers all these other bases and declare the instance files (see Figure 15 ).

Syntactic shape

TROEPS textual format is parsed with the help of a program generated by YACC, but the grammar given here is to be understood as a standard for the syntax and not as the actual implementation of it. Here is a small typical base description (boldfaced names are keywords). The syntax itself is introduced afterward.

<base-name
	required-bases = { base-name,... };
	types = { type-desc,... };
	viewpoints = { view-name,... };
	concepts =
		{
			<concept-name
				key = {
						<keyslot-name
							type = concept or type;
							nature = propriete or composant or lien;
							constructor = un or liste or ensemble;
						>,
						...
					};
				fields =
					{
						<field-name
							type = concept or type;
							nature = propriete or composant or lien;
							constructor = un or liste or ensemble;
						>,
						...
					};
				viewpoints =
					{
						<conceptview-name
							root-class =
								<class-name
									fields =
										{
											<field-name descriptor = desc-value;... >,
											...
										};
								>;
							classes =
								{
									<class-name
										super-class = class-name;
										fields =
											{
												<field-name descriptor = desc-value;... >,
												...
											};
									>,
									...
								};
						>,
						...
					};
				bridges =
					{
						<	bridge-name
							source = { class-name@conceptview-name,... };
							destination = class-name@conceptview-name;
						>,
						...
					};
			>,
			...
		};
	methods = { method-signature,... };
	instance-files = { file-name,... };
	lexicons = { file-name,... };
	talk-modules = { file-name,... };
>

Instance files

On loading a knowledge base from a particular file, the system will attempt to load an instance file with the same filename but ".idf" as extension. It will then load the files corresponding to the instance-file keyword. Instance files contain instance descriptions under the following format.

{
<concept-name
	is-in = {	class-name@conceptview-name,... };
	fied-name = value;
	...
>,...
}
The reference to another instance in an instance description can be achieved through either the complete description of the instance (which is then created), or a reference to the instance in the form:

#<<concept keyvalues*>>

Comments

Comments (inserted between /* and */) can be only put just before an entity description (beginning by a <). These comments are attached to the entities they precede and can be loaded and saved by the system. They can be found under the "comment" annotation label.

Backus-Naur form syntax

The following Backus-Naur form is built upon the following conventions:
Comments can be expressed with the help of matching /* */

<base>			::=		'<'	base-name
										required-bases '=' '{' l-file-name '}' ';'
										types '=' '{' l-desc-type '}' ';'
										viewpoints '=' '{' l-viewpoint-name '}' ';'
										concepts '=' '{' l-<concept> '}' ';'
										methods '=' '{' l-<signature> '}' ';'
										instance-files '=' '{' l-file-name '}' ';'
										lexicons '=' '{' l-file-name '}' ';'
										talk-modules '=' '{' l-file-name '}' ';' '>'
<desc-type>		::=	typefile-name
<concept>		::=		'<'	concept-name
										key '=' '{' l-<conceptslot> '}' ';'
										fields '=' '{' l-<conceptslot> '}' ';'
										viewpoints '=' '{' l-<conceptview> '}' ';'
										bridges '=' '{' l-<bridge> '}' ';' '>'
<concept-slot>	::=		'<'	conceptslot-name
										type '=' <concept> | <type> ';'
										nature '=' propriete | composant | lien ';'
										constructor '=' un | liste-de | ensemble-de ';' '>'
<viewpoint>		::=		'<'	viewpoint-name
										root-class '=' <root-class> ';'
										classes '=' '{' l-<class> '}' ';' '>'
<root-class >	::=		'<'	class-name
										fields '=' '{' l-<classslot> '}' ';' '>'
<filter>			::=		<class>
<class>			::=		'<'	class-name
										super-class '=' class-name ';'
										fields '=' '{' l-<classslot> '}' ';' '>'
<classslot>		::=		'<'	classslot-name <descriptor>* '>'
<descriptor>	::=				type '=' '{' l-<exp-class> '}' ';'
						|				domain '=' <domain> ';'
						|				intervals '=' '{' <interval>+ '}' ';'
						|				except '=' <domain> ';'
						|				card '=' <integer> | <interval> ';'
						|				default '=' <value> ';'
						|				assign '=' '(' l-<path> ')' ';'
						|				filters '=' '(' l-<filter> ')' ';'
						|				methods '=' '(' l-<method> ')' ';'
<bridge>			::= 		'<'	bridge-name
										source '=' '{' l-<class-ref> '}' ';'
										destination '=' <class-ref> ';' '>'
<object>			::=		'<'	is-in '=' '{' l-<class-ref> '}' ';'
										<field-value>-l '>'
<signature>		::=	method-name ':' l-<mtype> '->' <mtype>
<mtype>			::=	<constructeur> <type> | <constructeur> <concept>-name
<constraint>	::=	constraint-name '(' l-<constraint-term> ')'
<constraint-term> 	::= <argument> | <constraint-operator> '(' l-<constraint-term> ')'
<field-value>	::=	field-name '=' <value> ';'
<method>			::=	method-name '(' l-<argument> ')'
<argument>		::=	<value> | <path>
<path>			::=	'!' | <path> '.' field-name | <path> ':' field-name
<domain>			::=	<single-domain> | <collector-domain>
<single-domain> ::=	'{' l-<single-value> '}'
<collector-domain> ::= 'P' '(' <collector-value> ')' | '{' l-<collector-value> '}'
<interval>		::=	<bound> <single-value> <single-value> <boound>
<value>			::=	<collector-value> | <single-value>
<collector-value>	::= <set-value> | <list-value>
<list-value> 	::=	'(' l-<single-value> ')'
<set-value> 	::=	'{' l-<single-value> '}'
<single-value>	::=	'|' <anything> '|' | <object-ref>
<class-ref>		::=	class-name '@' conceptview-name
<object-ref>	::=	'#<<' concept-name l-<value> '>>'
<boolean>		::=	true | false
<bound>			::=	'[' | ']'

Keywords and multi-linguism

Multi-linguism is available by setting the (languages) TALK form (the first supported language found in this variable is the one considered). Supported languages are currently English and French. Type and constructor keywords are not available in multi-lingual form.

Reserved symbols

[ and ]
interval delimiters
< and >
structure delimiters
{ and }
set delimiters
( and )
list delimiters
,
set element separator
=
structure item assignment
;
structure item separator
#<< and >>
object reference delimiters
!
path initiator
.
path constructor
:
path constructor with concatenation
->
method functor
==, <>
equality comparators
<, >, >=, <=
ordered types comparators
/* */
comments

Terminals

type
regular expression
meaning
identifiers
[A-Za-z][-_A-Za-z0-9]*

external value
\|[^|]*\|
anything between | and |
string
\"[^"]*\"
anything between " and "
comments
/*.**/
anything between /* and */
integers
{+-}[0-9]+

reals
{S}{D}+"."{D}*((e|E){S}{D}+)?
{S}"."{D}+((e|E){S}{D}+)?

boolean
vrai|faux (resp. true|false)

infinite bounds
[+-]inf
-[infinity] or +[infinity]

Keywords

The lexical analyser can be used in two exclusive languages: French or English. Here is the exhaustive list of keywords:

base
base
concepts
concepts
attributs
fields
nature
nature
card
card
sauf
except
defaut
default
chemin
assign
methodes
methods
filtres
filters
classes
classes
sorte-de
superclass
classes-depart
sources
est-dans
is-in
points-de-vue
viewpoints
clef
key
dans
type
const
constructor
domaine
domain
intervalles
intervals
condition
condition
classe-racine
root-class
passerelles
bridges
classe-arrivee
destination

Concept field values (only available in French)

propriete
property
composant
component
un
a
liste
list
ensemble
set

API

(tr-print-when-created optional: boolean ) macro in [libtrl]

-> boolean, boolean boolean
Sets or returns a value indicating that, while loading a knowledge base, each created entity will cause an indication to be displayed on standard output.
(tr-load-base filename) function in [libtrl]

-> boolean, filename filename fnf
Loads a knowledge base defined in the file named filename. Returns t if no error has been detected, () otherwise. Results in the knowledge base actually loaded.
(tr-load-instance-file filename) function in [libtrl]

-> boolean, filename filename fnf
Loads an instance file defined in the file named filename. Returns t if no error has been detected, () otherwise. Results in the instances actually available.
(tr-unload-instances base) function in [libtrl]

-> boolean, base base base
Deletes all the instances of the concepts of the base. This allows to load again instance files after a failure without having to load again the whole knowledge base.
(tr-save-base base) function in [libtrl]

-> boolean, base base nab
Saves the knowledge base base in a file correspondng to its filename. Returns t if no error has been detected, () otherwise. The initial file, if it exists, is copied with appended "~".
(tr-save-base-as-talk base optional: fileout ) function in [libtrl]

-> boolean, base base nab, filename filename fnf
Prints the knowledge base base as a TALK program corresponding exactly to the action of loading the knowledge base. The result is printed in the stream fileout (by defaults (stdout)). Returns t if no error has been detected, () otherwise.
(tr-init-xml) function in [libtrl]

-> boolean
Initialises some variables for XML output. Applying this is required before launching tr-save-base-as-xml.
( tr-save-base-as-xml base optional: fileout ) function in [libtrl]

-> boolean, base base nab, filename filename fnf
Prints the knowledge base base as a XML document corresponding exactly to the contents of the knowledge base. The result is printed in the stream fileout (by defaults (stdout)). Returns t if no error has been detected, () otherwise.
(tr-save-base-as-c base optional: fileout )-- function in [libtrl]

-> boolean, base base nab, filename filename fnf NIY
The same as above with a C program instead of a TALK program.