Graph data throughout documents

[vid]

Hi, I've been following this project for a while, it's incredible how much functionality is included. But from what I can tell, it is missing one profound feature, which is the use of graph data throughout documents.

From what I can tell, AFFiNE content is essentially different types of self contained blobs, whether they are text, images, tables, graphs, etc. However, they really should support graph data. This approach allows creating a lot of dynamic views, with a lot less hard coded information, so the entire system of documents (blocks) can be a database/knowledge graph.

My earliest experience of this was Semantic MediaWiki (SMW), I created a simple Markdown parser that allows creating graph data using markdown links (subject-predicate-object triples), along with some useful views.

So I can say "the bus is a vehicle" once, only need to update it in that place, and throughout the document base re-use that information, for example to create tables of types of vehicles, relationships between object types, counts of buses, etc. The extension I created allows creating tables, network diagrams, gantt charts, counts, etc. SMW as another reference provides a huge ecosystem of extensions (Look at Semantic Result Formats in particular), all just by adding data to wiki pages via inline triples.

There should not really be a "database" as a distinct thing. Any block type could have and use data. For example, a vector image can have its connections, draw properties, as well as attributes ("state is proposed"), so a version of that image could be generated by an attribute query.

The graph data is is optional, so the user can take it or leave it, but it'd really be best if everything supported data editing/re-use.

I'm not writing all this to promote my prototype code, but rather to hope AFFiNE might include this profound approach. Obsidian supports it to some degree, and many people have adopted it to bootstrap personal knowledge graphs.

What I notice about AFFiNE is it mostly uses a rich text/graphical/etc rather than markdown or other data-extensible editors. In this case markdown is more capable, because it's easy to indicate inline predicates in markdown, it would be an extra step using a rich editor.

But I really like what AFFiNE offers, so maybe this approach could be accommodated, or maybe I just missed how this is done in AFFiNE, since there's a lot of functionality (though I would hope for this to be front and centre).

Thanks for reading this far and any comments!

[vid]

I see mention to "inline properties" in the roadmap, but it really has to be a fundamental, foundational approach to be worthwhile.