+
+ <ul>
+ <li>The <b>property</b> operator now accepts more than one <b>isfalse</b>
+ clause to increase the complexity of the constraint condition used to filter
+ the raw query results. This feature is exploited in the queries produced
+by the <a href="implementation.html">HELM query generator</a>.</li>
+
+ </ul>
+ <br>
+ <hr width="100%" size="2">
+ <div align="center">
+ <h3>The PostgreSQL database map:</h3>
+ </div>
+The <b>PostgreSQL database map</b> is a file describing how the MathQL-1
+interpreter must interact with the underlying PostgreSQL database, when it
+is run in Postgres mode. Currently this file contains the following information:<br>
+ <ul>
+ <li>the <i>database connection string</i> to be used when the interpreter
+opens a connection with the database;</li>
+ </ul>
+ <ul>
+ <li>the <i>map</i> describing the correspondence between the metadata
+access paths used by the <i>property</i> operator and the fields of the database
+tables.</li>
+ </ul>
+The format of the file is textual and line oriented, but a corresponding
+XML syntax will be provided soon.<br>
+The first line must contain the database connection string and the subsequent
+lines contain the map with the following syntax:<br>
+ <ul>
+ <li>blank lines: ignored (used for separation);</li>
+ </ul>
+ <ul>
+ <li>lines starting with a # followed by a space: ignored (used for
+comments);<br>
+ </li>
+ </ul>
+ <ul>
+ <li><table_name> <field_name> "<-"
+[ <path_component> ]*<br>
+ </li>
+ </ul>
+ <blockquote>the information about the metadata denoted by the given
+path is found in the given field of the given table in the database. For
+example the line:<br>
+ <br>
+refobj h_occurrence <- refObj h:occurrence<br>
+ <br>
+tells that the metadata denoted by the path <b>/"refObj"/"h:occurrence"</b>
+is found in the field "h_occurrence" of the table "refobj" in the database,
+while:<br>
+ <br>
+refobj source <-<br>
+ <br>
+tells that the metadata denoted by the path <b>/</b> is found in the field
+"source" of the table "refobj" in the database;<br>
+ </blockquote>
+ <ul>
+ <li><table_name> <field_name> "<+"
+[ <path_component> ]*<br>
+ </li>
+ </ul>
+ <blockquote>same as the previous but defines a default table and field
+for the given path. This is used to force the interpreter to query a particular
+table when the information denoted by a path can be found in more than one
+table and field. For example:<br>
+ <br>
+objectname source <+<br>
+refobj source <-<br>
+refrel source <-<br>
+refsort source <-<br>
+ <br>
+tells that the metadata denoted by the path <b>/</b> is found in the "source"
+field of the "objectname", "refobj", "refrel" and "refsort" tables, and that
+the first choice is preferred;<br>
+ </blockquote>
+ <ul>
+ <li><table_name> "<-" [ <path_component> ]*</li>
+ </ul>
+ <blockquote>the given path denotes a structured metadata whose components
+are found in the fields of the given table. For example:<br>
+ <br>
+refobj <- refObj<br>
+ <br>
+tells that the path <b>/"refObj"</b> denotes a structured metadata whose
+components are found in the fields of the table "refobj"; <br>
+ </blockquote>
+ <ul>
+ <li><table_name> "<+" [ <path_component> ]*</li>
+ </ul>
+ <blockquote>same as the previous but tells that this is a default correspondence;
+ <br>
+ </blockquote>
+ <ul>
+ <li><virtual_table_name> "->" <concrete_table_name></li>
+ </ul>
+ <blockquote>defines a correspondence between a virtual table name an
+a concrete table name. All the <table_name> entries represent virtual
+table names that are mapped to concrete table names using the identity function
+unless a particular mapping is defined for them using the above construction.
+This mechanism allows to define several set of metadata on the same database
+table as in:<br>
+ <br>
+refobj source
+ <-<br>
+refobj h_occurrence <-
+ refObj h:occurrence<br>
+backpointer source
+ <- backPointer h:occurrence<br>
+backpointer h_occurrence <-<br>
+backpointer
+ -> refobj<br>
+ </blockquote>
+ <blockquote>which defines four path accessing two virtual tables ("refobj"
+and "backpointer") and then maps these tables in a single concrete table;<br>
+ </blockquote>
+ <ul>
+ <li>"->" <br>
+ </li>
+ </ul>
+ <blockquote>a line like this must end the map file. <br>
+ </blockquote>
+Here you can find the <a
+ href="http://www.cs.unibo.it/cgi-bin/cvsweb/helm/mathql_db_map.txt">current
+version of PostgreSQL database map for HELM</a>.<br>
+ <br>
+ <b>How does the interpreter use the map?</b> The map file is read during
+the interpreter initialization process from the file pointed by the MATHQL_DB_MAP
+environment variable and is used during the execution of each <i>property</i>
+operation in the issued queries.When executing a <i>property</i> operation,
+the interpreter uses the map to find the smallest set of database tables
+containing the information required by the given access paths and then queries
+these tables to obtain the wanted information. <br>
+ </td>
+ </tr>
+
+ </tbody>