ocaml 3.09 transition

[helm.git] / helm / mathql / doc / mathql_overview.tex

diff --git a/helm/mathql/doc/mathql_overview.tex b/helm/mathql/doc/mathql_overview.tex
index 6d59b55fa92dcbeb5ef1abc20cb2d66704e69880..45fd2cb99f366fe50ea2a38ada18660058cd6219 100644 (file)
--- a/helm/mathql/doc/mathql_overview.tex
+++ b/helm/mathql/doc/mathql_overview.tex
@@ -16,7 +16,6 @@ database or on-line libraries reviewers, for proof assistants or
 proof-checking systems, and also for learning environments because these
 applications require features for classifying, searching and browsing
 mathematical information in a semantically meaningful way.
 proof-checking systems, and also for learning environments because these
 applications require features for classifying, searching and browsing
 mathematical information in a semantically meaningful way.

-

 Other languages to be defined in the context of the MathQL proposal may be
 suitable for queries about the semantic structure of mathematical data:
 this includes content-based pattern-matching and possibly other forms of
 Other languages to be defined in the context of the MathQL proposal may be
 suitable for queries about the semantic structure of mathematical data:
 this includes content-based pattern-matching and possibly other forms of


@@ -50,6 +49,8 @@ native support for post-processing the query results;
 We will briefly analyze these features in the remaining part of this
 section.
 
 We will briefly analyze these features in the remaining part of this
 section.
 

+\vspace{-1pc}
+

 \subsubsection*{The main requirements from the RDF community}
 
 As a query language for {\RDF} databases, {\MathQL} has a well-conceived
 \subsubsection*{The main requirements from the RDF community}
 
 As a query language for {\RDF} databases, {\MathQL} has a well-conceived


@@ -66,9 +67,8 @@ part of a solution should be preserved, and supports a machine-processable
 the best usability.
 The two syntaxes concern both queries and results, making {\MathQL} usable in
 a distributed environment where query engines are implemented as stand-alone
 the best usability.
 The two syntaxes concern both queries and results, making {\MathQL} usable in
 a distributed environment where query engines are implemented as stand-alone

-components. This is because in this setting both queries and query results
-must be exchanged by the system's components and thus need to be encoded in
-clearly defined format.
+components. In this setting in fact both the queries and their results must be
+exchanged by the system's components and thus need to be clearly encoded.

 
 {\MathQL} provides a graph-oriented access to the {\RDF} metadata, based on
 tree instantiation.
 
 {\MathQL} provides a graph-oriented access to the {\RDF} metadata, based on
 tree instantiation.


@@ -80,9 +80,11 @@ definitely desirable especially in a distributed context.
 {\MathQL} query results are meant to capture the structure of trees coming
 from an {\RDF} graph and for this purpose a standard $1$- or $2$-dimensional
 organization (as provided by most {\RDF}-oriented query languages) is not
 {\MathQL} query results are meant to capture the structure of trees coming
 from an {\RDF} graph and for this purpose a standard $1$- or $2$-dimensional
 organization (as provided by most {\RDF}-oriented query languages) is not

-satisfactory. Here {\MathQL} approach is to use a $4$-dimensional organization
+satisfactory. {\MathQL} approach is to use a $4$-dimensional organization

 for its query results.
 
 for its query results.
 

+\vspace{-1pc}
+

 \subsubsection*{Post-processing and code generation capabilities}
 
 The {\MathQL} query engine, that is written in {\CAML}%
 \subsubsection*{Post-processing and code generation capabilities}
 
 The {\MathQL} query engine, that is written in {\CAML}%


@@ -112,7 +114,6 @@ Moreover the language provides access to an extensible set of code-generating
 functions (also available at {\CAML} side) that the expert user can define
 writing suitable {\CAML} modules for the engine.
 Note that the generated code is always {\MathQL} code.
 functions (also available at {\CAML} side) that the expert user can define
 writing suitable {\CAML} modules for the engine.
 Note that the generated code is always {\MathQL} code.

-

 The code generation features allow to build complex queries incrementally and
 in an automatic manner, as required by the needs of the {\HELM} project.
 Using the native programming language, instead, queries can include the
 The code generation features allow to build complex queries incrementally and
 in an automatic manner, as required by the needs of the {\HELM} project.
 Using the native programming language, instead, queries can include the


@@ -123,6 +124,8 @@ In this sense the alternative of performing a complex query on a remote
 component issuing some {\MathQL} querying code followed by some {\CAML}
 post-processing code is really infeasible in a distributed context.  
 
 component issuing some {\MathQL} querying code followed by some {\CAML}
 post-processing code is really infeasible in a distributed context.  
 

+\vspace{-1pc}
+

 \subsubsection*{Physical organization of the RDF database}
 
 The implementation of the {\MathQL} query engine does not depend on any
 \subsubsection*{Physical organization of the RDF database}
 
 The implementation of the {\MathQL} query engine does not depend on any