X-Git-Url: http://matita.cs.unibo.it/gitweb/?p=helm.git;a=blobdiff_plain;f=helm%2Fmathql%2Fdoc%2Fmathql_introduction_property.tex;fp=helm%2Fmathql%2Fdoc%2Fmathql_introduction_property.tex;h=0000000000000000000000000000000000000000;hp=6bd8561e37b2376937efe608d5850933a382bdda;hb=1696761e4b8576e8ed81caa905fd108717019226;hpb=5325734bc2e4927ed7ec146e35a6f0f2b49f50c1 diff --git a/helm/mathql/doc/mathql_introduction_property.tex b/helm/mathql/doc/mathql_introduction_property.tex deleted file mode 100644 index 6bd8561e3..000000000 --- a/helm/mathql/doc/mathql_introduction_property.tex +++ /dev/null @@ -1,200 +0,0 @@ -\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.