X-Git-Url: http://matita.cs.unibo.it/gitweb/?a=blobdiff_plain;f=helm%2Fmathql%2Fhomepage%2Fwhatsnew.html;fp=helm%2Fmathql%2Fhomepage%2Fwhatsnew.html;h=0000000000000000000000000000000000000000;hb=1696761e4b8576e8ed81caa905fd108717019226;hp=1a15631ba5f1ba3ca03324c2eab1ba2c307a94cb;hpb=5325734bc2e4927ed7ec146e35a6f0f2b49f50c1;p=helm.git diff --git a/helm/mathql/homepage/whatsnew.html b/helm/mathql/homepage/whatsnew.html deleted file mode 100644 index 1a15631ba..000000000 --- a/helm/mathql/homepage/whatsnew.html +++ /dev/null @@ -1,328 +0,0 @@ - - - - MathQL - - - - - - - - - - -

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

-

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:
-
    -
  • 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"}.
-
- -
    -
  • 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.
-
-
-
- -