-
-
- What's new
-
-
+ - What's new
+
+
+
-
-
- Documentation - - +
- Documentation + +
-
-
- Implementation
-
-
+ - Implementation
+
+
+
-
-
- The authors
-
-
-
+ - The authors
+
+
+
-
+
What's new
-
-
- This page reports the newly implemented
-features of MathQL-1 that are not included in the ufficial
+
+ This page reports the newly implemented
+ features of MathQL-1 that are not included in the official documentation yet.-
-
-
-Changes and additions to MathQL-1 operators:
+
+ +
+
+ MathQL-1 version 4 now under development ...
+We are now implementing the new unstable version of MathQL-1 (i.e. MathQL-1.4).
+The main goals of this release are:+
-
+
- A clear distinction between the core language and the auxiliary
+functions, which should be part of an extensible library.
+
+
-
-
- The add operator now accepts a syntax extension allowing -to specify more than one explicit attribute group. +
- 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).
+
+
+
+
+
+ Changes and additions to MathQL-1 operators:
+-
+
- 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: + <groups> := <group> [ ";" <group> ]*
- 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: +
- 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 intersect operator now intersects the attribute groups -of the mathing subject strings set-theoretically rather than making their -"Cartesian product". This semantics reduces the computational costs and makes -intersection the dual of union. +
- the database connection string to be used when the interpreter + opens a connection with the database; +
- The property operator now accepts more than one isfalse
-clause to increase the complexity of the constraint condition used to filter
-the query results. This feature is exploited in the queries produced by the
- HELM query generator.
-
+ - 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> ]*
+
+
+ - <table_name> <field_name> "<+"
+ [ <path_component> ]*
+
+
+ - <table_name> "<-" [ <path_component> ]* +
+ <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"}.
+ + +
-
+
<value> := "align" <string> "in" <value>+ +
+
+ This operators aligns strings containing numbers so that their alphabetic + order agrees with their numeric order.
+
-
+
-
+
-This operators aligns strings containing numbers so that their alphabetic -order agrees with their numeric order.
- - + +
+
+
+ The PostgreSQL database map 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:The PostgreSQL database map:
++
-
-
-
-
+ The first line must contain the database connection string and the subsequent + lines contain the map with the following syntax:
+ +
-
+
-
+
-
+
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;
+
-
+
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;
+
-
+
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.+ Here you can find the current + version of PostgreSQL database map for HELM.
+
+
+ How does the interpreter use the map? 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 + property operation in the issued queries.When executing a property +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.
+ + + +