# Possible Belief Network Queries

Belief networks are powerful tools for understanding the relationships between users' beliefs, their conversations, and the implications of these beliefs. Below are some queries that could be particularly useful.
This is a brainstorming session by chatGPT, prior to our developing a schema for storing all this.

## Common Beliefs Between Users

This query helps to find beliefs shared by two users, which could be the starting point for a meaningful conversation.

## Contradictory Beliefs

Identifying contradictions in a user's belief system can provide insights for discussion.

## Belief Implications

Exploring the deeper implications of a user's belief can reveal new topics for conversation.

## Influential Beliefs in Conversations

Finding which beliefs are most commonly discussed can indicate their importance within a community.

## Tracking Belief Changes Over Time

Observing the evolution of a user's beliefs can inform understanding of their current views.

## User's Influence on Beliefs

Identifying users who have influenced the spread of beliefs can highlight key conversationalists.

## Clusters of Related Beliefs

Detecting clusters of related beliefs can unveil patterns and commonalities in belief systems.
By utilizing these queries, we can facilitate more informed and productive conversations, and help to bridge the gaps in understanding between different user groups.

# Schema

I am in the process of designing a system to map and analyze the complex web of user beliefs, understandings, and their implications based on conversational data. The goal is to facilitate meaningful dialogue, uncover common ground, and provide insights into the logical structure of belief networks within diverse groups. To achieve this, I'm considering constructing an ontology and utilizing SPARQL for querying a graph database, which will efficiently manage the intricate relationships inherent in this data.
The next step is to develop a detailed schema for the ontology, which will involve defining the classes, relationships, properties, and rules necessary to accurately represent and reason about the domain of beliefs and conversations. The schema will need to be robust enough to capture nuanced relationships and flexible enough to accommodate the evolving nature of beliefs and discourse.

# A First SparQL Schema
## Classes

* User: Engages in conversations, holds beliefs.
* Belief: Assertions held true by users.
* Meta-Belief: Beliefs about relationships between other beliefs.
* Reasoning: Justifications for why one belief supports or contradicts another.
* Statement: Expressions of beliefs by users.
* Conversation: Collections of statements exchanged between users.
* Timestamp: Specific times when statements are made or beliefs are expressed.

## Relationships

* HoldsBelief (User-Belief): Associates users with the beliefs they hold.
* ExpressesStatement (User-Statement): Links users with statements they make.
* PartOfConversation (Statement-Conversation): Connects statements to the conversations they belong to.
* SupportsBelief (Belief-Meta-Belief): Identifies supportive relationships between beliefs, justified by Meta-Belief.
* ContradictsBelief (Belief-Meta-Belief): Identifies contradictory relationships between beliefs, justified by Meta-Belief.
* Discusses (Conversation-Reasoning): Associates conversations with the reasoning they contain.

## Properties

* hasTimestamp (Statement, Conversation): Indicates when a statement or conversation occurred.
* hasJustification (SupportsBelief, ContradictsBelief): References the reasoning behind the relationship.

## Rules

* InferenceRule1: A user expressing a statement supporting a belief holds that belief, based on referenced Meta-Belief.
* InferenceRule2: A user holding a belief supporting another belief also holds the second belief, justified by Meta-Belief.

## Additional Pieces

The SQL database will handle the creation of new statements, users, conversations (w/ IDs), and will be used to store the full text of statements. We may also add a more sophisticated search component, but the hope is to handle this entirely with the ```vector companion```.

## Vector companion

The vector database will handle semantic search on statements, with each entry simply identified by an ID number which connects on an index to the SQL database.

# Conversation Ontology (second draft)
## Definitions

* User: Individuals who participate in conversations.
* Statement: Assertions, questions, or any utterances made by a user.
* MetaStatement: A higher-order statement that describes a relationship between two statements.
* Conversation: A series of statements exchanged between users.

## Relationships

* authors (User, Statement): Connects users to the statements they make.
* participatesIn (User, Conversation): Connects users to the conversations they are part of.
* comprises (Conversation, Statement): Connects conversations to the statements that make them up.
* respondsTo (Statement, Statement): Connects a statement to another statement it is responding to.
* relates (MetaStatement, Statement): Connects a meta-statement to the statements it describes.

## Properties

* hasTimestamp (Statement, MetaStatement, Conversation): Indicates when a statement, meta-statement, or conversation took place.
* hasType (MetaStatement): Specifies the type of relationship between statements (e.g., support, contradiction, synonymy).
* hasEquivalentExpressionVector (Statement): Associates statements with their vector representations for searching.

## Rules

* InferenceRule1: If a MetaStatement of type "supports" relates statements AA and BB, and another MetaStatement of the same type relates statements BB and CC, then it can be inferred there exists a MetaStatement indicating AA supports CC.
* InferenceRule2: If a MetaStatement of type "contradicts" relates statements AA and BB, and another MetaStatement of the same type relates statements BB and CC, then it can be inferred there exists a MetaStatement indicating AA supports CC.

# Technology
## Blazegraph

"Blazegraph™ DB is a ultra high-performance graph database supporting Blueprints and RDF/SPARQL APIs. It supports up to 50 Billion edges on a single machine. It is in production use for Fortune 500 customers such as EMC, Autodesk, and many others. It is supporting key Precision Medicine applications and has wide-spread usage for life science applications. It is used extensively to support Cyber analytics in commercial and government applications. It powers the Wikimedia Foundation's Wikidata Query Service."
"The Blazegraph product covers all application needs starting from small applications with embedded storage, to larger standalone applications, and up to 50B statements stored in NanoSparqlServer. There are different operating modes (triples, provenance, and quads), and 100s of configuration options."
Once you download the JAR file it's as simple as:
And you can access the sparql endpoint through

## Others

* Apache Jena Fuseki: It is a popular RDF database with a SPARQL endpoint. Jena Fuseki can be optimized for performance and is widely used.
* Stardog: Offers enterprise-level capabilities and supports SPARQL queries with strong consistency and high availability features.
* Virtuoso: An RDF store that provides high-performance SPARQL query capabilities and is designed for scalability.
* GraphDB: Focuses on efficient data management and offers powerful SPARQL query optimization for large datasets.
* Amazon Neptune: A managed graph database service that is optimized for storing billions of relationships and querying the graph with milliseconds latency.
* ↑ Blazegraph
* ↑ [https://github.com/blazegraph/database/wiki BlazeGraph Wiki