mathql/doc/mathql_introduction_property.tex

   1 \subsection{High level access to metadata} \label{HighAccess}
   2
   3 {\MathQL} high level access to an {\RDF} database is \emph{graph-oriented} and
   4 is delegated to its \TT{property} operator that builds a \emph{result} {\av}
   5 set starting from two mandatory arguments: the \emph{source} {\av} set and the
   6 \emph{head path}.
   7 Other optional arguments may be used to change its default behaviour or to
   8 request advanced functionalities.
   9
  10 This operator has the following syntax, where a path has the structure of an
  11 attribute name ({\ie} a list of strings) and denotes a (possibly empty) finite
  12 sequence of contiguous arcs (describing properties in the {\RDF} graph%
  13 \footnote
  14 {When we say \emph{{\RDF} graph}, we actually mean both the {\RDFM} graph and
  15 the {\RDFS} graph.}%
  16 ).
  17
  18 \begin{center}
  19 \TT{property} \EM{optional-flags} \EM{head-path} \EM{optional-clauses} \TT{of}
  20 \EM{optional-flag} \EM{av-set}
  21 \end{center}
  22
  23 \begin{figure}
  24 \begin{footnotesize} \begin{verbatim}
  25  These examples refer to the resources "A" and "B" of Figure 2.
  26
  27 Example 1: reading an unstructured property - simple case:
  28  property /"id"/"major" of {"A", "B"} gives "1"
  29  property /"id"/"minor" of {"A", "B"} gives "2"; "7"
  30
  31 Example 2: reading an unstructured property - use of pattern:
  32  property /"id"/"minor" of pattern ".*" gives "2"; "7"
  33
  34 Example 3: reading a structured property without main component:
  35  property /"id" attr /"major", /"minor" of {"A", "B"}
  36  generates the following attributed values:
  37  "" attr {/"major" = "1"; /"minor" = "2"};
  38  "" attr {/"major" = "1"; /"minor" = "7"}
  39  that are composed with the set-theoretic union giving:
  40  "" attr {/"major" = "1"; /"minor" = "2"},
  41          {/"major" = "1"; /"minor" = "7"}
  42
  43 Example 4: reading a structured property specifying a main component:
  44  property /"id" main /"major" attr /"minor" of {"A", "B"} gives
  45  "1" attr {/"minor" = "2"}, {/"minor" = "7"}
  46
  47 Example 5: the renaming mechanism:
  48  property /"id" attr /"minor" as /"new-name" of {"A", "B"} gives
  49  "" attr {/"new-name" = "2"}, {/"new-name" = "7"}
  50
  51 Example 6: imposing constraints on property values:
  52  property /"date" istrue /"first" in "2002-01-01"
  53                   attr /"modified" of {"A", "B"} and
  54  property /"date" istrue /"first" match ".*01.*"
  55                   attr /"modified" of {"A", "B"} give
  56  "" attr {/"modified" = "2002-03-01"}
  57  Only the instance of "date" with "first" set to "2002-01-01"
  58   is considered.
  59
  60 Example 7: inverse traversal of the head path:
  61 property inverse /"date" attr /"first" in "" gives
  62 "A" attr {/"first" = "2002-01-01"}; "B" attr {/"first" = "2002-02-01"}
  63
  64 Example 8: some triples of an access relation:
  65 The triples formalizing the property "date" of the resource "A":
  66 ("A", /"date", "");
  67 ("A", /"date"/"first", "2002-01-01");
  68 ("A", /"date"/"modified", "2002-03-01")
  69 \end{verbatim} \end{footnotesize}
  70 \vspace{-1pc}
  71 \caption{The ``property'' operator}
  72 \label{Property}
  73 \end{figure}
  74
  75 In the simplest case \TT{property} is used to read the values of a (possibly
  76 compound) property with an unstructured value and does the following:
  77
  78 \begin{enumerate}
  79
  80 \item
  81 It computes the instances of the given path in the {\RDF} graph available to
  82 the query engine, using the resources specified in the head strings of the
  83 source {\av} set (call them source resources) as start-nodes.
  84
  85 \item
  86 The computation gives a set of nodes ({\ie} the end-nodes of the instantiated
  87 paths) which are the values of the instances of the (possibly compound)
  88 property specified by the path and concerning the source resources.
  89
  90 \item
  91 These values, encoded into {\av}'s as explained above, are composed by means
  92 of the {\MathQL} set-theoretic union to form the result {\av} set.
  93
  94 \end{enumerate}
  95
  96 \figref{Property} (example 1) shows an instance of this procedure.
  97 Note that the result sets of this example have no attributes and that a path
  98 is represented by a slash-separated list of strings denoting the path's arcs.%
  99 \footnote{If needed, the empty path is represented by a single slash.}
 100
 101 Using the \TT{pattern} flag, \TT{property} can be instructed to regard the
 102 values of the source {\av} set as POSIX regular expressions rather than as
 103 constant strings.
 104 In this case \TT{pattern} selects the set of resources matching at least one
 105 of the given expressions.
 106 See for instance \figref{Property} (example 2).
 107
 108 If we want to read the value of a structured property we can specify the
 109 value's main component in the \TT{main} \EM{optional-clause} (this
 110 specification overrides the default setting inferred from the {\RDF} graph
 111 through the \emph{rdf:value} property) and the list of the value's secondary
 112 components in the \TT{attr} \EM{optional-clause}.
 113
 114 Note that if a secondary component is not listed in the \TT{attr} clause, it
 115 will not be read.
 116 Also recall that, when the result {\av}'s are formed, the main component is
 117 is read in the head string, whereas the secondary components are
 118 encoded using the attributes of a single group.
 119 See for instance \figref{Property} (examples 3 and 4).
 120 As a component of a property's value may be a structured property, its
 121 specification (appearing in the \TT{main} or \TT{attr} clause) is
 122 actually a path in the {\RDF} graph starting from the end-node of the head
 123 path.
 124
 125 Note that the name of an attribute, which by default is its defining path in
 126 the \TT{attr} clause, can be changed with an optional \TT{as} clause for the
 127 user's convenience. See for instance \figref{Property} (example 5).
 128 Note that the assigned name must be a path for typing reasons.
 129 The alternative could be to use a simple string but in any case a string can
 130 be seen as a one-element path.
 131
 132 In the default case \TT{property} builds its result considering every
 133 component of the {\RDFM} graph ({\ie} every {\RDFM}) but we can constrain
 134 some nodes of the inspected components to have (or not to have) a given value,
 135 with the aim of improving the performance of the inspection procedure.
 136 The constrained nodes are specified in the \TT{istrue} and \TT{istrue}
 137 \EM{optional-clauses} and the constraining values are expressed by \TT{in} or
 138 \TT{match} constructions depending on their semantics (constant values or
 139 POSIX regular expressions respectively).
 140 See for instance \figref{Property} (example 6).
 141 Again a constrained node may be the value of a compound property, therefore
 142 its specification (appearing in the \TT{istrue} or \TT{isfalse} clause) is
 143 a path in the {\RDF} graph starting from the end-node of the head path.
 144
 145 \TT{property} allows to access the {\RDFS} property hierarchy by specifying
 146 a flag \TT{sub} or \TT{super}.
 147 If the \TT{sub} flag is present, \TT{property} inspects the instances of the
 148 default tree (made by the head path and by the \EM{optional-clauses} paths)
 149 and every other tree obtained by substituting an arc $ p $ with the arc of a
 150 subproperty of $ p $.
 151 If the \TT{super} flag is present, super-property arcs are substituted instead.
 152
 153 \TT{property} also allows the inverse traversal of its head path if the
 154 \TT{inverse} flag is specified.
 155 In this case the operator works as follows:
 156
 157 \begin{enumerate}
 158
 159 \item
 160 It instantiates the head path using as end-nodes the values whose main
 161 component is specified in head strings of the source {\av} set.
 162
 163 \item
 164 It encodes the resources corresponding to the instances of the start-nodes into
 165 {\av}'s assigning the attributes obtained instantiating the attribute paths%
 166 \footnote{The paths in the \EM{optional-clauses} are never traversed backward.}
 167 and builds the result set composing these {\av}'s with the set-theoretic union.
 168
 169 \end{enumerate}
 170
 171 See for instance \figref{Property} (example 7).
 172
 173 Formally \TT{property} accesses the {\RDF} graph through an \emph{access
 174 relation} which is a set of triples $ (r_1, p, r_2) $ where $ r_1 $ and
 175 $ r_2 $ are strings, and $ p $ is a path.
 176 Each triple is a sort of ``extended {\RDF} triple'' in the sense that $ r_1 $
 177 is a resource for which some metadata is provided, $ p $ is a path in the
 178 {\RDF} graph and $ r_2 $ is the main value of the end-node of the instance of
 179 $ p $ starting from $ r_1 $ (this includes the instances of sub- and
 180 super-arcs of $ p $ if necessary).
 181 See for instance \figref{Property} (example 8).
 182 {\MathQL} does not provide for any built-in access relation so any query
 183 engine can freely define the access relations that are appropriate with
 184 respect to the metadata it can access.
 185
 186 It is worth remarking, as it was already stressed in \cite{Gui03,GS03}, that
 187 the concept of access relation corresponds to the abstract concept of property
 188 in the basic {\RDF} data model which draws on well established principles from
 189 various data representation communities.
 190 In this sense an {\RDF} property can be thought of either as an attribute of a
 191 resource (traditional attribute-value pairs model), or as a relation between
 192 a resource and a value (entity-relationship model).
 193 This observation leads us to conclude that {\MathQL} is sound and complete
 194 with respect to querying an abstract {\RDF} metadata model.
 195 Finally note that access relations are close to {\RDF} entity-relationship
 196 model, but they do not work if we allow paths with an arbitrary number of
 197 loops ({\ie} with an arbitrary length) because this would lead to creating
 198 infinite sets of triples.
 199 If we want to handle this case, we need to turn these relations into
 200 multivalued functions.