Memex merge between two knowledge domains

General
1

Being new as Logseq user (two days), I think I’ve got your point regarding a block as the minimum unit, and the journal as the default page. One of the first things that came to my mind after one day using Logseq was that it would be possible to create a vocabulary for my company (software developers) where all common words become pages (e.g EPIC, task, ETL, frontend, backend, etc) and merge it with my client vocabulary (medicine, research, logistics). This would allow me to create quick projects ramp-up taking requirements as journal entries.

Then during project development, ask team members to maintain an interstitial journal, keep using tags from both domains, commit their journals every day and automatically have a common project knowledge base every team member can understand.

Does this sound doable and useful?
Has someone tried to create something similar?

1 Like
2

Welcome.

You are at a good starting point, but it needs more thought. I’m going to approach this in a way that software developers may find interesting.

  • Some code is knowledge, and knowledge is like high-level code:
    • Each high-level expression is like a Logseq block.
      • High-level, meaning not written for computers, but for humans.
      • This includes composite expressions, up to the level of function definitions.
        • A composite expression is a hierarchy of Logseq blocks.
      • A good atomic note should be relatively easy to transform into code.
    • Each high-level module is like a Logseq page.
      • High-level, meaning not an arbitrary packaging of related functions, but a local namespace (not Logseq namespace), gathering all functions that model a well-identified concept within a knowledge domain.
      • A module is not a datatype, but a unique concept from the perspective of a project.
        • A single concept may need multiple datatypes to be fully modeled.
      • A concept may be a common word.
        • Not every common word is a module.
          • Not every common word deserves its own page.
          • Should not spam the graph with pages for every single common word.
          • Some common words should be fine as common blocks.
    • Each project is like a Logseq graph.
      • A project combines some modules to provide a solution within a company.
      • One Logseq graph per project, is the ideal separation.
        • Difficult in practice, because of overlapping.
  • A journal is a log.
    • Logs should be read-only (except for fixing mistakes from the perspective of the past).
  • Throughout a project’s life the requirements change.
    • In your scenario, that means that some older journal entries become outdated.
      • That would turn non-journal pages into a mix of valid info with outdated one.
  • Therefore, a journal cannot serve well as the ultimate source of truth.
    • It takes a knowledgeable human to decide which entries remain valid.
    • Non-journal pages should be carefully edited to always contain the currently valid info.

Sometimes tools are advertised as if they do everything automatically. Get to know the tool and use it for its real merits.

3
  • Another problem is understanding the client domain language which is another knowledge base.
    • I like to use client's knowledge jargon because
      • It improves communnication
      • It helps me translate software jargon into something they can understand
      • The con is that the team need to learn quite fast the domain language
        • and also it's meaning
        • we need to be fast learners.
      • at the beginning a lot of confusion arises
        • nobody understands what is big and what small
        • what is contained by what
        • what is related to what
      • as it settles
        • there's a lot of rework
        • silly work reorganizing things wrongly hierarchized
        • tickets to move, epics to decompose and so on.
        • until we get something understandable, but we rarely do it quicky
      • processes are the worst part
        • clients know them by repetition
        • but never document those processes, they explain and think it's understandable
        • so i need to ask questions interviewing and then show results to verify those questions reflect reality.
    • After that I need to repeat the process with my team.
      • that implies a lot of writing, meetings, speaking
      • devs are used to their own jargon as the client does.
      • I wish that could be shortened by
        • Taking notes
        • Defining specs
        • defining "objects" via templates
        • and get something useful in a shorter time anyone can understand
        • to speak both high level domains quickly
      • furthermore, I'd like to feed an LLM with the model and see it can "understand"
        • I fell logseq approach is better for AI
          • because it resamblance how LLM are made
            • using the smallest part with "meaning"
            • "understanding"
              • hierarchies
              • relations
              • nested concepts
              • from both domains
            • and then
              • answering questions
              • becoming our project assistants
              • expanding atomic ideas into better explanations
            • and because apparently that's how our own neural network work
              • a collection of meanings
              • a context
              • and "information retrieval" using synapsis.
            • then probably our atomic ideas can be digested by
              • knowledgable humans
              • LLM
      • And yup I always assume a knowledgable human is on the loop
        • Filtering ideas
        • Merging concepts
        • Creating aliases for synonims
        • and reviewing journals so they understand who is getting out of track
      • What I like about logseq is
        • One place to make a brain dump (journal)
        • Atomic ideas
        • Quick definition of hierarchies.
        • Strict enforcement of the habit and the atom.
      • However I do not clearly see how to
        • share knowledge using journals
        • or have a shared journal that doesn't become unmanageable
        • but I would like to make experiments, any previous experience on this communnity?
        • would be very apprecciated.
      • Thanks a lot, by the way. :)
        • PS: I think I'm taking notes the wrong way :(
          • I'm still a novice
4

You are above average.

Not even close (we live in the age of misinformation), but this is off-topic.

