Skip to content

Commit 1eef112

Browse files
claudeclaude
committed
Add side-capture: LinkedIn post on Semantic Knowledge Graphs
Record a LinkedIn post (urn:li:activity:7428445073249521664) flagged by Dinis Cruz for future follow-up once Issues-FS supports converting its graph data into Semantic Knowledge Graph formats (RDF, OWL, JSON-LD). The document maps the natural evolution from Issues-FS's existing graph-native architecture to formal semantic web standards, lists prerequisites for activation, and cross-references current implementation work (.issues parser, Graph__Repository integration, Lexicon architecture). Status: Pending (waiting for SKG export capability). https://claude.ai/code/session_01Sk3ihGTCicEo3dHVs6iXXW
1 parent ee6070a commit 1eef112

1 file changed

Lines changed: 118 additions & 0 deletions

File tree

‎docs/side-captures/v0.1.0__side-capture__linkedin-semantic-knowledge-graphs.md‎

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
# Side-Capture: LinkedIn Post -- Semantic Knowledge Graphs
2+
3+
**Document:** side-capture__linkedin-semantic-knowledge-graphs
4+
**Version:** v0.1.0
5+
**Date:** 2026-02-15
6+
**Status:** Pending
7+
**Author:** Librarian Role
8+
**Captured From:** Dinis Cruz (human lead) -- flagged for future follow-up
9+
**Follow-Up Trigger:** Issues-FS gains Semantic Knowledge Graph (SKG) export capability
10+
11+
---
12+
13+
## 1. Source
14+
15+
**LinkedIn Post URL:** https://www.linkedin.com/feed/update/urn:li:activity:7428445073249521664/
16+
17+
**Content status:** Not fetched. LinkedIn's authentication wall prevents automated retrieval. The post content should be read manually by the human lead or by a session with LinkedIn access, and this document updated accordingly.
18+
19+
**Action for Dinis:** When reviewing this side-capture, please paste or summarise the post content here so that future sessions have the full context without requiring LinkedIn access.
20+
21+
---
22+
23+
## 2. Why This Is Relevant to Issues-FS
24+
25+
Issues-FS is, at its core, a graph system. Everything is a node; meaning comes from edges. The entire architecture -- from the `.issues` flat file format through the Graph__Repository integration to the MGraph-DB storage layer -- is built on the principle that graph structure IS the data model, not a projection of it.
26+
27+
Semantic Knowledge Graphs (RDF, OWL, JSON-LD, SPARQL) are the standardised expression of this same principle in the wider knowledge representation world. The connection between Issues-FS's internal graph model and external semantic web standards is not a stretch or a bolt-on -- it is a natural extension of what the system already does.
28+
29+
The specific edges that make this connection meaningful:
30+
31+
| Issues-FS Concept | Semantic Web Equivalent | Nature of Connection |
32+
|-------------------|------------------------|---------------------|
33+
| Node types (Task, Bug, Epic, Decision, etc.) | OWL Classes | Issues-FS types map directly to ontology classes |
34+
| Edge types (depends_on, blocks, parent_of, etc.) | OWL Object Properties | Relationship types become formal predicates |
35+
| Node properties (status, priority, assignee) | OWL Data Properties / RDF Literals | Properties map to typed literals |
36+
| Lexicon anchor nodes | Ontology concepts / SKOS Concepts | The Lexicon IS a lightweight ontology already |
37+
| Graph__Repository (multi-repo discovery) | Named Graphs / RDF Datasets | Each repository's graph becomes a named graph |
38+
| Cross-references in `.issues` files | RDF triples (subject-predicate-object) | Cross-refs are already edges; they need only serialisation |
39+
40+
The leap from "graph-native issue tracker" to "semantic knowledge graph exporter" is architecturally small but strategically large. It would allow Issues-FS data to be:
41+
42+
- **Queried via SPARQL** -- enabling complex queries across issue graphs that go beyond what flat search or simple filtering can do
43+
- **Connected to external ontologies** -- linking issue data to domain-specific knowledge bases (security taxonomies, software architecture ontologies, project management standards)
44+
- **Consumed by semantic reasoning engines** -- enabling inference over issue relationships (e.g., transitive dependency chains, impact analysis via graph traversal with formal semantics)
45+
- **Interoperable with knowledge management tools** -- any tool that understands RDF/JSON-LD can consume Issues-FS data without a custom integration
46+
47+
---
48+
49+
## 3. Prerequisites Before Follow-Up
50+
51+
This side-capture should be revisited once the following capabilities exist in Issues-FS:
52+
53+
### Required
54+
55+
- [ ] **SKG export module**: A component that converts Issues-FS graph data (nodes, edges, types, properties) into standard semantic web formats (RDF, OWL, JSON-LD)
56+
- [ ] **SPARQL or equivalent query support**: The ability to query exported issue graphs using a semantic query language
57+
- [ ] **Ontology mapping layer**: A mapping from Issues-FS Lexicon anchor nodes and type schemas to a formal ontology (either a custom Issues-FS ontology or a mapping to existing ones like DOAP, FOAF, schema.org)
58+
59+
### Helpful but not blocking
60+
61+
- [ ] External ontology connectors (linking issue data to domain-specific knowledge bases)
62+
- [ ] JSON-LD context definition for Issues-FS data (enabling linked data consumption without full RDF export)
63+
- [ ] Graph visualisation of semantic relationships (extending existing Cartographer capabilities)
64+
65+
---
66+
67+
## 4. Current Implementation State (as of 2026-02-15)
68+
69+
What exists today that forms the foundation for eventual SKG support:
70+
71+
| Component | Status | Relevance to SKG |
72+
|-----------|--------|-------------------|
73+
| `.issues` flat file format parser | Implemented | Pipe-delimited, tab-indented hierarchy with cross-references -- already encodes graph structure in text |
74+
| Graph__Repository integration | Implemented | Multi-repo discovery, loading, and caching of `.issues` files into the graph model |
75+
| Check and normalise services | Implemented | Validates graph consistency -- a prerequisite for producing valid semantic output |
76+
| Schema validation with predefined type schemas | Implemented | Type schemas define the shape of nodes -- these become OWL class definitions |
77+
| CLI commands (`issues-fs check`, `issues-fs normalise`) | Implemented | The normalisation pipeline (`.issues` -> graph -> JSON) is the same pipeline that would produce RDF/JSON-LD output |
78+
| MGraph-DB graph model (nodes + edges) | Core | The in-memory graph representation is already structurally compatible with RDF triples |
79+
| Lexicon architecture | Designed | Anchor nodes with relationship edges -- this IS a lightweight ontology waiting for formal serialisation |
80+
81+
The path from current state to SKG export is: add a new serialisation target to the existing normalisation pipeline. Where today the pipeline outputs JSON files in folder structure, a future SKG pipeline would output RDF/Turtle, OWL, or JSON-LD. The graph traversal, type resolution, and relationship mapping are already implemented.
82+
83+
---
84+
85+
## 5. Cross-References
86+
87+
| Document | Relevance |
88+
|----------|-----------|
89+
| [Thinking in Graphs](../../../../modules/Issues-FS__Docs/docs/to_classify/v0_4_0__issues-fs__thinking-in-graphs.md) | Core philosophy -- "everything is a node; meaning comes from edges" -- is the same claim semantic web standards formalise |
90+
| [Architecture Overview](../../../../modules/Issues-FS__Docs/docs/issues_fs/architecture/v0.4.0__issues-fs__architecture-overview.md) | Defines the graph model, storage layers, and processing pipeline that SKG export would extend |
91+
| [Lexicon Architecture v2](../../../../modules/Issues-FS__Docs/docs/to_classify/v0_4_0__issues-fs__lexicon-architecture-v2.md) | The Lexicon's anchor nodes are the closest existing structure to an ontology; SKG export would formalise them |
92+
| [Memory-FS Abstraction Layer](../../../../modules/Issues-FS__Docs/docs/issues_fs/architecture/0.41.0__issues-fs__memory-fs-abstraction-layer.md) | Storage abstraction -- SKG export is a new output format, not a new storage backend |
93+
| Brief #14: Transformations, Round-Trips, and Ideas Library (v0.1.2) | Universal input/output transformations -- SKG export is a new transformation target in the same framework |
94+
| Brief #12: RSS Feed Processing with Semantic Text (v0.1.2) | Semantic text processing connects to the same knowledge representation space |
95+
| Brief #11: Multi-Persona Message Translation (v0.1.2) | Word-to-meaning connections are semantic graph operations |
96+
| [Librarian catalogue of Feb 10 briefs](../v0.2.1__catalogue__dinis-briefs-feb-10.md) | Cluster 8 (Semantic Text, Communication & Content) is the thematic home for SKG work |
97+
98+
---
99+
100+
## 6. When to Activate This Side-Capture
101+
102+
This document transitions from **Pending** to **Active** when:
103+
104+
1. An Architect decision (ADR) is created proposing SKG export as a feature
105+
2. OR a Dev branch begins implementing RDF/OWL/JSON-LD serialisation
106+
3. OR the LinkedIn post content (once read manually) reveals specific ideas, contacts, or approaches that should be acted on sooner
107+
108+
At activation, the Librarian should:
109+
- Re-read the LinkedIn post (with human assistance if auth wall persists)
110+
- Connect the post's specific claims to the Issues-FS SKG design
111+
- Create a Knowledge_Request or Task issue for the relevant work
112+
- Update this document's status to Active and add the activation context
113+
114+
---
115+
116+
*Issues-FS Librarian Role -- Side-Capture*
117+
*Version: v0.1.0*
118+
*Date: 2026-02-15*

0 commit comments

Comments
 (0)