]> matita.cs.unibo.it Git - helm.git/blob - mathql/doc/mathql_introduction_property.tex
auto => auto new.
[helm.git] / mathql / doc / mathql_introduction_property.tex
1 \subsection{High level access to metadata} \label{HighAccess}
2
3 {\MathQL} high level access to an {\RDF} database is \emph{graph-oriented} and
4 is delegated to its \TT{property} operator that builds a \emph{result} {\av}
5 set starting from two mandatory arguments: the \emph{source} {\av} set and the
6 \emph{head path}.
7 Other optional arguments may be used to change its default behaviour or to
8 request advanced functionalities. 
9
10 This operator has the following syntax, where a path has the structure of an
11 attribute name ({\ie} a list of strings) and denotes a (possibly empty) finite
12 sequence of contiguous arcs (describing properties in the {\RDF} graph%
13 \footnote
14 {When we say \emph{{\RDF} graph}, we actually mean both the {\RDFM} graph and
15 the {\RDFS} graph.}%
16 ).
17
18 \begin{center}
19 \TT{property} \EM{optional-flags} \EM{head-path} \EM{optional-clauses} \TT{of}
20 \EM{optional-flag} \EM{av-set}
21 \end{center}
22
23 \begin{figure}
24 \begin{footnotesize} \begin{verbatim}
25  These examples refer to the resources "A" and "B" of Figure 2.
26
27 Example 1: reading an unstructured property - simple case:
28  property /"id"/"major" of {"A", "B"} gives "1"
29  property /"id"/"minor" of {"A", "B"} gives "2"; "7"
30
31 Example 2: reading an unstructured property - use of pattern:
32  property /"id"/"minor" of pattern ".*" gives "2"; "7"
33
34 Example 3: reading a structured property without main component:
35  property /"id" attr /"major", /"minor" of {"A", "B"}  
36  generates the following attributed values:
37  "" attr {/"major" = "1"; /"minor" = "2"}; 
38  "" attr {/"major" = "1"; /"minor" = "7"}
39  that are composed with the set-theoretic union giving:
40  "" attr {/"major" = "1"; /"minor" = "2"}, 
41          {/"major" = "1"; /"minor" = "7"} 
42
43 Example 4: reading a structured property specifying a main component:
44  property /"id" main /"major" attr /"minor" of {"A", "B"} gives
45  "1" attr {/"minor" = "2"}, {/"minor" = "7"} 
46
47 Example 5: the renaming mechanism:
48  property /"id" attr /"minor" as /"new-name" of {"A", "B"} gives  
49  "" attr {/"new-name" = "2"}, {/"new-name" = "7"}
50
51 Example 6: imposing constraints on property values:
52  property /"date" istrue /"first" in "2002-01-01" 
53                   attr /"modified" of {"A", "B"} and  
54  property /"date" istrue /"first" match ".*01.*" 
55                   attr /"modified" of {"A", "B"} give
56  "" attr {/"modified" = "2002-03-01"}
57  Only the instance of "date" with "first" set to "2002-01-01" 
58   is considered.
59
60 Example 7: inverse traversal of the head path:
61 property inverse /"date" attr /"first" in "" gives
62 "A" attr {/"first" = "2002-01-01"}; "B" attr {/"first" = "2002-02-01"}
63
64 Example 8: some triples of an access relation:
65 The triples formalizing the property "date" of the resource "A":
66 ("A", /"date", "");
67 ("A", /"date"/"first", "2002-01-01"); 
68 ("A", /"date"/"modified", "2002-03-01")
69 \end{verbatim} \end{footnotesize}
70 \vspace{-1pc}
71 \caption{The ``property'' operator}
72 \label{Property}
73 \end{figure}
74
75 In the simplest case \TT{property} is used to read the values of a (possibly
76 compound) property with an unstructured value and does the following:
77
78 \begin{enumerate}
79
80 \item
81 It computes the instances of the given path in the {\RDF} graph available to
82 the query engine, using the resources specified in the head strings of the 
83 source {\av} set (call them source resources) as start-nodes.
84
85 \item
86 The computation gives a set of nodes ({\ie} the end-nodes of the instantiated
87 paths) which are the values of the instances of the (possibly compound)
88 property specified by the path and concerning the source resources.
89
90 \item
91 These values, encoded into {\av}'s as explained above, are composed by means
92 of the {\MathQL} set-theoretic union to form the result {\av} set.
93
94 \end{enumerate}
95
96 \figref{Property} (example 1) shows an instance of this procedure. 
97 Note that the result sets of this example have no attributes and that a path
98 is represented by a slash-separated list of strings denoting the path's arcs.%
99 \footnote{If needed, the empty path is represented by a single slash.}
100
101 Using the \TT{pattern} flag, \TT{property} can be instructed to regard the
102 values of the source {\av} set as POSIX regular expressions rather than as
103 constant strings.
104 In this case \TT{pattern} selects the set of resources matching at least one
105 of the given expressions.
106 See for instance \figref{Property} (example 2).
107
108 If we want to read the value of a structured property we can specify the
109 value's main component in the \TT{main} \EM{optional-clause} (this
110 specification overrides the default setting inferred from the {\RDF} graph
111 through the \emph{rdf:value} property) and the list of the value's secondary
112 components in the \TT{attr} \EM{optional-clause}. 
113
114 Note that if a secondary component is not listed in the \TT{attr} clause, it
115 will not be read.
116 Also recall that, when the result {\av}'s are formed, the main component is
117 is read in the head string, whereas the secondary components are
118 encoded using the attributes of a single group.
119 See for instance \figref{Property} (examples 3 and 4).
120 As a component of a property's value may be a structured property, its
121 specification (appearing in the \TT{main} or \TT{attr} clause) is
122 actually a path in the {\RDF} graph starting from the end-node of the head
123 path.
124
125 Note that the name of an attribute, which by default is its defining path in
126 the \TT{attr} clause, can be changed with an optional \TT{as} clause for the
127 user's convenience. See for instance \figref{Property} (example 5).
128 Note that the assigned name must be a path for typing reasons.
129 The alternative could be to use a simple string but in any case a string can
130 be seen as a one-element path.
131
132 In the default case \TT{property} builds its result considering every
133 component of the {\RDFM} graph ({\ie} every {\RDFM}) but we can constrain
134 some nodes of the inspected components to have (or not to have) a given value,
135 with the aim of improving the performance of the inspection procedure.
136 The constrained nodes are specified in the \TT{istrue} and \TT{istrue}
137 \EM{optional-clauses} and the constraining values are expressed by \TT{in} or
138 \TT{match} constructions depending on their semantics (constant values or
139 POSIX regular expressions respectively).
140 See for instance \figref{Property} (example 6).
141 Again a constrained node may be the value of a compound property, therefore
142 its specification (appearing in the \TT{istrue} or \TT{isfalse} clause) is
143 a path in the {\RDF} graph starting from the end-node of the head path.
144
145 \TT{property} allows to access the {\RDFS} property hierarchy by specifying
146 a flag \TT{sub} or \TT{super}.
147 If the \TT{sub} flag is present, \TT{property} inspects the instances of the
148 default tree (made by the head path and by the \EM{optional-clauses} paths)
149 and every other tree obtained by substituting an arc $ p $ with the arc of a
150 subproperty of $ p $.
151 If the \TT{super} flag is present, super-property arcs are substituted instead.
152
153 \TT{property} also allows the inverse traversal of its head path if the
154 \TT{inverse} flag is specified.
155 In this case the operator works as follows:
156
157 \begin{enumerate}
158
159 \item
160 It instantiates the head path using as end-nodes the values whose main
161 component is specified in head strings of the source {\av} set.
162
163 \item
164 It encodes the resources corresponding to the instances of the start-nodes into
165 {\av}'s assigning the attributes obtained instantiating the attribute paths%
166 \footnote{The paths in the \EM{optional-clauses} are never traversed backward.}
167 and builds the result set composing these {\av}'s with the set-theoretic union.
168
169 \end{enumerate}
170
171 See for instance \figref{Property} (example 7).
172
173 Formally \TT{property} accesses the {\RDF} graph through an \emph{access
174 relation} which is a set of triples $ (r_1, p, r_2) $ where $ r_1 $ and
175 $ r_2 $ are strings, and $ p $ is a path. 
176 Each triple is a sort of ``extended {\RDF} triple'' in the sense that $ r_1 $
177 is a resource for which some metadata is provided, $ p $ is a path in the
178 {\RDF} graph and $ r_2 $ is the main value of the end-node of the instance of
179 $ p $ starting from $ r_1 $ (this includes the instances of sub- and
180 super-arcs of $ p $ if necessary).
181 See for instance \figref{Property} (example 8).
182 {\MathQL} does not provide for any built-in access relation so any query
183 engine can freely define the access relations that are appropriate with
184 respect to the metadata it can access.
185
186 It is worth remarking, as it was already stressed in \cite{Gui03,GS03}, that
187 the concept of access relation corresponds to the abstract concept of property
188 in the basic {\RDF} data model which draws on well established principles from
189 various data representation communities.
190 In this sense an {\RDF} property can be thought of either as an attribute of a
191 resource (traditional attribute-value pairs model), or as a relation between
192 a resource and a value (entity-relationship model).
193 This observation leads us to conclude that {\MathQL} is sound and complete
194 with respect to querying an abstract {\RDF} metadata model. 
195 Finally note that access relations are close to {\RDF} entity-relationship
196 model, but they do not work if we allow paths with an arbitrary number of
197 loops ({\ie} with an arbitrary length) because this would lead to creating
198 infinite sets of triples.
199 If we want to handle this case, we need to turn these relations into
200 multivalued functions.