Why Hypergraphs? (2013)
blog.opencog.org
blog.opencog.org
Isn't that just like the difference between Object Oriented and Relational, Models? A relational table has multiple columns. A relational table does not represent a relation between two things. It represents a relation between N things, with its N columns.
Two things to make this way more intuitive & practical:
* Modeling: We use them for helping folks correlate across events, or correlating across wide database rows. Ex: Finding bots & fraudsters in your signup events or accounts table . A signup event might have the same weird User Agent, same weird IP, same weird domain name, etc: its good to see events connected across multiple such things! So any time you have an event or a wide row, you can think of it as a hyperedge connecting (correlating) the multiple entities involved.
* Visualizing: It's typically weird visually to draw an edge connecting more than 2 nodes, so most people don't. Instead, sometimes, our users want to see a correlation event as an explicit node in a graph. SO there's a natural bipartite graph from events to entities, like "(signup)-> (user agent)" + "(signup)->(ip)" + ... . But other times its annoying, so they rather just see "(ip:node)<-[signup:edge]-->(useragent:node)". Interestingly, for really wide data, having an explicit "hypernode" (event node) does increase the number of nodes... but significantly decreases the number of edges b/c avoids drawing really big connected components. Formally, add |events| nodes, vs multiply edges by |number of columns|^2 .
If you want to play with it, try "graphistry.hypergraph(pd.read_csv('http://blah.csv'))['graph'].plot()" in http://github.com/graphistry/pygraphistry (or just to get the ._nodes and ._edges dataframes out)
Nowdays, we also do a lot with embedding arbitrary data and exploring similarity graphs that way (use k-nn for inferring similarity edges), so not just across entity links but also say timestamps, $'s, and byte counts. Any dataset embedding can thus be thought of as a projection of the hypergraph, and supporting more interesting columns than just entity columns (categoricals). So in the above example, `graphistry.nodes(pd.read_csv('http://blah.csv')).umap().plot()` and we'll infer the `._edges`. All the nodes in an embedding view are essentially hypernodes, and instead of connecting them to entity/attribute nodes... project those out, and just connect the hypernodes to one another. This gives a very different way to think about stuff like explainability of AI :)
I hadn't thought of relational tables in that way. I guess, you could look at each row of a table as a hyperedge grouping together all the columns for a given record. Not sure how useful that is though. The cross-table join relations are still relatively point-to-point I think.
What I'd like to find is a relational database where field-values can be not just elementary values like numbers and strings but also "object-instances".
I wonder is there such a database? It would seem to offer the best of both worlds, objects, and relations between objects.
Related to the current topic, do graph databases support hyper-graphs?
I don't think the most popular ones support hypergraphs, although that sounds cool. I did see HypergraphDB [3] though! Need to read more about that.
[1] https://neo4j.com/developer/cypher/guide-sql-to-cypher/#cyph... [2] https://tinkerpop.apache.org/gremlin.html#:~:text=Host%20Lan... [3] http://hypergraphdb.org/
What I'd like to understand is, is there some basic reason why RDBMS and ODBMs must be different databases. Or could their conceptual models of data perhaps be generalized into a single model. Using hyper-graphs perhaps. :-)
See https://arxiv.org/abs/1404.0703 for some reading material and one particular way at beyond worst case (i.e., sharing worst case asympotics with the best constant time algorithm, but better performance on non-pathological data (a more precise notion is complicated; there are at least 3 different useful definitions)) runtime performance.
AFAIK the worst cyclical query on a 2-column table is "k-clique counting", from a POV of performance between WCOJ and what Postgres can do (asympotics).
It's interesting whether a new formalism allows to express things better, unearth interesting structures not apparent using a more busy formalism, etc.
Compare the Maxwell equations in the wordy original form, and in a highly compact Clifford algebra form.
Specifically, I read about the SubsetCases predicate: SubsetCases[expr, pattern] returns subsets of expr that match the pattern. You can draw a triangle graph, put slots as the node names, and do SubsetCases[graph,triangle] to pull out all the triangle subgraphs! Mind-blowing. You can also transform graphs really easily like this. Phenomenally powerful, though the computational complexity must get gnarly.
https://news.ycombinator.com/item?id=31928608
That kind of also describes every other Wolfram-related submission :/
His recent "Physics Fundamentals" project is even worse, I see 0 collabration or critique from mainstream physics, 0 testable predictions or actual real-world significance to all the CS-Physics mixed salad. The only thing that sorta kinda could be described as physics is that he can re-derieve some traditional physics out of the new theory with some assumptions. Despite me not being a physicist, my understanding is that this is quite low-bar for a new physics theory, almost the bare minimum, enough to not consider you a total crank, but not for anything else.
I wonder if this is something the author would have enjoyed…
https://github.com/JeffreyBenjaminBrown/hode
I haven't looked more into them, but thought others might find hode interesting.
If your basic system cannot learn solving at least some problems initially, it drastically lowers the probability of it acquiring learning capability later in development lifecycle.
OpenCog never got huge amounts of money. Ben believes strongly in developing AGI (he actually coined the term). There are a few core researchers and developers that have worked with him for decades, also mission-focused. So I don't see development "fizzling out". There are also newer efforts such as SingularityNET.
Development seems alive and well, based on activity at https://groups.google.com/g/opencog, though it is mostly done by a single person these days (the author of the OP)
A general criticism about results may have some validity - When I added cross-platform capability to a part of the project back in 2016, I found an obscene amount of technical debt.
That said, I don't think your criticism is necessarily a good one to make. I'm not aware of any projects that have much in common with OpenCog or Ben's other work. The approach is very different, but again, I'm not an AI/ML expert and only understand this based on comments from others in the AGI community. My gut feeling here is that there's more to the story, or something otherwise doesn't add up, as you are attributing the project with a failure mode apparently shared by the majority of AI projects.
Can you name some examples of projects which are doing the right thing in regard to learning? I'd be genuinely interested in checking them out.
I'd also encourage posting your criticisms to the OpenCog mailing list and I'd expect someone there to address them in good faith. In any case, if you're enough of an expert to be able to make those sorts of criticisms correctly, there would certainly be value to be found in your complete argument.
Quote: "A novel version of opencog" https://wiki.opencog.org/w/Hyperon
And a video of OpenCog Hyperon in use with explanations: https://www.youtube.com/watch?v=Unryt6XH2FE