@jonny this might be a surprise given my graph evangelism but I actually don't like graphs as an interface. In principle they could be useful but in practice I usually find they just become a mess for anything even mildly complicated. There are some tricks if you have extra structure (like bundled connections), but I've never seen anything really convincing.
@neuralreckoning thinking about that over here: https://social.coop/@jonny/110432265414247415
Anything can be hyper complex! but we develop tools to deal with that complexity, show it, hide it, etc. that I also have not seen done convincingly with graphs. To be clear i'm not saying 'make everything the typical force-directed layout of balls and sticks' without much order, but making tools to manipulate and view graphs in lots of different ways - as a tree! comparing two subgraphs! etc.
@jonny yes absolutely! It's on my to do list (in the section of things I'll probably never get around to) to play around with better ways of interacting with graphs.
@neuralreckoning i have the blessing and the curse of having set myself up to need to do this pretty imminently lmao
@neuralreckoning tangent/not-tangent, i have felt the same way about our conceptual vocabulary for graphlike things in neuroscience, and specifically for dynamical phenomena over graphs (which is what the brain does) in the same way that we have conceptual vocabulary for much simpler phenomena like 'inhibition' or 'neuromodulation' and so on. Like there *isn't* a good way to think and talk about the configuration of activity through time, but that's all we have to talk about.
@jonny agreed. Dynamics plus graphs is just incredibly mind bending. No idea how to even get started on that, but agree it could be important.
@jonny it's actually a live question for me. We're trying to think about the dynamics of specialisation, namely how modules could specialise on different things at different times. Basically impossible to visualise in even quite simple cases.
@neuralreckoning this is one of the cases where the extremely fucked state of our communication mediums poses a real and tangible limitation to our ability to understand things. Because we have to reduce everything down to a static two-dimensional representation to fit in PDF, we can't do things like "look there is no 2d representation of this, you have to interact with it and explore it and see it change over time." TO SAY NOTHING of how we d=2 with t-SNE and PCA regardless of dimensionality
@neuralreckoning @jonny Are your adventures documented anywhere? This has been on my mind (ha ha) a loy lately too. Mostly thinking 3d spatial and using the third dimenaion for time with layers interlinked in stacks. Then moving it around to see the connections better with your hands
@mauve @neuralreckoning talk format if that suits you better https://archive.org/details/jls-defense?start=1965
and a very handwavy thought experiment at the protocol level again: https://archive.org/details/jls-defense?start=2543
slides: https://jon-e.net/dissertation/slides/?slideIndex=36&stepIndex=0
@mauve @jonny not really, unfortunately. A couple of papers on graph layout algorithms (with code), but nothing on the interactive stuff.
http://neural-reckoning.org/publication_category_visualisation.html
@david @neuralreckoning @jonny Hmm, I was thinking about this over the weekend. What sort of stuff do you wish to explore through it?
IMO shoving everything into postgres with the proper relational links between data and exploring it via queries might get you pretty far. I've been afflicted with programmer-brain so I'm not sure if it's a reasonable suggestion.
@david @neuralreckoning @jonny I see. 🤔 It sounds like rather than exploring and visualizing data the biggest problem is how to ingest the data in the first place. Sadly that's way harder (especially if your data isn't already structured) and outside of my personal realm of expertise. Might be worth it to look at some of the SemanticWeb stuff the Chat*** plugin ecosystem has though.
@mauve @david @neuralreckoning
oh boy i have thoughts, lemme reply from my neuromatchstodon account so i can have more than 500 characters @jonny@neuromatch.social
@mauve @david @neuralreckoning
Genealogy is a graph with people as nodes and relationships as edges! This is actually one thing that semantic web/linked data technologies are already really good at, so for example see the wikidata project on Genealogy.
Genealogy actually is the most common thing in their list of examples of visualizing wikidata.
So for example if you go here https://www.entitree.com/en/family_tree/Q4604 and keep clicking the "down" arrows, you can trace Confucius' family tree to the present day.
You can see how this works at the wikidata page - he has a child property, in addition to many others.
Accommodating growing/changing/incomplete/overlapping schemas is exactly what #SemanticWeb and #LinkedData technologies are good at - I explore that and the complex politics that surround these technologies, particularly corporate #KnowledgeGraphs in this piece: https://jon-e.net/surveillance-graphs/
specifically here and here though as I said it's one of the basic topics of the whole piece. That naturally contrasts with traditional relational databases, which, as u all are saying, can be brittle and difficult to refactor.
I also discuss the complex and fraught relationship between knowledge graphs and chat interfaces in that piece: https://jon-e.net/surveillance-graphs/#the-near-future-of-surveillance-capitalism-knowledge-graphs-get-chatbots
and spoiler alert automatically populated graphs are, uh, pretty bad, but KGs + #LLMs is the direction that the information conglomerates are headed in a much deeper and terrifying way than I have seen in the general discourse (that's why i wrote the piece in the first place i guess).
Interface design has been one of the major problems in the history of semweb/LD (in my opinion, next to the social systems and politics, it is the largest problem). I explore that history and the constraints a bit in a prior piece, here, and talk a bit about some potential roads forward here.
Ingestion is also a huge problem! and that is partially because most of the tooling has been designed for massive information conglomerates to guzzle down the semi-structured information on the web rather than for individual people to make sense of information they care about. So eg. existing tools like Neo4j or other graph databases are pretty dang tricky to get set up, but imo i'm pretty sure the target data format you're looking for is a graph of triples, and once that's in a serializable format like turtle or n-triples or whatever I'm pretty confident you won't "regret it" or that the effort will have been wasted. You might have to shop around a bit for the appropriate visualization/storage/query tech stack, but that's the neighborhood to look in. One example is wbstack which is intended to make hosting your own instance of wikidata (wikibase) more straightforward if you don't want to shove all your data in public onto wikidata.
Marking this public so i can search for it later because these questions come up frequently :)
@mauve @david @neuralreckoning
I went to find the link to the post where i was like 'how come we don't represent things that are graphs as graphs' but i guess that is the top of this very thread lmao
@david @mauve @neuralreckoning
absolutely :) browse around some wikidata pages and you'll also see heterogeneous data and provenance - that's sort of the name of the game with linked data. Wikidata is specifically very good with translation and source references. They are also (somewhat implicitly) good with tracing the evolution through time (same "view history" page as is present on wikipedia/mediawiki)
wikipedia/wikidata have a complicated relationship with surfacing the kind of dialogical process you're describing, even though they are of course built on it. Sorry for bombing you with more links but if it's useful i have written about that here: https://jon-e.net/infrastructure/#the-wiki-way
but i couldn't agree more how important it is to represent as a first-class part of the data. You're also right on that modeling documents is definitely less well-defined than genealogical relationships (eg. saying above how tedious it would be to manually annotate all the topics in some writing, totally right), and wikidata doesn't necessarily provide the perfect set of tools for doing that, but yes I plan to work on that problem after I get a draft of a p2p backend for sharing and communicating and negotiating over these kinds of packetized-graphlike information blobs <3
#SemanticWeb #LinkedData #WikiData
@david @mauve @neuralreckoning
put another way, semweb/LD approach the problem very generally - rather than "a database for genealogy," thinking about data structures that allow arbitrarily relating information to other information. Genealogy just happens to be a very well-defined graph.
There are a lot of substrains of thought on what that should look like (should it be a perfectly verifiable, logically complete schema or something more freewheeling? it is more important to make global or local sense? and so on) but yes I think you are in the right place in exploring linked data and semweb tooling, even though as said above it is the interfaces for dealing with this kind of data that have historically suffered, with wikidata being I think the flagship 'public mass infrastructure' tooling at the moment
@david
@mauve @neuralreckoning
thank you, im honored you're taking the time with it. feel free to share any thoughts as you read, make annotations on the page, etc. (or don't, also fine.) it's something better made sense of together I think because of yes the horrors and also yes the information density❤️
@david
@mauve @neuralreckoning
@joelchan86 add another mark on the counter until we have to do something about these #DiscourseGraphs together
@mauve @neuralreckoning
mine are both scattered and contained lol. too many little visualization and interface experiments to count or link to across the terrifying tundra of grad school memories. I have some thoughts here that are more at the level of protocol design than interface design, but the protocol is explicitly designed to support interface design so 🤷.
full section: https://jon-e.net/infrastructure/#rebuilding-scientific-communication
integrating linked data and code for display: https://jon-e.net/infrastructure/#shared-tools