ocaml 3.09 transition

[helm.git] / helm / mathql / doc / mathql_introduction_property.tex

diff --git a/helm/mathql/doc/mathql_introduction_property.tex b/helm/mathql/doc/mathql_introduction_property.tex
index f73f5bc781c99d420e2e99fca3f04634f151f800..6bd8561e37b2376937efe608d5850933a382bdda 100644 (file)
--- 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
 \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. 
 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}
 
 
 \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}
 \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:
 
 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:
 
 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:
 
 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:
 
 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:
 
 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:
 
 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:
 
 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":
 
 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}
 \end{verbatim} \end{footnotesize}

-\vskip-1pc
+\vspace{-1pc}

 \caption{The ``property'' operator}
 \label{Property}
 \end{figure}
 \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
 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
 
 \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}. 
 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 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).
 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
 
 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 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
 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%
 \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).
 
 
 \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 $
 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).
 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.
 {\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. 
 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
 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