+++ /dev/null
-\subsection{High level access to metadata} \label{HighAccess}
-
-{\MathQL} high level access to an {\RDF} database is \emph{graph-oriented} and
-is delegated to its \TT{property} operator that builds a \emph{result} {\av}
-set starting from two mandatory arguments: the \emph{source} {\av} set and the
-\emph{head path}.
-Other optional arguments may be used to change its default behaviour or to
-request advanced functionalities.
-
-This operator has the following syntax, where a path has the structure of an
-attribute name ({\ie} a list of strings) and denotes a (possibly empty) finite
-sequence of contiguous arcs (describing properties in the {\RDF} graph%
-\footnote
-{When we say \emph{{\RDF} graph}, we actually mean both the {\RDFM} graph and
-the {\RDFS} graph.}%
-).
-
-\begin{center}
-\TT{property} \EM{optional-flags} \EM{head-path} \EM{optional-clauses} \TT{of}
-\EM{optional-flag} \EM{av-set}
-\end{center}
-
-\begin{figure}
-\begin{footnotesize} \begin{verbatim}
- These examples refer to the resources "A" and "B" of Figure 2.
-
-Example 1: reading an unstructured property - simple case:
- property /"id"/"major" of {"A", "B"} gives "1"
- property /"id"/"minor" of {"A", "B"} gives "2"; "7"
-
-Example 2: reading an unstructured property - use of pattern:
- property /"id"/"minor" of pattern ".*" gives "2"; "7"
-
-Example 3: reading a structured property without main component:
- property /"id" attr /"major", /"minor" of {"A", "B"}
- generates the following attributed values:
- "" attr {/"major" = "1"; /"minor" = "2"};
- "" attr {/"major" = "1"; /"minor" = "7"}
- that are composed with the set-theoretic union giving:
- "" attr {/"major" = "1"; /"minor" = "2"},
- {/"major" = "1"; /"minor" = "7"}
-
-Example 4: reading a structured property specifying a main component:
- property /"id" main /"major" attr /"minor" of {"A", "B"} gives
- "1" attr {/"minor" = "2"}, {/"minor" = "7"}
-
-Example 5: the renaming mechanism:
- property /"id" attr /"minor" as /"new-name" of {"A", "B"} gives
- "" attr {/"new-name" = "2"}, {/"new-name" = "7"}
-
-Example 6: imposing constraints on property values:
- property /"date" istrue /"first" in "2002-01-01"
- attr /"modified" of {"A", "B"} and
- property /"date" istrue /"first" match ".*01.*"
- attr /"modified" of {"A", "B"} give
- "" attr {/"modified" = "2002-03-01"}
- Only the instance of "date" with "first" set to "2002-01-01"
- is considered.
-
-Example 7: inverse traversal of the head path:
-property inverse /"date" attr /"first" in "" gives
-"A" attr {/"first" = "2002-01-01"}; "B" attr {/"first" = "2002-02-01"}
-
-Example 8: some triples of an access relation:
-The triples formalizing the property "date" of the resource "A":
-("A", /"date", "");
-("A", /"date"/"first", "2002-01-01");
-("A", /"date"/"modified", "2002-03-01")
-\end{verbatim} \end{footnotesize}
-\vspace{-1pc}
-\caption{The ``property'' operator}
-\label{Property}
-\end{figure}
-
-In the simplest case \TT{property} is used to read the values of a (possibly
-compound) property with an unstructured value and does the following:
-
-\begin{enumerate}
-
-\item
-It computes the instances of the given path in the {\RDF} graph available to
-the query engine, using the resources specified in the head strings of the
-source {\av} set (call them source resources) as start-nodes.
-
-\item
-The computation gives a set of nodes ({\ie} the end-nodes of the instantiated
-paths) which are the values of the instances of the (possibly compound)
-property specified by the path and concerning the source resources.
-
-\item
-These values, encoded into {\av}'s as explained above, are composed by means
-of the {\MathQL} set-theoretic union to form the result {\av} set.
-
-\end{enumerate}
-
-\figref{Property} (example 1) shows an instance of this procedure.
-Note that the result sets of this example have no attributes and that a path
-is represented by a slash-separated list of strings denoting the path's arcs.%
-\footnote{If needed, the empty path is represented by a single slash.}
-
-Using the \TT{pattern} flag, \TT{property} can be instructed to regard the
-values of the source {\av} set as POSIX regular expressions rather than as
-constant strings.
-In this case \TT{pattern} selects the set of resources matching at least one
-of the given expressions.
-See for instance \figref{Property} (example 2).
-
-If we want to read the value of a structured property we can specify the
-value's main component in the \TT{main} \EM{optional-clause} (this
-specification overrides the default setting inferred from the {\RDF} graph
-through the \emph{rdf:value} property) and the list of the value's secondary
-components in the \TT{attr} \EM{optional-clause}.
-
-Note that if a secondary component is not listed in the \TT{attr} clause, it
-will not be read.
-Also recall that, when the result {\av}'s are formed, the main component is
-is read in the head string, whereas the secondary components are
-encoded using the attributes of a single group.
-See for instance \figref{Property} (examples 3 and 4).
-As a component of a property's value may be a structured property, its
-specification (appearing in the \TT{main} or \TT{attr} clause) is
-actually a path in the {\RDF} graph starting from the end-node of the head
-path.
-
-Note that the name of an attribute, which by default is its defining path in
-the \TT{attr} clause, can be changed with an optional \TT{as} clause for the
-user's convenience. See for instance \figref{Property} (example 5).
-Note that the assigned name must be a path for typing reasons.
-The alternative could be to use a simple string but in any case a string can
-be seen as a one-element path.
-
-In the default case \TT{property} builds its result considering every
-component of the {\RDFM} graph ({\ie} every {\RDFM}) but we can constrain
-some nodes of the inspected components to have (or not to have) a given value,
-with the aim of improving the performance of the inspection procedure.
-The constrained nodes are specified in the \TT{istrue} and \TT{istrue}
-\EM{optional-clauses} and the constraining values are expressed by \TT{in} or
-\TT{match} constructions depending on their semantics (constant values or
-POSIX regular expressions respectively).
-See for instance \figref{Property} (example 6).
-Again a constrained node may be the value of a compound property, therefore
-its specification (appearing in the \TT{istrue} or \TT{isfalse} clause) is
-a path in the {\RDF} graph starting from the end-node of the head path.
-
-\TT{property} allows to access the {\RDFS} property hierarchy by specifying
-a flag \TT{sub} or \TT{super}.
-If the \TT{sub} flag is present, \TT{property} inspects the instances of the
-default tree (made by the head path and by the \EM{optional-clauses} paths)
-and every other tree obtained by substituting an arc $ p $ with the arc of a
-subproperty of $ p $.
-If the \TT{super} flag is present, super-property arcs are substituted instead.
-
-\TT{property} also allows the inverse traversal of its head path if the
-\TT{inverse} flag is specified.
-In this case the operator works as follows:
-
-\begin{enumerate}
-
-\item
-It instantiates the head path using as end-nodes the values whose main
-component is specified in head strings of the source {\av} set.
-
-\item
-It encodes the resources corresponding to the instances of the start-nodes into
-{\av}'s assigning the attributes obtained instantiating the attribute paths%
-\footnote{The paths in the \EM{optional-clauses} are never traversed backward.}
-and builds the result set composing these {\av}'s with the set-theoretic union.
-
-\end{enumerate}
-
-See for instance \figref{Property} (example 7).
-
-Formally \TT{property} accesses the {\RDF} graph through an \emph{access
-relation} which is a set of triples $ (r_1, p, r_2) $ where $ r_1 $ and
-$ r_2 $ are strings, and $ p $ is a path.
-Each triple is a sort of ``extended {\RDF} triple'' in the sense that $ r_1 $
-is a resource for which some metadata is provided, $ p $ is a path in the
-{\RDF} graph and $ r_2 $ is the main value of the end-node of the instance of
-$ p $ starting from $ r_1 $ (this includes the instances of sub- and
-super-arcs of $ p $ if necessary).
-See for instance \figref{Property} (example 8).
-{\MathQL} does not provide for any built-in access relation so any query
-engine can freely define the access relations that are appropriate with
-respect to the metadata it can access.
-
-It is worth remarking, as it was already stressed in \cite{Gui03,GS03}, that
-the concept of access relation corresponds to the abstract concept of property
-in the basic {\RDF} data model which draws on well established principles from
-various data representation communities.
-In this sense an {\RDF} property can be thought of either as an attribute of a
-resource (traditional attribute-value pairs model), or as a relation between
-a resource and a value (entity-relationship model).
-This observation leads us to conclude that {\MathQL} is sound and complete
-with respect to querying an abstract {\RDF} metadata model.
-Finally note that access relations are close to {\RDF} entity-relationship
-model, but they do not work if we allow paths with an arbitrary number of
-loops ({\ie} with an arbitrary length) because this would lead to creating
-infinite sets of triples.
-If we want to handle this case, we need to turn these relations into
-multivalued functions.
projects / helm.git / blobdiff