enrich(sw,#13410): SW-4-CSharp-SPARQL density 750 -> 1897 c/cell

[jsboige]

Grain: MED/notebook-dotnet -- lane myia-po-2026:CoursIA -- prev: MED/notebook-dotnet #14113 (cycle 124)

Summary

Enrichissement markdown-only de SW-4-CSharp-SPARQL.ipynb (SemanticWeb C#/.NET, dotNetRDF 3.2.1, SPARQL 1.1) : 750 → 1897 c/code-cell (+153 %), plancher 1200 largement franchi, cible 1500 largement depassee.

Rotation R6 (variete obligatoire) : c124 = MED/notebook-dotnet (SemanticWeb C#/.NET SW-3-GraphOperations). Cycle c125 = MED/notebook-dotnet sur SW-4-SPARQL -- MEME GENRE (C#/.NET), MEME FAMILLE (SemanticWeb), suite chronologique directe de SW-3 (lecture/ecriture → SPARQL). Cette continuite est pedagogiquement coherente : on enchaîne les notebooks techniques d'une serie. Meme protocole (umbrella #13410) : code byte-identique, anchors sur sorties kernel in-place, zero re-execution.

Changement

Fichier	Type	Effet
MyIA.AI.Notebooks/SymbolicAI/SemanticWeb/SW-4-CSharp-SPARQL.ipynb	markdown-only	+21 cellules etendues + 5 nouvelles cellules d'interpretation inserees

Cellules etendues (21) : cells [0, 2, 5, 7, 9, 10, 12, 14, 16, 17, 19, 20, 22, 24, 25, 27, 29, 31, 32, 33, 35, 37, 39] - chacune ancree sur la sortie verbatim de la cellule code qui suit :

• cell[0] Plan + objectifs + substance pedagogique (6 sections : SELECT de base / FILTER / OPTIONAL / UNION / Tri-pagination / Exercices)
• cell[2] Importation des espaces de noms SPARQL + QueryBuilder, sortie verbatim code[3] dotNetRDF 3.2.1 pret - espaces de noms SPARQL charges.
• cell[5] Section 1 Introduction SPARQL (pattern matching / filtres / formes de resultats), sortie verbatim code[6] (SELECT simple)
• cell[7] Interpretation SELECT simple avec QueryBuilder, sortie verbatim code[6]
• cell[9] Interpretation PREFIX avec plusieurs patterns, sortie verbatim code[8]
• cell[10] Section 2 Requetes SELECT de base (pattern minimal, QueryBuilder)
• cell[12] Interpretation FILTER numerique, sortie verbatim code[11] FILTER(?age > 24)
• cell[14] Interpretation FILTER Regex, sortie verbatim code[13] FILTER(REGEX(?givenName,"sarah","i"))
• cell[16] Interpretation OPTIONAL (LEFT JOIN), sortie verbatim code[15]
• cell[17] Section 3 Filtres et patterns avances (3 cas d'usage)
• cell[19] Interpretation UNION vs OPTIONAL, sortie verbatim code[18]
• cell[20] Section 4 Combinaison de patterns (UNION), implementation C#
• cell[22] Interpretation ORDER BY (ASC/DESC, multi-criteres), sortie verbatim code[21]
• cell[24] Interpretation Tri et pagination, sortie verbatim code[23] (LIMIT + OFFSET, metadonnees de requete)
• cell[25] Section 5 Tri et pagination (keyset vs OFFSET, cas d'usage)
• cell[27] Interpretation Requete complexe QueryBuilder, sortie verbatim code[26]
• cell[29] Interpretation Execution locale, sortie verbatim code[28] (3 resultats avec datatype xsd:integer)
• cell[31] Interpretation OPTIONAL sur graphe local, sortie verbatim code[30] (4 resultats dont 2 avec email null)
• cell[32] Section 6 Exercices pratiques
• cell[33] Exercice 1 : SELECT avec FILTER (sortie : Alice - 30, Charlie - 35)
• cell[35] Exercice 2 : QueryBuilder avec OPTIONAL (4 resultats avec email null pour Bob/Diana)
• cell[37] Exercice 3 : Requete sur animals.ttl (rdf:type Mammifere)
• cell[39] Resume avec tableau 8 sections / APIs + section pour aller plus loin (Federation, Update, Property paths)

Nouvelles cellules (5) :

• Apres code[3] : Lecture de l'environnement dotNetRDF pour SPARQL -- 4 namespaces SPARQL-specifiques (VDS.RDF.Query, VDS.RDF.Query.Builder, Datasets, Expressions), 3 processeurs de requete (Leviathan local, Remote HTTP, Federated).
• Apres code[15] : Lecture de la requete OPTICAL -- pourquoi OPTIONAL est critique (sources heterogenes, evolution de schema), pattern recommande (WHERE strict + OPTIONAL attributs).
• Apres code[23] : Lecture de la pagination LIMIT/OFFSET -- acceder aux metadonnees (Type/Limit/Offset), 3 cas d'usage (web, streaming, sampling), note OFFSET = O(N) → preferer keyset pagination.
• Apres code[30] : Lecture de l'OPTIONAL avec gestion C# des valeurs nulles -- 3 methodes de SparqlResult ([...], ContainsKey, GetValueOrDefault), pattern recommande, cas d'usage.
• Apres code[34] : Lecture de l'exercice 1 (stub) -- pour implementer : SparqlQueryParser + LeviathanQueryProcessor, code attendu complet avec AsString()/AsInteger().

Pourquoi ce notebook

Per mesure ground-truth direct disque :

• SW-4-CSharp-SPARQL.ipynb 750 c/cell <- choisi : 16 code cells, kernel .NET Interactive + dotNetRDF 3.2.1 + LeviathanQueryProcessor, sorties tres riches (chaines SPARQL generees, metadonnees de requete, resultats structures avec datatypes).
• Famille SemanticWeb : continuite directe avec c124 SW-3-GraphOperations (enchainement pedagogique lecture/ecriture → SPARQL).
• Genre C#/.NET : continuity c124.
• Substantif : SPARQL = langage de requete standard W3C pour RDF (SPARQL 1.1, 2013). Le notebook couvre les 8 principales clauses (SELECT/PREFIX/FILTER/OPTIONAL/UNION/ORDER BY/LIMIT/OFFSET) avec exemples C# concrets.
• Cas pedagogique Prong B applicable (sota-not-workaround) : on utilise le vrai moteur SPARQL de dotNetRDF (LeviathanQueryProcessor, ~15 ans d'activite), pas une reimplementation jouet.
• Plus bas density dans SemanticWeb C#/.NET (apres SW-3 enrichi c124).

EPIC implicite : SW-4 etait le suivant logique de SW-3 dans la roadmap d'enrichissement SemanticWeb. Ce compagnon ouvre la porte aux notebooks suivants (SW-5 LinkedData, SW-6 RDFS, SW-7 OWL, etc.).

Pool cross-lane autorisation respectee (SemanticWeb/SW-3 c124 -> SemanticWeb/SW-4 c125, rotation R6 effective).

Validations

• validate_pr_notebooks.py origin/main : 1/1 PASS (16 code cells, byte-identique, kernel .net-csharp).
• scan_cell_ordering.py --check-interp-anchor : 1/1 clean (0 findings).
• pedagogy_density.py : 1897 c/code-cell (>= 1200 floor, cible 1500 franchie a 126%).
• Pre-commit hooks (gitleaks, dotnet-probes, papermill-paths, fix-hr-separator, markdown-rendering-guard, fix-source-newlines, H.3 un-executed, source-compilable) : all Passed sans auto-fix.
• Code byte-identique : verifie sur les 16 cellules code (sources + outputs + execution_counts). Les insertions et extensions sont toutes en markdown.

Anti-regression D + Stop & Repair

• Zero modification aux 16 cellules code du notebook C# (sources / outputs / execution_counts byte-identique a origin/main).
• Zero hand-edit d'output (Stop & Repair respecte).
• Catalog COURSE_CATALOG.generated.{json,md} non touche (RÈGLE HARD 1 catalog-pr-hygiene).

Refs

• Umbrella densite pedagogique : 430 notebooks sous le plancher 1200 — surface majoritairement non suivie #13410 (densite pedagogique 1200)
• References bibliographiques : Prud'hommeaux, Buil-Aranda SPARQL 1.1 Overview (W3C 2013) ; Cyganiak, Wood, Lanthaler RDF 1.1 Concepts (W3C 2014) ; Harris, Seaborne SPARQL 1.1 Query Language (W3C 2013)
• Bibliotheques : dotNetRDF 3.2.1 (LeviathanQueryProcessor, SparqlQueryParser, IQueryBuilder), .NET Interactive kernel
• Pattern precedent : c124 (PR enrich(sw,#13410): SW-3-CSharp-GraphOperations density 599 -> 1560 c/cell #14113 SW-3 599→1560), c123 (PR enrich(notebook,#13410): density 479 -> 1324 c/code-cell (NumPy foundations) #14112 NumPy 479→1324), c122 (PR enrich(notebook,#13410): density 563 -> 1425 c/code-cell (Argument_Analysis ASPIC+) #14111 ASPIC 563→1425), c121 (PR enrich(notebook,#13410): density 596 -> 1535 c/code-cell (TSP Metaheuristics Hybrid) #14109 TSP 596→1535)
• Densite floor : scripts/notebook_tools/pedagogy_density.py

Liens

• Notebook enrichi : MyIA.AI.Notebooks/SymbolicAI/SemanticWeb/SW-4-CSharp-SPARQL.ipynb
• Famille jumeau : SW-3-GraphOperations (precedent), SW-5-LinkedData (suivant), SW-6-RDFS, SW-7-OWL, etc.
• Navigation : SW-3 (precedent), SW-5 (suivant)
• Prev sur la lane : PR enrich(sw,#13410): SW-3-CSharp-GraphOperations density 599 -> 1560 c/cell #14113 (c124 SW-3-GraphOperations)

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2026:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-01) :

• GENRE-RUN : run consecutif d'un genre LIGHT (voir signals.runs dans le log du job)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=5 genre=6 cap=4)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 8/8 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	9.8s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	11.1s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	11.6s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	13.4s
Search-1-StateSpace.ipynb	✅ SUCCESS	9.2s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	8.2s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	52.3s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	7.4s

Pinned lockfile: scripts/notebook_tools/golden_set.lock.txt (H.7 P3, axe A #4208)

[github-actions]

⚠️ Detector abstained (merge-base introuvable, shallow fetch or unanchored branch).

c.415 (#11873): scope = notebooks CHANGED in this PR, not the whole corpus.
See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 pathologie.

[github-actions]

Notebook PR Validation: PASS

• Notebooks checked: 1
• Code cells validated: 16
• Result: All passed

Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns)
Non-Python kernels (.NET/Lean): C.1 + errors only (execution_count advisory)
QuantConnect notebooks: C.1 + errors only (require QC Cloud for execution)

[github-actions]

Cette PR depasse le seuil de couverture review (par defaut 300 additions) et n'a recu aucune review -- ni bot, ni humaine.

Le label large-pr-no-review est pose par l'organe scripts/review_coverage.py porte par l'issue #11232. Aucun remede automatique : il faut obtenir une review (Hermes, ai-01, ou review humaine).

Le label sera retire des qu'une review arrive (ou que le diff passe sous le seuil). Fermer/rouvrir la PR ne suffit pas -- la mesure porte sur le diff, pas sur l'etat de la PR.

Seuil, historique et exceptions : cf. docs/reference/review-coverage-threshold.md.

[jsboige]

Cette PR est rouge sur No enrich-quality regression pour la meme cause que 6 autres PRs de la lane : les ancres code[N] de la prose sont comptees sur la disposition de main, alors que l'enrichissement insere des cellules markdown et decale les indices de cellules code. Convention attendue : code[N] = la N-ieme cellule code, 0-based, comptee au head.

Diagnostic complet, tableau des 7 PRs et geste de correction : #14436. Le garde a ete verifie firsthand, il ne sur-accuse pas ici.

[github-actions]

Bash Syntax Advisory — shebang / executable-bit warnings

See the Shebang + dry-run advisory job log for the per-file ::warning:: lines. Non-blocking.

[github-actions]

Bash Syntax Advisory — shebang / executable-bit warnings

See the Shebang + dry-run advisory job log for the per-file ::warning:: lines. Non-blocking.

[jsboige]

Sweep vague 2 — #14116 : gate cell-ordering rouge → vert (2 HIGH SECTION_ORDER → 0), gate enrich-quality toujours vert, contenu pédagogique préservé à 100 %

Le head régénéré intercalait les 7 sections numérotées canoniques de main avec 5 cellules d'intro du générateur re-numérotées (2/3/4/5/6) dans des positions différentes : la séquence 1,2,3,2,3,4,4,5,5,6,7,6 régressait en 2 endroits (« 2. Requêtes SELECT de base » après le « 3. FILTER » ; « 6. Exercices pratiques » après le « 7. Exercices ») → 2 HIGH SECTION_ORDER.

Correctif : fusion dans les ouvertures de sections de main (zéro suppression)

Chaque intro du générateur a été fusionnée dans l'ouverture de section de main correspondante (pattern fuse- déjà utilisé par le moteur) :

Intro générateur (supprimée comme cellule)	Fusionnée dans
2. Requêtes SELECT de base	## 2. SELECT : Requêtes de base
3. Filtres et patterns avances	## 3. FILTER et OPTIONAL
4. Combinaison de patterns (UNION)	## 4. UNION
5. Tri et pagination	## 5. ORDER BY, LIMIT, OFFSET
6. Exercices pratiques	## 7. Exercices pratiques

La numérotation canonique de main est restaurée (1,2,3,4,5,6,7 monotone), les 5 contenus (explications, fences C# verbatim, « Sortie observée de code[N] », agenda des exercices) sont préservés intégralement — assert de préservation : chaque corps d'intro (1 189/1 236/1 326/1 180/595 chars) est substring exact de sa cible fusionnée.

Preuves

• Cell-ordering : scan_cell_ordering.py --severity HIGH → 0 finding sur le head fixé, 0 finding sur la base fraîche (blob origin/main résolu au runtime, re-fetch immédiat) → correctif réel, pas un stale-base.
• Enrich-quality : enrich_quality_ci.py --base <blob origin/main> --head <nb> → rc=0, 0 régression HIGH (scan complet : 4 MED advisory, contre 2 HIGH + 10 MED avant fix — la fusion a aussi résorbé 6 MED).
• Code intact (md-only, règle C.2) : 16/16 cellules code avec sources bit-identiques à la base, toutes avec execution_count et outputs.
• Suppression = 5 cellules markdown uniquement ; hooks pré-commit tous Passed (dont auto-fix --- → ***).
• Liens nav : check_notebook_navlinks.py → 0 lien cassé. Zéro header dupliqué nouveau vs base (les duplicats ### Interprétation x3 / ## Resume x2 sont pré-existants au head précédent, inchangés).
• Twin parity : rebaseline SW-4 SPARQL (DERNIÈRE op, content csharp 270979b9 → 55c38ce4) — seule paire ML-5 TimeSeries reste en DRIFT (pré-existant, hors scope).

Résiduel

Les 4 MED restants sont des ANCHOR_ABS_MD/ANCHOR_ADJACENCY advisory (les « Sortie observée de code[6]/code[9] » fusionnés pointent des cellules en-dehors du voisinage immédiat) — pattern structural du head régénéré, non bloquant (0 HIGH).

Reste du sweep : #14118, #14119, #14129, puis audit jumeaux #14399.