Wow, lot's of great stuff you all are posting here! So exciting 😃 I'd like to share something too, it embraces the "scaling-down" sentiment I am seeing in other projects here. I designed a semantic hypermedia data structure (FIFO) with a "higher-order" syntax, allowing form to be transferred across text/gui substrates. The general idea was to see how closely you can emulate hypermedia documents using just semantic and semiotic rules. These rules are then encoded in a rendering pipeline to systemically present the data on the screen. It sounds fancy but in practice it's very mundane. FIFO's syntax is actually inspired by the file system information model, which, as we know, has these properties, allowing trees to be rendered systemically and consistently in whatever style, but without any loss in meaning. Not only file systems, though, this is a very pervasive modality, such as the universality of frequencies in relation to the particularities of timbre, or natural language itself, which is very malleable in terms of encoding, preserving meaning mostly intact regardless of representation. This sort of thing is only possible with models that are purely abstract, immaterial, but yet well defined. Now this is not just for fun, it can be very useful to have a document language like in some scenarios, for instance, to very cheaply and quicky compose and distribute multimedia information. I made my website using FIFO, and also a portfolio for a friend of mine. It's just a proof of concept at this point, I invested very little in the rendering part, just enough to make it usable. In the future I'd like to make an editor for it, for now I just write it by hand. You can check the links below to see it in practice. Before anyone asks why bother with all the work to have a worse version of markdown, consider that: 1) this is not markup but a data structure, it has it's own in-memory DOM and query interface, 2) it's extensible, 3) it's hierarchical, so you can have directories in the document, 4) it's mathematically rigorous, 5) is composable, and some more things. The fact it looks like a basic document is consequential, as the whole idea was to capture the stereotype but starting from a different principles. There can be different visual renditions, too, I'm just not so much creative in this department. visual repr: https://jon.work/og text repr: https://jon.work/og/index.fifo.txt visual repr: https://jon.work/fifo text repr: https://jon.work/fifo/index.fifo.txt visual repr: https://henriquecesar.pages.dev text repr: https://henriquecesar.pages.dev/index.fifo.txt

Interesting! Your FIFO reminds me of two somewhat similar (but differently focused) projects I have seen before: • Tree notation • The Most Elegant Configuration Language

Both very exciting projects! I love this kind of stuff. Pretty sure I've seen Tree notation during the discovery phase of my research! And the CCL article is a gem, had real fun reading it, the author is much better than me at explaining things

Now I am a bit lost. What I see is a tree, both visually and in the parsed data. Where are the edges that relate multiple nodes? Where are edges that have edges themselves?

The edges are reified. Nodes prefixed by a dot (meta nodes) are edges/relations between data nodes. The example given was not meant to be a sample demonstrating the qualities I mentioned. Indeed it mostly behaves as a tree due to the text source layout. But when using a live environment, such as a GUI interface, the text representation is not needed, and so it facilitates more advanced compositions. In any case, this is more in theoretical than practical utility, since it's designed for documents and those are naturally tree-like

There are indeed multiple ways to represent a file system as a (hyper)graph. The question is what you gain from moving to more sophisticated graph representations. A plain file system without links has a well-established representation as a tree. You can choose to represent directories are hyper-edges between files, but unless you add links (which let you add any file to any hyper-edge), you don't gain much from that. Inversely, if your use case profits from hypergraphs, the question is if implementing this hypergraph as a tree plus links is the best concrete representation.

I think representing a tree model as a tree data structure (mimicking containment by tucking nodes behind a chain of native pointers) turns data manipulation into a cumbersome process. The tree representation gives close to nothing in terms of access ergonomics, so you practically always need secondary/tertiary representations/indexes to avoid traversing it over and over. In my case, I needed the ability to efficiently find nodes in the tree/graph, and also the ability to natively instantiate nodes across many places. The choice for a flat strucure with data-level pointers affords that. This in-memory repr is basically the sorted in-order image of the tree, which is usually the sort of traversal you'll be performing repeatedly to manipulate the document. Now the matter of finding a set of nodes with a given type/value becomes a simple branchless/stackless loop/filter, both easy to write and more performant. Context-free searches can also be fully paralellized if needed. I understand it's a very particular case, but it just plays very nicely with other systems I'm developing