\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 formally accesses an {\RDF}
-graph%
-\footnote
-{When we say {\RDF} graph, we actually mean both the {\RDFM} graph and the
-{\RDFS} graph.}
-through an \emph{access relation} which is better understood by explaining
-the informal semantics of the operator itself.
-
-This operator builds a \emph{result} {\av} set starting from two mandatory
-arguments: the \emph{source} {\av} set and the \emph{head path}.
+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.
-Its textual syntax is (see \subsecref{Textual}):
+
+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}
-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).
-
-\begin{figure}[ht]
+\begin{figure}
\begin{footnotesize} \begin{verbatim}
-These examples refer to the resources "A" and "B" of Figure 2.
+ 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"} returns "1"
-property "id"/"minor" of {"A", "B"} returns "2"; "7"
+ 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 ".*" returns "2"; "7"
+ 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 using MathQL-1 set-theoretic union giving the one-element set:
-"" attr {"major" = "1"; "minor" = "2"}, {"major" = "1"; "minor" = "7"}
+ 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"}
+ 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"}
+ 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.
+ 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 subj "" gives
-"A" attr {"first" = "2002-01-01"}; "B" attr {"first" = "2002-02-01"}
+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")
+("A", /"date", "");
+("A", /"date"/"first", "2002-01-01");
+("A", /"date"/"modified", "2002-03-01")
\end{verbatim} \end{footnotesize}
-\vskip-1pc
+\vspace{-1pc}
\caption{The ``property'' operator}
\label{Property}
\end{figure}
source {\av} set (call them source resources) as start-nodes.
\item
-The computation gives a set of nodes in the {\RDF} graph ({\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.
+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
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
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).
-The alternative could be a simple string but it needs to be a path for typing
-reasons. In any case a string can be seen as a one-element path.
+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
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 named \TT{sub} or \TT{super}.
+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
\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 path in \EM{optional-clauses} are never traversed backward.}
-and composes these {\av}'s using the {\MathQL} set-theoretic union to build
-the result set.
+\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).
-Now we can present \emph{access relations} which are the formal tools used by
-{\MathQL} semantics to access the {\RDF} graph.
-An access relation is a set of triples $ (r_1, p, r_2) $ where $ r_1 $ and
-$ r_2 $ are strings, $ p $ is a path (encoded as a list of strings).
+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 is a resource for which 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).
+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.
-In particular, \secref{Interpreter} describes the access relations implemented
-by the {\HELM} query engine.
-It is worth remarking, as it was already stressed in \cite{GS03, Gui03}, 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.
+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
projects / helm.git / blobdiff