helm/mathql/doc/mathql_overview.tex

   1 \section{Overview}
   2
   3 {\MathQL}%
   4 \footnote{See \URI{http://helm.cs.unibo.it/mathql}.}
   5 is a query language for {\RDF} \cite{RDF,RDFS} databases, developed in the
   6 context of the {\HELM}%
   7 \footnote{See \URI{http://helm.cs.unibo.it}.}
   8 project \cite{APSCGS03}.
   9 Its name suggests that it is supposed to be the first of a group of query
  10 languages for retrieving information from distributed digital libraries of
  11 formal mathematical knowledge, but no other languages of this proposal have
  12 been implemented yet except for {\MathQL} that is not Mathematics-oriented.
  13 So the name is a bit misleading.
  14
  15 \xcomment {
  16
  17 The MathQL proposal rises within the HELM project with the final aim of
  18 providing a set of query languages for digital libraries of formalized
  19 mathematical resources, capable of expressing content-aware requests.
  20
  21 This proposal has several domains of application and may be useful for
  22 database or on-line libraries reviewers, for proof assistants or
  23 proof-checking systems, and also for learning environments because these
  24 applications require features for classifying, searching and browsing
  25 mathematical information in a semantically meaningful way.
  26
  27 As the most natural way to handle content information about a resource is
  28 by means of metadata, our first task is providing a query language that we
  29 call MathQL level 1 (or {\MathQL} for short), suitable for a metadata
  30 framework.
  31 Other languages to be defined in the context of the MathQL proposal may be
  32 suitable for queries about the semantic structure of mathematical data:
  33 this includes content-based pattern-matching (MathQL-2) and possibly other
  34 forms of formal matching involving for instance isomorphism, unification and
  35 $\delta$-expansion%
  36 \footnote{by $\delta$-expansion we mean the expansion of definitions.}
  37 (MathQL-3).
  38
  39 In this perspective the role of a query on metadata can be that of producing a
  40 filtered knowledge base containing relevant information for subsequent queries
  41 of other kind.
  42
  43 }
  44
  45 {\MathQL} is carefully designed for making up for two limitations that seem to
  46 characterize several implementations and proposals of current {\RDF}-oriented
  47 query languages, namely the insufficient compliance with the most requested
  48 features and the poor attention paid to query result management.
  49 Thus the language has the following design goals:
  50
  51 \begin{enumerate}
  52
  53 \item
  54 compliance with the main requirements stated by the {\RDF} community;
  55
  56 \item
  57 native support for post-processing the query results;
  58
  59 \item
  60 {\HELM}-independent implementation of the query engine.
  61
  62 \end{enumerate}
  63
  64 We will briefly analyze these features in the remaining part of this
  65 section.
  66
  67 \subsubsection*{The main requirements from the RDF community}
  68
  69 As a query language for {\RDF} databases, {\MathQL} has a well-conceived
  70 semantics, defined in term of an abstract metadata model, according to which
  71 queries return exhaustive solutions.
  72 The language provides facilities for imposing query constraints based on
  73 {\RDFS} \cite{RDFS} and for the traversal of compound values of properties.
  74 It also provides a full set of Boolean operators to compose the query
  75 constraints and facilities for selecting resources or literals by means of
  76 {\POSIX} regular expressions.
  77 Moreover the language allows to customize the query results specifying what
  78 part of a solution should be preserved, and supports a machine-processable
  79 {\XML} \cite{XML} syntax as well as a human-readable textual syntax to achieve
  80 the best usability.
  81 The two syntaxes concern both queries and results, making {\MathQL} usable in
  82 a distributed environment where query engines are implemented as stand-alone
  83 components. This is because in this setting both queries and query results
  84 must be exchanged by the system's components and thus need to be encoded in
  85 clearly defined format.
  86
  87 {\MathQL} provides a graph-oriented access to the {\RDF} metadata, based on
  88 tree instantiation.
  89 This approach has the advantage of providing an abstraction over the
  90 concrete representation of the {\RDF} database (that can consist of {\RDF}
  91 triples and {\XML} files simultaneously) at the user level, and this is
  92 definitely desirable especially in a distributed context.
  93
  94 {\MathQL} query results are meant to capture the structure of trees coming
  95 from an {\RDF} graph and for this purpose a standard $1$- or $2$-dimensional
  96 organization (as provided by most {\RDF}-oriented query languages) is not
  97 satisfactory. Here {\MathQL} approach is to use a $4$-dimensional organization
  98 for its query results.
  99
 100 \subsubsection*{Post-processing and code generation capabilities}
 101
 102 The {\MathQL} query engine, that is written in {\CAML}%
 103 \footnote{See \URI{http://caml.inria.fr}.}
 104 for an easy integration with the {\HELM} software, provides two ways of
 105 processing the query results: at {\CAML} side and natively.
 106
 107 At {\CAML} side, an application issues a query calling a function of the
 108 engine and manipulates the result either operating directly on its internal
 109 representation (through a low-level interface), or using a set of dedicated
 110 functions specifically designed to manage the query results.
 111 This set of functions includes a basic library but is extensible depending
 112 on the {\CAML} modules included in the engine at compile-time. In this way
 113 an expert user can write a {\CAML} module with new dedicated functions and can
 114 include it in the engine recompiling it.
 115
 116 {\MathQL} supports native post-processing of the query results including the
 117 standard constructions of an imperative Turing-complete programming language,
 118 whose aim is definitely not that of being all-purpose (the user can work at
 119 {\CAML} side for that), but of being optimized for the management of the
 120 query results.
 121 In this context an {\SQL}-like ``select-from-where'' construction is provided
 122 (as required by the {\RDF} community) as well as a mechanism for accessing the
 123 post-processing dedicated functions available to the engine.
 124
 125 Moreover the language provides access to an extensible set of code-generating
 126 functions (also available at {\CAML} side) that the expert user can define
 127 writing suitable {\CAML} modules for the engine.
 128 Note that the generated code is always {\MathQL} code.
 129
 130 The code generation features allow to build complex queries incrementally and
 131 in an automatic manner, as required by the needs of the {\HELM} project.
 132 Using the native programming language, instead, queries can include the
 133 post-processing algorithms on their results so the querying code and the
 134 subsequent processing code (if needed) are treated together as a
 135 self-contained object that can be computed by a single engine.
 136 In this sense the alternative of performing a complex query on a remote
 137 component issuing some {\MathQL} querying code followed by some {\CAML}
 138 post-processing code is really infeasible in a distributed context.
 139
 140 \subsubsection*{Physical organization of the RDF database}
 141
 142 The implementation of the {\MathQL} query engine does not depend on any
 143 software developed within the {\HELM} project, nor it depends on the {\HELM}
 144 metadata model in any way.
 145
 146 However the engine does make few assumptions on the way metadata are
 147 physically organized and needs some user-provided knowledge about the concrete
 148 metadata representation.
 149 Metadata stored as {\RDF} triples are accessed through a {\MySQL}%
 150 \footnote{See \URI{http://www.mysql.com}.}
 151 or a {\PostgreSQL}%
 152 \footnote{See \URI{http://www.postgresql.org}.}
 153 engine, while metadata stored as {\RDF}/{\XML} files are accessed through a
 154 {\Galax}%
 155 \footnote{See \URI{http://db.bell-labs.com/galax/}.}
 156 {\XQuery} \cite{XQuery} engine.