X-Git-Url: http://matita.cs.unibo.it/gitweb/?a=blobdiff_plain;ds=sidebyside;f=helm%2Fmathql%2Fhomepage%2Fwhatsnew.html;h=e00096b641cb838c1f80638ce34da99f12e6cc9b;hb=60c7321771851b82493bb202185ee184f1e7a3d1;hp=66285b900560aa12c8fc283eacb591f4c744ccd1;hpb=61519a6ef507c1319be96c2f4a06e059fb61cf44;p=helm.git diff --git a/helm/mathql/homepage/whatsnew.html b/helm/mathql/homepage/whatsnew.html index 66285b900..e00096b64 100644 --- a/helm/mathql/homepage/whatsnew.html +++ b/helm/mathql/homepage/whatsnew.html @@ -2,127 +2,268 @@ MathQL - + + - + - + - +

MathQL-1

- -

A query language for RDF metadata

+

A query language for RDF metadata

+ - - - + + - + - - - +
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.
+ + + +
- +
+ - - - +
    -
  • 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 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:
+
+
+
+

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 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>
+ <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

-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"}.
+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;
    -
  • 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:
  • +
  • <table_name>  <field_name>  "<+"  +[  <path_component>  ]*
    +
-
<value> := "align" <string> "in" <value>
+
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;
-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 mathing subject strings set-theoretically rather than making their -"Cartesian product". This semantics reduces the computational costs and makes -intersection the dual of union.
  • +
  • <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;
+
    -
  • 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.
    +
  • "->"
-
-
+