For Developers

This is where it gets technical. An overview of the architecture and technologies behind ChangingGraph.

Why a knowledge graph?

Data sitting in isolated databases is hard to link. A knowledge graph makes relationships the native data structure.

Comparison: Relational DB vs. Graph

Aspect	Relational DB	Knowledge Graph
Structure	Rigid tables	Flexible triples (subject-predicate-object)
Relationships	Foreign keys, JOINs	Native edges
Schema	Schema changes are expensive	Extensible without migration
Semantics	No built-in meaning	Ontologies define meaning
Interoperability	Proprietary	Open standards (RDF, SPARQL)

ActivityPub: more than microblogging

The Fediverse can do more than microblogging. Much more. But we act like Neanderthals clutching a rock, even though a power drill is sitting right next to us.

ActivityPub was specified for arbitrary object types — but almost every implementation reduces it to Notes and the Mastodon API. A flea-market item gets sent as a Note. A point of interest simply doesn't exist. The Client-to-Server API is effectively dead.

ChangingGraph changes that:

Semantic objects instead of Notes: a food item, a place, an offer, a recipe — objects in the Fediverse can finally be what they actually are, not just text with a hashtag.
SKOS taxonomies instead of hashtags: a dedicated SKOS tag on ActivityPub objects states explicitly which taxonomy an object belongs to. #regional can mean anything — a SKOS concept is unambiguous.
Client-to-Server API: ChangingGraph implements ActivityPub's C2S API. Not just server-to-server — clients can interact directly with the instance.
Federated knowledge graphs: not yet another platform, but the infrastructure that lets distributed data find itself without duplication.

Technology stack

RDF (Resource Description Framework)

ChangingGraph is built on RDF — the W3C standard for linked data.

Core principle: everything is a triple.

<Apple> <isA> <Fruit> .
<Apple> <contains> <VitaminC> .
<VitaminC> <amount> "5mg/100g" .

SPARQL

The query language for RDF. Similar to SQL, but for graphs.

Example: find all food items high in vitamin C

SELECT ?food ?vitaminC WHERE {
  ?food a cg:Food ;
        cg:hasNutrient ?nutrient .
  ?nutrient cg:nutrientType "Vitamin C" ;
            cg:amount ?vitaminC .
  FILTER(?vitaminC > 20)
}

Ontologies

ChangingGraph uses existing ontologies and extends them:

FoodOn — Food Ontology (food classification)
ChEBI — Chemical Entities (ingredients)
Wikidata — links to general knowledge
SKOS — taxonomies and classifications

Data sources

ChangingGraph integrates data from multiple sources:

Bundeslebensmittelschlüssel (BLS)

The German national food reference database, with ~7,000 food items and ~120 nutrients per item.

Scientifically validated (Max Rubner-Institut)
Deep nutrient analysis (amino acids, fatty acids, vitamins, minerals)

Open Food Facts (planned)

Crowd-sourced product database with barcodes and branded products.

Enrichment

All data is enriched with SKOS taxonomies and linked to Wikidata, ChEBI and FoodOn.

Architectural principles

Design goals:

Modular: components are replaceable
Federatable: multiple instances can talk to each other
Open standards: RDF, SPARQL, ActivityPub
Data sovereignty: users control their data

Multi-repository design

Data is separated by domain:

Food Catalog: food items, nutrients, recipes
Actors: people, initiatives, organizations
User Data: personal nutrition data, symptoms

Content-addressed storage

Versioning via content hashes — similar to Git.

Every change to the data creates a new version; older versions remain available.

For researchers

Long-term, ChangingGraph aims to enable research:

SPARQL endpoint: for complex queries over the curated data (API access is paid)
Anonymized data: for nutrition studies (GDPR-compliant)
Data sources: built on public data (BLS, Open Food Facts) — the added value is in the semantic linking and curation

For developers

ChangingGraph is open to collaboration:

Standards-based: RDF, SPARQL, ActivityPub
Federated: own instances are possible
Extensible: modules and extensions supported

Open source as a goal: as soon as membership and donations make it sustainable.

Interested in collaboration or a technical exchange?

Contact: office@gsund.rocks