How Logseq should build a World Knowledge Graph

#
>

Logseq has a stated goal to build a World Knowledge Graph. Here’s what I think they should build:

→
#
>

Allow users to build knowledge graphs with their notes

→
#
>

See my proposal for how to do this here: Building a knowledge graph in Logseq

→
#
>

Allow users to check that their knowledge graph is a category, and treat it as one

→
#
>

do I mean bicartesian closed category?

→
#
>

this would probably be in the category of “sets of notes”, and if a user has not stated a relationship between two notes, then that relationship can return the “empty set”

→
#
>

this also means allowing for users to treat combinations of notes like notes of their own

→
#
>

AND

→
#
>

[[organization]] [[meeting]] [[date]]

→
#
>

If in one block I link to all of these names together then I am essentially linking to this page which is an AND of all these three other pages

→
#
>

The key functionality here is for Logseq to treat this combination page like it is a page of its own, and allowing for natural navigation to related pages.

→
#
>

Related pages include: [[organization]] [[meeting]] to zoom out to all meetings with that organization

→
#
>

This is different from namespaces because we don’t want to dictate a hierarchy:

→
#
>

[[organization]] [[date]] and [[organization]] [[meeting]] should be “siblings”

→
#
>

[[organization]] [[meeting]] [[date]] does not need meeting to be the namespace for date or vice versa

→
#
>

allowing for links in names should take care of a lot of this

→
#
>

OR

→
#
>

[[organization a]], [[organization b]], [[project c]]

→
#
>

this is a bit harder, but I think it could have some interesting uses

→
#
>

The default syntax for this feels like it should be to use commas

→
#
>

This is OR page is then treated like a page of its own

→
#
>

notably a link to any of the pages in the OR page shows up as a reference in the OR page

→
#
>

this is different from AND because only references that mention all of the pages in the AND show up in references

→
#
>

Create a general knowledge ontology that users can create translations into

→
#
>

there can be multiple “general ontologies”, perhaps for different industries or areas (academic research, corporate documentation, etc)

→
#
>

for example, a general ontology may be like Joel Chan’s Discourse Graph (types: question, claim, evidence, etc.. relationships: supports, opposes, informs, etc)

→
#
>

if a user can translate their knowledge graph into this “discourse graph ontology”, then other users can see how to utilize that user’s knowledge graph in the context of a discourse graph ontology

→
#
>

a user could create this translation / functor by describing how that user’s knowledge graph types and relationships map to the general ontology’s types and relationships

→
#
>

Translations = functors

→
#
>

here I am using the term category theory term functor to describe a (potentially lossy) translation between two “knowledge graphs”

→
#
>

Make it possible to publish a subset of your knowledge graph, and integrate other knowledge graphs into your own

→
#
>

if personal knowledge graphs x and y both have functors to general knowledge graph a, then it becomes possible to integrate x and y so that you can extract knowledge from x into y (or vice versa)

→
#
>

among other details, it would be necessary to let other people’s knowledge graphs live alongside your own, without taking over my own content

→