| … | … | @@ -46,8 +46,8 @@ marked, the embedding vectors are already implicit in the graph, and |
| 46 | 46 | all that was needed was an API to work with these (sparse) vectors. |
| 47 | 47 | Given a vector API, a cornucopia of similarity measures can be created. |
| 48 | 48 | |
| 49 | | Queries as Tensors |
| 50 | | ------------------ |
| 49 | Review of the existing API |
| 50 | -------------------------- |
| 51 | 51 | The original matrix API was invented to work with word-pairs. Each word |
| 52 | 52 | is a vertex; the edge between them forms a word-pair. Given a collection |
| 53 | 53 | of edges, one could think of this as forming an adjacency matrix, with |
| … | … | @@ -62,10 +62,10 @@ called "parametric polymorphism", defining a base class API, that all |
| 62 | 62 | higher analysis layers could be stacked on top of. The base class |
| 63 | 63 | consisted of these parts: |
| 64 | 64 | |
| 65 | | 1) Get the types of the left and reight vertexes, and the edge. |
| 65 | 1) Get the types of the left and right vertexes, and the edge. |
| 66 | 66 | 2) Given an edge, get the left and right vertexes. |
| 67 | | 3) Given the matrix, get left and right marginals (edges with the |
| 68 | | left or right vertexes replaced by wild-cards). |
| 67 | 3) Given the matrix, get left and right wild-cards (marginals; edges |
| 68 | with the left or right vertexes replaced by wild-cards). |
| 69 | 69 | 4) A list of all edges. |
| 70 | 70 | 5) Ability to get all edges from a StorageNode |
| 71 | 71 | 6) Delete all edges (and the correspodning entries in a StorageNode) |
| … | … | @@ -83,3 +83,40 @@ that almost all otherlayers above need. These are: |
| 83 | 83 | 10) List of the left and right duals to a given Atom. The left dual |
| 84 | 84 | for a given Atom Y is `{x | (x,Y) given fixed Y}` |
| 85 | 85 | |
| 86 | The "problem" with this API is that it is implemented in scheme, and |
| 87 | all of the data is stored in scheme structures. This is a fatal flaw, |
| 88 | and probmpts these re-design notes. |
| 89 | |
| 90 | Queries as Tensors |
| 91 | ------------------ |
| 92 | It appears that the original API can be completely replaced and |
| 93 | generalized by using MeetLink, and generalized by using RuleLink and/or |
| 94 | QueryLink. In retrospect, this is "obvious", and I'm quite mystified why |
| 95 | I didn't do it this way from the beginning. Perhaps it just wasn't so |
| 96 | obvious at first. Let's spell out the obvious. |
| 97 | |
| 98 | The current word-pair representation for the pair (some, thing) is: |
| 99 | ``` |
| 100 | (Edge (Predicate "word-pair") (List (Word "some") (Word "thing"))) |
| 101 | ``` |
| 102 | All such edges can be found by executing the query |
| 103 | ``` |
| 104 | (Query |
| 105 | (VariableList |
| 106 | (TypedVariable (Variable "$left") (Type 'Word)) |
| 107 | (TypedVariable (Variable "$right") (Type 'Word))) |
| 108 | (Present |
| 109 | (Edge (Predicate "word-pair") |
| 110 | (List (Variable "$left") (Variable "$right")))) |
| 111 | (Edge (Predicate "word-pair") |
| 112 | (List (Variable "$left") (Variable "$right")))) |
| 113 | ``` |
| 114 | Running this query provides item (4) above. The query results are cached |
| 115 | on the query itself, using itself as the key. That is, `(cog-value q q)` |
| 116 | will return the query results from the most recent execute of Query `q`. |
| 117 | |
| 118 | Obviously, the above can be replaced by "any" query at all. The current |
| 119 | rules seem to require explicit variable declarations, so that the types |
| 120 | become visible for item (1). |
| 121 | |
| 122 | For item (3), |