|
What's new
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:
- 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 PostgreSQL database map:
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 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.
The format of the file is textual and line oriented, but a corresponding
XML syntax will be provided soon.
The first line must contain the database connection string and the subsequent
lines contain the map with the following syntax:
- 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.
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.
|