+
+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.