bryanph / GeistMap

An experimental personal knowledge base with a focus on connections
https://geistmap.com
GNU Affero General Public License v3.0
446 stars 31 forks source link

formal knowledge representation questions #147

Closed jbescudie closed 6 years ago

jbescudie commented 6 years ago

Hi,

First, congratulations for tackling such a hard problem !

I read your blogpost on PKBs (that's how I discovered Geist, researching on knowledge graphs), gave a try to the demo, and overlooked your github. I have some questions and thoughts that I'll share in the hope it may be useful for you to complete the README or start a conversation.

1) There are decades of work done in formal knowledge representations, databases and reasoning. I'm not an expert in this field, but I happened to work with medical semantic networks and ontologies and also worked with older professor who studied this subject. Your blogpost details how you differientiate Geist from other PKBs, but it is not clear to me how you position your approach on Geist compared to existing work in formal knowledge representation.

2) the Geist model seems to be restricted to one node type (a note) and one type of relations (undefined ?). What is the motivation for this limitation ?

3) I haven't found how you implement this model (I quickly gave up navigating the source code as no architecture overview was provided). Your goal is really high : data entry, modeling, exploring, sharing without sacrifying UX. What existing technologies do you reuse / what do you develop yourself ? How do you decouple and orchestrate all these things ?

Thanks again for sharing you work ! Regards, JB

A few entries Semantic nets examples: in medicine UMLS, in general DBpedia Semantic web: technologies derived from W3C work on semantic nets such as RDF or SPARQL Ontologies: Stanford's Protégé is a popular yet complicated tool

bryanph commented 6 years ago

Hello JB,

Thanks for contacting me and sharing the links. I'll try to respond to some of your points below.

1. The representation I came up with is not particularly inspired by any of the theory you mention but lately I have done more reading on the subject and I think my approach is positioned compared to existing work in formal knowledge representation in the following way:

I see every node as encompassing a "concept". The concept can either be abstract or something concrete. By using hierarchical links, you can abstract over multiple concepts to create a new concept. Direct linking in the system is not particularly done for semantic effect, but more for relating concepts together without providing a specific abstraction.

2. There are two types of relationships right now, a "hierarchical" relationship for abstracting concepts and a "normal" relationship which has no type attached to it.

I see the node type as a function of the abstractions that a given concept belongs to. So not explicitly specified, but implied by the user's use. The same could possible apply for the relationship type, I am not sure.

The reason for not including more node/relationship types is one of simplicity and flexibility. My goal for a PKB is not for it to represent a strict semantic network of concepts where all relationships and node types are strictly defined (in fact, I doubt this is possible). Instead, I see it more as a tool of thought. A flexible tool with enough semantic meaning to provide the user with an overview of their thought network (based on abstraction and linking), but not enough to bog you down when changes need to be made to the semantic structure of the network (I feel like this is the case with traditional semantic networks as I know them). The goal is to have a usable semantic system.

3. I'm not really reusing any main technologies. I use a graph database (neo4j) to represent the nodes/links and in the front-end I use d3 for the graph simulation.

That said, I am in no way an expert in any of this. I have a lot to learn about the subject matter and the design is anything but final. I would love to hear your thoughts on the matter. This is just what I have come up with over the last year and a half. Please let me know if you have more questions or if I am being unclear. I will try to find some time to write more about the design process and hopefully to update documentation.

PS: let's continue this conversation over mail if you wish to discuss this further: bryanhaakman@gmail.com

Best, Bryan