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 761b688cb070cbac3b2f7d82dc90f51beeb20ea3..45fd2cb99f366fe50ea2a38ada18660058cd6219 100644 (file)
--- a/helm/mathql/doc/mathql_overview.tex
+++ b/helm/mathql/doc/mathql_overview.tex
@@ -1,10 +1,10 @@
 \section{Overview}
 
 {\MathQL}%
-\footnote{See \URI{http://helm.cs.unibo.it/mathql}.}
+\footnote{See \CURI{http://helm.cs.unibo.it/mathql}.}
 is a query language for {\RDF} \cite{RDF,RDFS} databases, developed in the
 context of the {\HELM}%
-\footnote{See \URI{http://helm.cs.unibo.it}.} 
+\footnote{See \CURI{http://helm.cs.unibo.it}.} 
 project \cite{APSCGS03}.
 Its name suggests that it is supposed to be the first of a group of query
 languages for retrieving information from distributed digital libraries of
@@ -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.
-
 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.
 
+\vspace{-1pc}
+
 \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
-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.
@@ -80,13 +80,15 @@ 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
-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.
 
+\vspace{-1pc}
+
 \subsubsection*{Post-processing and code generation capabilities}
 
 The {\MathQL} query engine, that is written in {\CAML}%
-\footnote{See \URI{http://caml.inria.fr}.}
+\footnote{See \CURI{http://caml.inria.fr}.}
 for an easy integration with the {\HELM} software, provides two ways of
 processing the query results: at {\CAML} side and natively.
 
@@ -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.
-
 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.  
 
+\vspace{-1pc}
+
 \subsubsection*{Physical organization of the RDF database}
 
 The implementation of the {\MathQL} query engine does not depend on any
@@ -133,10 +136,10 @@ However the engine does make few assumptions on the way metadata are
 physically organized and needs some user-provided knowledge about the concrete
 metadata representation.   
 Metadata stored as {\RDF} triples are accessed through a {\MySQL}%
-\footnote{See \URI{http://www.mysql.com}.}
+\footnote{See \CURI{http://www.mysql.com}.}
 or a {\PostgreSQL}%
-\footnote{See \URI{http://www.postgresql.org}.}
+\footnote{See \CURI{http://www.postgresql.org}.}
 engine, while metadata stored as {\RDF}/{\XML} files are accessed through a
 {\Galax}%
-\footnote{See \URI{http://db.bell-labs.com/galax/}.}
+\footnote{See \CURI{http://db.bell-labs.com/galax/}.}
 {\XQuery} \cite{XQuery} engine.