helm/mathql/doc/mathql.tex

   1 \documentclass[10pt]{article}
   2
   3 % \usepackage{fguidi}
   4 \addtolength{\textheight}{2.5cm}
   5 \addtolength{\oddsidemargin}{-1.0cm}
   6 \addtolength{\evensidemargin}{-1.0cm}
   7 \addtolength{\textwidth}{2.0cm}
   8 \addtolength{\topmargin}{-1.0cm}
   9
  10 \newcommand{\MathQL}{\textsc{mathql-1}}
  11 \newcommand{\RDF}{\textsc{rdf}}
  12 \newcommand{\RDFS}{\textsc{rdf schema}}
  13 \newcommand{\HELM}{\textsc{helm}}
  14 \newcommand{\POSIX}{\textsc{posix}}
  15 \newcommand{\XML}{\textsc{xml}}
  16 \newcommand{\CAML}{\textsc{caml}}
  17 \newcommand{\SQL}{\textsc{sql}}
  18 \newcommand{\PostgreSQL}{\textsc{postgresql}}
  19 \newcommand{\Galax}{\textsc{galax}}
  20 \newcommand{\XQuery}{\textsc{xquery}}
  21
  22 \title{MathQL-1.4}
  23 \author{Ferruccio Guidi}
  24
  25 \begin{document}
  26
  27 \maketitle
  28
  29 \section{Overview}
  30
  31 {\MathQL} is a query language for {\RDF} databases, developed in the context
  32 of the {\HELM} project. Its name suggests that it is supposed to be the first
  33 of a group of query languages for retrieving information from distributed
  34 digital libraries of formal mathematical knowledge, but no other languages of
  35 this group have been implemented yet except for {\MathQL} that is not
  36 Mathematics-oriented. So the name is a bit misleading.
  37
  38 {\MathQL} is carefully designed for having the following features:
  39
  40 \begin{enumerate}
  41
  42 \item
  43 compliance with the main requirements stated by the {\RDF} community;
  44
  45 \item
  46 native support for post-processing the query results;
  47
  48 \item
  49 {\HELM}-independent implementation of the query engine.
  50
  51 \end{enumerate}
  52
  53 We will briefly analyze these features in the remaining part of this section.
  54
  55 \subsubsection*{The main requirements from the RDF community}
  56
  57 As a query language for {\RDF} databases, {\MathQL} has a well-conceived
  58 semantics, defined in term of an abstract metadata model, according to which
  59 queries return exhaustive solutions.
  60 The language provides facilities for imposing query constraints based on
  61 {\RDFS} and for the traversal of compound values of properties.
  62 It also provides a full set of Boolean operators to compose the query
  63 constraints and facilities for selecting resources or literals by means of
  64 {\POSIX} regular expressions.
  65 Moreover the language allows to customize the query results specifying what
  66 part of a solution should be preserved, and supports a machine-processable
  67 {\XML} syntax as well as a human-readable textual syntax to achieve the best
  68 usability.
  69
  70 The two syntaxes concern both queries and results, making {\MathQL} usable in
  71 a distributed environment where query engines are implemented as stand-alone
  72 components. This is because in this setting both queries and query results
  73 must be exchanged by the system's components and thus need to be encoded in
  74 clearly defined format.
  75
  76 {\MathQL} provides a graph-oriented access to the {\RDF} metadata, based on
  77 tree instantiation.
  78 This approach has the advantage of providing an abstraction over the
  79 concrete representation of the {\RDF} database (that can consist of {\RDF}
  80 triples and {\XML} files simultaneously) at the user level, and this is
  81 definitely desirable especially in a distributed context.
  82
  83 {\MathQL} query results are meant to capture the structure of trees coming
  84 from an {\RDF} graph and for this purpose a standard $1$- or $2$-dimensional
  85 organization (as provided by most {\RDF}-oriented query languages) is not
  86 satisfactory. Here {\MathQL} approach is to use a $4$-dimensional organization
  87 for its query results.
  88
  89 \subsubsection*{Post-processing and code generation capabilities}
  90
  91 The {\MathQL} query engine, that is written in {\CAML} for an easy integration
  92 with the {\HELM} software, provides two ways of processing the query results:
  93 at {\CAML} side and natively.
  94
  95 At {\CAML} side, an application issues a query calling a function of the
  96 engine and manipulates the result either operating directly on its internal
  97 representation (that is placed in the public scope), or using a set of
  98 dedicated functions specifically designed to manage the query results.
  99 This set of functions includes a basic library but is extensible depending
 100 on the {\CAML} modules included in the engine at compile-time. In this way
 101 an expert user can write a {\CAML} module with new dedicated functions and can
 102 include it in the engine recompiling it.
 103
 104 {\MathQL} supports native post-processing of the query results including the
 105 standard constructions of an imperative Turing-complete programming language,
 106 whose aim is definitely not that of being all-purpose (the user can work at
 107 {\CAML} side for that), but of being optimized for the management of the
 108 query results.
 109 In this context an {\SQL}-like ``select-from-where'' construction is provided
 110 (as required by the {\RDF} community) as well as a mechanism for accessing the
 111 post-processing dedicated functions available to the engine.
 112
 113 Moreover the language provides access to an extensible set of code-generating
 114 functions (also available at {\CAML} side) that the expert user can define
 115 writing suitable {\CAML} modules for the engine.
 116 Note that the generated code is always {\MathQL} code.
 117
 118 The code generation features allow to build complex queries incrementally and
 119 in an automatic manner, as required by the needs of the {\HELM} project.
 120 Using the native programming language, instead, queries can include the
 121 post-processing algorithms on their results so the querying code and the
 122 subsequent processing code (if needed) are treated together as a
 123 self-contained object that can be computed by a single engine.
 124 In this sense the alternative of performing a complex query on a remote
 125 component issuing some {\MathQL} querying code followed by some {\CAML}
 126 post-processing code is really infeasible in a distributed context.
 127
 128 \subsubsection*{Physical organization of the RDF database}
 129
 130 The implementation of the {\MathQL} query engine does not depend on any
 131 software developed within the {\HELM} project, nor it depends on the {\HELM}
 132 metadata model in any way.
 133
 134 However the engine does make few assumptions on the way metadata are
 135 physically organized and needs some user-provided knowledge about the concrete
 136 metadata representation.
 137 Metadata stored as {\RDF} triples are accessed through a {\PostgreSQL} engine,
 138 while metadata stored as {\RDF}/{\XML} files are accessed through a {\Galax}
 139 {\XQuery} engine.
 140
 141 \end{document}