X-Git-Url: http://matita.cs.unibo.it/gitweb/?a=blobdiff_plain;f=helm%2Fmathql%2Fdoc%2Fmathql_introduction_property.tex;h=6bd8561e37b2376937efe608d5850933a382bdda;hb=97c2d258a5c524eb5c4b85208899d80751a2c82f;hp=f73f5bc781c99d420e2e99fca3f04634f151f800;hpb=468da7af4b52d01451073ff1cca5aa1949b9657f;p=helm.git diff --git a/helm/mathql/doc/mathql_introduction_property.tex b/helm/mathql/doc/mathql_introduction_property.tex index f73f5bc78..6bd8561e3 100644 --- a/helm/mathql/doc/mathql_introduction_property.tex +++ b/helm/mathql/doc/mathql_introduction_property.tex @@ -1,71 +1,73 @@ \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} @@ -81,10 +83,9 @@ 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 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 @@ -109,6 +110,7 @@ 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 @@ -123,8 +125,9 @@ 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). -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 @@ -140,7 +143,7 @@ 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 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 @@ -160,41 +163,35 @@ 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 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