MathQL-1

• Forward
  

• Features

• What's new
  

• Documentation

• Implementation
  

• The authors
  

• Links
  

 MathQL-1 version 4 now under development ...

• A clear distinction between the core language and the auxiliary functions, which should be part of an extensible library.
  

• The elimination of the explicit casts between the <query> and <value> types in queries.
  

• A tight connection with a query generator (i.e HELM query generator).
  

• The add operator now accepts a syntax extension allowing to specify more than one explicit attribute group.

The syntax now is:

<query> := "add" [ "distr" ]? [ <groups> | <avar> ] "in" <query>
<groups> := <group> [ ";" <group> ]*
<group> := <attribute> [ "," <attribute> ]*
<attribute> := <value> "as" <path>

Examples:
the query add "1" as "a", "2" as "b" in subj "A" gives the result "A" attr {"a"="1"; "b"="2"} while
the query add "1" as "a"; "2" as "b" in subj "A" gives the result "A" attr {"a"="1"}, {"b"="2"}.

• The new align operator takes an integer i (represented as a string), a multiple string value v and returns the same v where each string with length n < i is prefixed with i - n spaces. The syntax of the add operator is:

<value> := "align" <string> "in" <value>

This operators aligns strings containing numbers so that their alphabetic order agrees with their numeric order.

• The intersect operator now intersects the attribute groups of the matching subject strings set-theoretically rather than making their "Cartesian product". This semantics reduces the computational costs and makes intersection the dual of union.

• The property operator now accepts more than one isfalse 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 HELM query generator.

• the database connection string to be used when the interpreter opens a connection with the database;

• the map describing the correspondence between the metadata access paths used by the property operator and the fields of the database tables.

• blank lines: ignored (used for separation);

• lines starting with a # followed by a space: ignored (used for comments);
  

• <table_name>  <field_name>  "<-"  [  <path_component>  ]*
  

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:

refobj  h_occurrence  <-  refObj  h:occurrence

tells that the metadata denoted by the path /"refObj"/"h:occurrence" is found in the field "h_occurrence" of the table "refobj" in the database, while:

refobj  source  <-

tells that the metadata denoted by the path / is found in the field "source" of the table "refobj" in the database;

• <table_name>  <field_name>  "<+"  [  <path_component>  ]*
  

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:

objectname  source  <+
refobj           source  <-
refrel            source  <-
refsort          source  <-

tells that the metadata denoted by the path / is found in the "source" field of the "objectname", "refobj", "refrel" and "refsort" tables, and that the first choice is preferred;

• <table_name>  "<-" [ <path_component>  ]*

the given path denotes a structured metadata whose components are found in the fields of the given table. For example:

refobj  <-  refObj

tells that the path /"refObj" denotes a structured metadata whose components are found in the fields of the table "refobj";

• <table_name>  "<+" [ <path_component>  ]*

same as the previous but tells that this is a default  correspondence;

• <virtual_table_name>  "->" <concrete_table_name>

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:

refobj           source             <-
refobj           h_occurrence  <-  refObj           h:occurrence
backpointer  source             <-  backPointer  h:occurrence
backpointer  h_occurrence  <-
backpointer                          ->  refobj

which defines four path accessing two virtual tables ("refobj" and "backpointer") and then maps these tables in a single concrete table;

• "->"
  

a line like this must end the map file.