Relationships/Associations Represented on Vectors

~

[1] Joseph V. Homan, Paul J. Kovacs – A Comparison Of The Relational Database Model And The Associative Database Model (6 page article). Issues in Information Systems, Volume X, No. 1, 2009. pdf > This paper compares the relational database model with the associative database model. This paper briefly summarizes the relational and other familiar data models. The remainder of this paper will introduce and describe the associative database model. …

Here’s a way to unpack the quote *“relationships/associations represented on vectors”* in light of the 2009 associative data model paper you mentioned and today’s vector database technologies: --- ### 1. What the quote means literally * **Associative database model (2009):** Data was structured around *entities* (things) and *associations* (relationships between things). Associations were first-class citizens, not just foreign keys. The model explicitly stored these links. * **Vector representation (modern AI/ML):** A *vector* is a numerical encoding of a data item. Similar items are close together in this high-dimensional space. Relationships are not stored as explicit links but are *inferred* from geometry: distance, direction, and clustering. So, the quote is saying that instead of representing associations as logical links (tables, joins, associative entities), we can represent them as *positions and proximities* in vector space. --- ### 2. Context in data models * In 2009, associative databases were positioning themselves as a step beyond relational databases: * Relational DBs: relationships are implicit, defined by keys and joins. * Associative DBs: relationships are explicit, stored as data objects. * In modern vector databases (Weaviate, Pinecone, Milvus, etc.): * You no longer need to *define* explicit links for similarity. * Embeddings learned from machine learning models automatically capture *semantic associations* (e.g. “Paris → France” close to “Berlin → Germany”). * Relationships become a property of the embedding geometry. --- ### 3. Evolution of the idea | Aspect | Associative Data Model (2009) | Vector Databases (2020s) | | ---------------------------------- | -------------------------------------------------- | ----------------------------------------------------- | | **Unit of representation** | Entities + Associations | Vectors (embeddings) | | **How associations are expressed** | Explicit links (a record: `EntityA —rel→ EntityB`) | Implicitly, by closeness or direction in vector space | | **Data focus** | Structured, logical relationships | Semantic, contextual relationships | | **Query style** | “Which entities are linked to X?” | “Which vectors are closest to X?” (Similarity Search) | --- ### 4. The broader significance The quote captures a **shift in the locus of meaning**: * *Before*: Relationships were engineered into the schema (explicit links). * *Now*: Relationships are *learned* and represented in vector geometry (emergent associations). This explains why vector databases have exploded in importance in AI/ML: they allow you to ask *“what is like this?”* without pre-defining every possible association. --- 👉 Would you like me to go one step further and show **how a many-to-many association (classic database concept)** translates into a vector representation (e.g. word embeddings for synonyms/contexts)? That would make the bridge between the two models even clearer.

Great — let’s make that bridge concrete. --- ### Many-to-Many in Classic Databases Suppose you model **students enrolled in courses**: * `Student(id, name)` * `Course(id, title)` * `Enrollment(student_id, course_id)` ← the association table This `Enrollment` table is necessary because one student can take many courses and one course can have many students. The association is *explicit and logical*. --- ### Many-to-Many in Associative Database Model (2009) In the associative model, this wouldn’t be a “join table” but an **association entity** stored alongside items: * Entities: `Student(123, "Alice")`, `Course(42, "Databases")` * Association: `Enrolled(123, 42)` So the relationship is a first-class object, queryable just like an entity. --- ### Many-to-Many in Vector Representation In vector databases, there’s no association table. Instead: * Each student gets an **embedding** (from text profile, grades, activities). * Each course gets an **embedding** (from syllabus, description). * The *association emerges* because vectors for a student and the courses they take will be closer together in space. For example: * If Alice has interests in “machine learning,” her vector will sit near the vectors for “Databases,” “AI,” “Statistics.” * If Bob is more into “literature,” his vector will cluster near “English” and “Philosophy.” When you query “similar students” or “similar courses,” the geometry reveals many-to-many associations without explicitly storing them. --- ### Key Difference * **Database schema world:** association = explicit record (`Enrollment`). * **Vector world:** association = implicit proximity (embedding similarity). The many-to-many relationship is not stored as rows but **discovered through similarity search**. --- Would you like me to sketch this with a **simple diagram** (boxes + arrows for the DB model vs. points + clusters for the vector model) that you can drop into your FedWiki page?

For your **dm6-elm** architecture, the difference between *explicit links* (associative DB style) and *implicit proximity* (vector DB style) has some practical consequences. --- ### 1. Current dm6-elm stance * **Maps, topics, associations** → you already model associations as **first-class objects** in Elm. * This matches the **associative database model** from the 2009 paper: you can pin/unpin topics, unbox containers, traverse explicit links, etc. * Relationships are **deterministic**: they exist because you’ve created them in the model. --- ### 2. What vector embeddings would add * A second “layer” of *soft associations* that are not explicitly modeled in the topic map. * For example: * Two topics might not be linked in dm6-elm, but their embeddings could be very close (e.g. “Golden Ratio” and “Laws of Form”). * The app could surface these as **suggested links** or **semantic neighborhoods**. * Associations would then be both: * **Explicit** (hard links you’ve created, core to dm6-elm). * **Implicit** (emergent from embedding similarity, optional/augmentative). --- ### 3. Architectural implications * **Model extension:** you’d need a place in the Elm model to store embeddings or similarity indexes. This could be a `Dict Id (List (Id, Float))` mapping each topic to its closest neighbors. * **UI integration:** * WhiteBox/BlackBox could optionally show “related by embedding” items. * A sidebar or hover menu could suggest “possible new connections.” * **Workflow change:** * Today, links are curated (manual). * With embeddings, you’d get a *semi-automatic associative substrate* (Wiki as Substrate, in your phrasing). --- ### 4. Big picture for dm6-elm * **Keep explicit associations as the backbone.** This preserves the integrity and graph logic of topic maps. * **Layer in vector associations as augmentation.** They don’t replace links but provide *semantic gravity* — hints about what might belong together. * This makes dm6-elm a hybrid: * *Graph database feel* (explicit links). * *Vector database feel* (implicit semantic neighborhoods). --- 👉 In other words: **dm6-elm could evolve from a purely explicit topic map editor into a tool that also suggests associations based on semantic embeddings**, while still letting the user decide which ones to formalize. Would you like me to draft a **possible Elm type extension** (e.g. adding a `semanticNeighbors : Dict Id (List Id)` to `Model`) so you can see what this would look like concretely in your codebase?