Julian's Polymath Explorations

(UPDATED Oct. 2023)   Now that we have discussed a full technology stack based on Neo4j (or other graph databases), and that we a design and implementation available from the open-source project BrainAnnex.org  , what next?  What shall we build on top? Well, how about  Full-Text Search ?  This article is part of a growing, ongoing series on Graph Databases and Neo4j Full-Text Searching/Indexing Starting with the  Version 5, Beta 26.1  release, the Brain Annex open-source project includes a straightforward but working implementation of a design that uses the convenient services of its Schema Layer , to provide indexing of word-based documents using Neo4j. The python class FullTextIndexing ( source code ) provides the necessary methods, and it can parse both plain-text and HTML documents (for example, used in "formatted notes"); parsing of PDF files and other formats will be added at a later date. No grammatical analysis ( stemming or lemmatizing ) is done on

Putting it All Together : a Technology Stack on top of a (Neo4j) Graph Database The above technology stack is explained in  this short video . (UPDATED Mar. 2024)  For many practical use cases, one needs a full data-management solution, not just a database.   So, armed with the Schema Layer discussed in the previous part , the next natural step is to add an API and possibly a UI . This article is part 6 of a growing,  ongoing  series  on Graph Databases and Neo4j   The API Layer / Data Manager The  API Layer ("Data Manager")  is in some ways the most straightforward layer - because the "heavy lifting" is done by the Schema Layer.   I've been involved in projects that utilized an inadequate Schema Layer - and in those situations the API Layer ends up taking on an immense amount of responsibility that don't logically belong there; the end result being a lot of difficult, error-prone and non-modular development that feels like "pulling teeth"! By co