- some code patched

[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 5fffd727642dd6316edee64254e3957a4d74c69b..6bd8561e37b2376937efe608d5850933a382bdda 100644 (file)
--- a/helm/mathql/doc/mathql_introduction_property.tex
+++ b/helm/mathql/doc/mathql_introduction_property.tex
@@ -60,6 +60,12 @@ Example 6: imposing constraints on property values:
 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}
@@ -163,3 +169,32 @@ 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.