Thread - Nostr Hypermedia

I just realized what I said is untrue: tapestry theory does not require the sets and subsets within a concept to be acyclic. The class_thread_propagation relationship type (one of the 3 main relationship types that define a class thread — the other two types being class_thread_initiation and class_thread_termination) can be interpreted as the statement that node A is a superset of node B (or conversely, node B is a subset of node A). And there is no rule that A and B cannot be subsets of each other, in which case they are equivalent (any element of one is an element of the other). I could say, for example, that the superset of all dogs (in my database) has subsets A and B, that A is a subset of B, and B is a subset of A. So I shouldn’t refer to it as a DAG. It’s directed, and a graph, and is probably acyclic in many cases, but definitely not always.

↑ Parent

Replies (2)

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ me@mleku.dev 1 week ago

I strongly suspect it is a lattice you are looking for. Merge conflicts in Git histories are precisely a case where the DAG does not permit extending the graph while retaining the property of linearity—it only lacks cycles. Lattices have linearity. Disambiguating the nonlinearity usually has to be done by humans, although in my experience, you can just get an LLM to use its pattern recognition to find the break in the linearity and extend the DAG. This effectively transforms it back into a lattice, as a DAG that is a lattice can be extended.

david david@bitcoinpark.com 1 week ago

I suppose we could assert that wherever a cycle is discovered, A subset of B subset of C subset of A, then all nodes in the cycle should be merged into a single node. Then we have a DAG. Any cycle that’s not so reduced would be breaking the rules, and the graph db would be not fully “normalized” (not sure if that’s the best word here). The reason for deviating from that and allowing cycles is UX. Suppose I develop the concept for cities. I want to arrange them by continent, and also by their official languages. And I want to visualize the tree of Sets in the page. On the left I arrange them by continent — cities in N America, cities in Europe, etc — and on the right I arrange them by language: cities that list English as an official language, cities that list French as an official language, etc. Any given city will be an element of more than one Set node. So at the top I’d have the Superset of all cities, then underneath two subsets: Cities that have an official language and Cities that are on a continent. Those two set nodes are each subsets of the other. (In theory they don’t have to be — there could be a city that’s not on any continent — but in reality, to the best of my knowledge, they are.) But we still keep them as separate nodes because it’s just better UX.