| … | … | @@ -63,12 +63,14 @@ higher analysis layers could be stacked on top of. The base class |
| 63 | 63 | consisted of these parts: |
| 64 | 64 | |
| 65 | 65 | 1) Get the types of the left and right vertexes, and the edge. |
| 66 | (The `'left-type`, `'right-type` and `'pair-type` methods.) |
| 66 | 67 | 2) Given an edge, get the left and right vertexes. |
| 68 | (The `'left-element` and `'right-element` methods.) |
| 67 | 69 | 3) Given the matrix, get left and right wild-cards (marginals; edges |
| 68 | 70 | with the left or right vertexes replaced by wild-cards). |
| 69 | 71 | 4) A list of all edges. |
| 70 | 72 | 5) Ability to get all edges from a StorageNode |
| 71 | | 6) Delete all edges (and the correspodning entries in a StorageNode) |
| 73 | 6) Delete all edges (and the corresponding entries in a StorageNode) |
| 72 | 74 | |
| 73 | 75 | This API is documented in `object-api.scm` and a concrete example |
| 74 | 76 | appears in `edge-pairs.scm`. The file `object-api.scm` also defines |
| … | … | @@ -157,4 +159,67 @@ In that original matrix, the only rewrite was identical to the search |
| 157 | 159 | pattern, thus a confusion about which is which. |
| 158 | 160 | |
| 159 | 161 | The rewrites provide an opportunity to specify exactly which marginals |
| 160 | | one is interested in. Thus, for example: |
| 162 | one is interested in. Thus, for example, the original matrix, with |
| 163 | wildcards, can be described as: |
| 164 | ``` |
| 165 | (Query |
| 166 | (VariableList |
| 167 | (TypedVariable (Variable "$left") (Type 'Word)) |
| 168 | (TypedVariable (Variable "$right") (Type 'Word))) |
| 169 | (Present |
| 170 | (Edge (Predicate "word-pair") |
| 171 | (List (Variable "$left") (Variable "$right")))) |
| 172 | (Edge (Predicate "word-pair") |
| 173 | (List (Variable "$left") (Variable "$right"))) |
| 174 | (Edge (Predicate "word-pair") |
| 175 | (List (Any "left-wild") (Variable "$right"))) |
| 176 | (Edge (Predicate "word-pair") |
| 177 | (List (Variable "$left") (Any "right-wild")))) |
| 178 | ``` |
| 179 | This has three rewrites: the diagonal, and the left and right marginals. |
| 180 | This has several nice properties. One is that, if the diagonal is not |
| 181 | required, then it can be omitted from the rewrites. This will save |
| 182 | RAM associated with the query result cache, expecially if it is large. |
| 183 | |
| 184 | The down-size is the marginals aren't auto-generated. Lacking a specific |
| 185 | use-case example, its hard to see what kind of solution could be |
| 186 | provided. The generic case seems to work well. |
| 187 | |
| 188 | Item (2) could be done with a `FilterLink` plus `RuleLink` combo. For |
| 189 | the word-pair matrix, the left-element axtractor would be |
| 190 | ``` |
| 191 | (Filter |
| 192 | (Rule |
| 193 | (VariableList |
| 194 | (TypedVariable (Variable "$left") (Type 'Word)) |
| 195 | (TypedVariable (Variable "$right") (Type 'Word))) |
| 196 | (Edge (Predicate "word-pair") |
| 197 | (List (Variable "$left") (Variable "$right"))) |
| 198 | (Variable "$left")) |
| 199 | (List |
| 200 | (Edge (Predicate "word-pair") |
| 201 | (Word "some") (Word "thing")))) |
| 202 | ``` |
| 203 | Notable aspects to this structure: |
| 204 | * The search pattern is specified with a `Rule` instead of a `Query`. |
| 205 | That's OK, given that Rule is a base class for Query. In practice, |
| 206 | its a bit confusing. |
| 207 | * The `Rule` doesn't include the `PresentLink` (more generally, the |
| 208 | `AndLink`). But this is a historical design accident... |
| 209 | * Should the `FilterLink` be amendeded to use the existing query-engine |
| 210 | infrastructure, but limit the search space to the input vector? Maybe, |
| 211 | but there seems to be little utility in this, since back-tracking will |
| 212 | never be required. Filtering is a lot easier than querying. So, no, |
| 213 | the query engine should not be used for filtering. |
| 214 | * Filtering should be unit tested for correctness on `PresentLink`, etc. |
| 215 | in the search pattern. Not clear this is fully supported at this time!? |
| 216 | |
| 217 | Anyway, the above replaces item (2) with a generic rewrite, which is a |
| 218 | good thing, I guess. |
| 219 | |
| 220 | Is Item (2) actually needed? Searching the code base, then answer seems |
| 221 | to be "no". The method only shows up in implementations of derived |
| 222 | clases. So I think this can be scratched. |
| 223 | |
| 224 | Item's (5) and (6) are already in the StorageNode API, although this API |
| 225 | also needs to be converted to pure Atomese. |