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
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
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} 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}%
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
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