X-Git-Url: http://matita.cs.unibo.it/gitweb/?a=blobdiff_plain;f=helm%2Fmathql%2Fhomepage%2Fwhatsnew.html;h=1a15631ba5f1ba3ca03324c2eab1ba2c307a94cb;hb=97c2d258a5c524eb5c4b85208899d80751a2c82f;hp=e00096b641cb838c1f80638ce34da99f12e6cc9b;hpb=686e22323249fbfdaf21f53b5a11fe73df52f3b9;p=helm.git diff --git a/helm/mathql/homepage/whatsnew.html b/helm/mathql/homepage/whatsnew.html index e00096b64..1a15631ba 100644 --- a/helm/mathql/homepage/whatsnew.html +++ b/helm/mathql/homepage/whatsnew.html @@ -3,267 +3,326 @@ MathQL - + - + - + - +

MathQL-1

- -

A query language for RDF metadata

+

A query language for RDF metadata

+ - - - + + - + - - - + 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.
+ + + +
- +
+ + - - + + - +
    -
  • What's new
    -
    • - - +
  • What's new
    +
    • + +
- - - 		- +
+ 		+
What's new
-
-
- This page reports the newly implemented - features of MathQL-1 that are not included in the official + + 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:

-
+
+

+

New +  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:
    -
  • The add operator now accepts a syntax extension allowing - to specify more than one explicit attribute group.
    • - +
  • 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.
    +
    • +
+ +
+
+

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"}.
-
- + <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:
    • - +
  • 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.
-
- +
+ 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 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 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 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 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 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:
+ 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);
    • +
  • blank lines: ignored (used for separation);
    • +
+
    -
  • lines starting with a # followed by a space: ignored (used for -comments);
    -
    • +
  • lines starting with a # followed by a space: ignored (used +for comments);
    +
    • +
+
    -
  • <table_name>  <field_name>  "<-"  -[  <path_component>  ]*
    -
    • +
  • <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 + 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;
-
+
+ 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>  ]*
    -
    • +
  • <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;
-
+ 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>  ]*
    • +
  • <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";
-
+ 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>  ]*
    • +
  • <table_name>  "<+" [ <path_component>  ]*
    • +
+
same as the previous but tells that this is a default  correspondence; -
-
+
+ +
    -
  • <virtual_table_name>  "->" <concrete_table_name>
    • +
  • <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
-
+ 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;
-
+ 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 + 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.
-
-
+
+