MathQL-1

A query language for RDF metadata

  • What's new

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.