What you describe is the frustrating reality of a typical custom-software company.

  • This is a waste of resources.
    • Apart for some redundancy, to avoid a single-point-of-failure.
    • The fewer persons having to learn one more language, the better.
      • Computers are so reliable in what they do, because they have:
        • ignorance of everything else
        • no option to do else
  • What is needed is a professional equally good with:
    • communication skills, to be productive when talking with:
      • the client
        • learning the client’s jargon
      • the team
        • knowing the team’s jargon
    • analytical skills, to break things down:
      • to manageable and explainable units
      • without degrading them
    • patience, to manage the frustration from the previous points
      • This is the only point where AI qualifies, because of the A part.
        • LLMs should never be in the loop, they should assist from the sides.
          • Being in the loop takes responsibility.
          • An LLM could be a humble junior in the team, but nothing more responsible.
  • Logseq should be:
    • internal to the team
    • unknown to the client
      • It is unrealistic to expect from the client to use your tools in an effective way.
    • using a single form of internal jargon for both domains
    • the single point of reference for the team
      • its non-journal pages only
        • Journals are:
          • mere inputs
          • not effective in sharing knowledge
      • This doesn’t replace live explanation sessions.
        • Just because something is documented, it doesn’t mean that anyone automatically:
          • is aware of it
          • understands it
          • is able to benefit from it
        • It is the live session that glues everything in place.
  • In Logseq, the aforementioned professional should be responsible for:
    • filling the journal from the client’s perspective
      • translating it to internal jargon
    • maintaining the quality of the graph, by:
      • reviewing the journals
      • editing non-journal pages as needed
    • arranging for live sessions in a balanced frequency
1 Like
5
  • #Logseq for Teams

    Anything less than decent knowledge is worse than total ignorance. :) Define "decent knowledge"

    • Not even close (we live in the age of misinformation), but this is off-topic.

      Agree! Point me to an interesting resource and I promise not mentioning this again on this thread :)

    • Logseq should be:
    • internal to the team
      • unknown to the client

      • Agree! Though! I need some way to organize what client had transfer to me, and collaborate, usually they don't do it. Since block mindset is yet far from mainstream I was considering combine logseq with another client facing tool, more document based but better than their hierachical tools (OneDrive, Gdrive) that anyway doesn't seem to work for them

    • It is unrealistic to expect from the client to use your tools in an effective way.

      Absolutely!

    • using a single form of internal jargon for both domains
      • the single point of reference for the team
    • its non-journal pages only
    • Journals are:
    • mere inputs
      • not effective in sharing knowledge

        So you think that sharing journals among the team will lead to more confussion?

    • I'm planning the folllowing experiment:
      • use a pet project (internal no client involved)
        • ask the team members (tech savy) to do interstitial journaling
        • share their journals
          • append those journals adding #byPerson to each parent node.
        • have the aforementioned professional selecting and filtering.
        • share the graph with the team
        • take advantage of the plain md format Logseq uses to
          • export selected resources to a client friendly similar thing (anytype, appflowy)
          • translate logseq artifacts to something else (client friendly) artifacts
          • share the client friendly thing with other people in my company (non tech savy)
            • pages
            • list of documents
            • processes
            • other stuff
          • if sucessfull, then automate, else iterate
      • I'm planning to use the following tools
        • Sync: Git, Gdrive (Drive sync)
        • Pandocs
        • Links for documents instead of documents (to use GDrive access permission)
        • NextCloud (if a 100% opensource stack required)
      • PS: No intention to reinvent the wheel, any previous experiences are welcome.
      • PS2: Thank you so much for your valuable time :)
6

It means adequate knowledge, making its usage by its possessor:

  • neither efficient
    • giving thorough explanations
  • nor performant
    • giving quick replies
  • but safe
    • giving accurate answers

You know decently a language:

  • neither when you have a rich vocabulary
    • like an automatic translator
  • nor when you sound fluent
    • like an LLM
  • but when you can be confident that you don’t communicate nonsense
    • where both automatic translators and LLMs fail
      • As of today, using a decent learning book is more reliable.

To put things in scale:

  • reaching decent knowledge:
    • as human
    • starting from “zero”
  • is estimated that it requires either:
    • 2 years half-time effort
    • 3 months full-time effort

The differences between Artificial and Biological Neural Networks is a random article that:

  • despite being:
    • somewhat biased
    • somewhat outdated (inevitably)
  • introduces a fair percentage of the differences
    • without even touching the rest
  • rightly says: “biological neurons have only provided an inspiration to their artificial counterparts”

The thing is that:

  • we don’t have an adequate knowledge of how our brain works
    • Even what we thought that we knew about how neurons work
      • the many different types of them
      • the inspiration behind artificial neural networks
    • turns out increasingly inaccurate
  • we can safely say that artificial neural networks:
    • being statistical inference engines
    • don’t approximate any biological mechanism

Sharing journals is not the same with sharing knowledge:

  • Input can be served by journals.
  • Output needs dedicated pages.

The need is:

  • not to reinvent the tool
  • but to develop its application in your particular conditions
1 Like
7
  • I think the discussion had settlef for now and needs
    • slow cooking
    • experimentation
    • drawing board.
  • I’ll let you know what happens!!
    • thanks for your patience and generously sharing your knowledge
1 Like