The .cphrase Format

To publish a C-Phrase NLI over a database, a special .cphrase configuration file must be maintained. This file defines what tables (and views) can be accessed and with what phrases. In remote mode, where the interface is to a remote, already existing database, the first step is to import the remote database's schema into an initial .cphrase file which is then edited. In stand-alone mode, where an SQLite database is built on the C-Phrase server, an initially empty .cphrase file is built up from which later an SQLite database is built. Either way, the authoring of the NLI will be over this .cphrase file.

The examples discussed here are drawn from the .cphrase files: geo.cphrase, northwind.cphrase and personal.cphrase. We recommend that you peruse these now to get an idea of what typical .cphrase files look like.

The Entire Configuration (the config element)

The config element is always root element in a .cphrase file. Its DTD-based definition is:

<!ELEMENT config (table|view|report|pre|post|response|state|execute)*>
<!ATTLIST config
          id CDATA #REQUIRED
          db CDATA #REQUIRED
          language CDATA #IMPLIED>

Tag Attributes

The tag attribute id is the name of the configuration. It is required.

The tag attribute language is an optional comma separated list of languages with the first language being the dominant one. Its default value is language="english". Since C-Phrase currently only supports Swedish and English, this could in its most complex form be language="swedish,english" which would mean that both English and Swedish would be covered, but paraphrases and messages would be in Swedish.

The tag attribute db specifies how to connect to the underlying database. It is always present although in stand-alone mode the actual database may not be built yet. If so, then launching NLIs will result in an error message reminding the administrator to build an SQLite database. The specific format of the db attribute is a text string that always starts with either postgresql:,mysql: or sqlite: followed by a connection string. In the case of SQLite, the connection string is simply the name of the database file. For example, db="sqlite:personal.db" specifies the local SQLite database. See the database connection string documentation for remote databases.

Sub-elements

Within the c-phrase element, sub-elements represent tables, views, reports and then string processing directives pre, post and response. It might also contain a list of tuples within a state element that represent a database state. Finally there is an optional execute element which defines an SQL script that is executed over the underlying database every time an NLI is launched.