Fix lightbox and its links, tidy gates; refresh about portrait

.github/workflows/jekyll.yml

@@ -48,7 +48,7 @@ jobs:
       # together. If this assumption is ever wrong the build job fails and
       # `deploy` (needs: build) publishes nothing.
       - name: Setup Ruby
-        uses: ruby/setup-ruby@e81a8fa391b11a595c1b7ed84177cc0fe02faf83 # v1
+        uses: ruby/setup-ruby@e81a8fa391b11a595c1b7ed84177cc0fe02faf83 # v1.328.0
         # The version comes from .ruby-version (3.3+: html-proofer's
         # async→console dependency requires Ruby >= 3.3).
         with:
@@ -89,7 +89,7 @@ jobs:
         # parse, that every page carries a description and a canonical, that no
         # two pages share a description or title, and that each plugin hook left
         # its mark on the posts (script/check-plugin-output.rb). Each check maps
-        # to a defect this site actually shipped.
+        # to a defect that shipped here or would ship silently.
         run: script/validate-site.sh ./_site
       - name: Upload artifact
         # Nothing to publish from a PR run; the gates above are the whole point.

README.ko.md

@@ -225,6 +225,8 @@ kramdown이 내용을 그대로 보존해 `\(…\)`로 내보내므로 안전합
   디스플레이 `$$` 줄.
 - 마커 뒤에 언어 말고 다른 것이 붙은 코드 펜스, 닫히지 않은 펜스.
 - 게시일로 시작하지 않는 파일명, 그보다 늦은 `date:`.
+- `href`가 이미지 `src`와 다른 직접 쓴 `<a class="glightbox">`: 라이트박스가 그 페이지를
+  iframe으로 열고 사이트가 이를 거부합니다. 출처는 캡션에 적습니다.
 - ar5iv 링크: ar5iv는 잃어버린 그림 대신 대체 이미지를 HTTP 200으로 돌려줍니다.
   `arxiv.org/html/<id>v1/…`를 쓰거나 그림을 `assets/images/`에 복사합니다.
 

README.md

@@ -237,6 +237,8 @@ rules easiest to trip, each a page that renders wrong with every other gate gree
   a display `$$` line without blank lines around it.
 - a code fence with more than a language after the marker, or one never closed.
 - a file name that does not start with the posting day, or a `date:` after it.
+- a hand-written `<a class="glightbox">` whose `href` is not its image's `src`: the
+  lightbox loads the page in an iframe the site refuses. Credit the source in the caption.
 - an ar5iv link: ar5iv now answers a lost figure with a placeholder image and
   HTTP 200. Use `arxiv.org/html/<id>v1/…`, or copy the figure into `assets/images/`.
 

_includes/head.html

@@ -83,7 +83,7 @@
 		})();
 	</script>
 
-	<title>{{ html_title }}</title>
+	<title>{{ html_title | escape }}</title>
 	<meta name="description" content="{{ page_description | escape }}" />
 	{% if site.author %}
 	<meta name="author" content="{{ site.author }}" />

_posts/2026-07-27-ai-ready-data-semantic-layer-knowledge-graph-en.md

@@ -271,7 +271,7 @@ One algorithm name is worth pinning down, at the fourth stage. Microsoft GraphRA
 
 A figure from Peng et al.'s survey maps the same skeleton in academic vocabulary, and it adds one axis between indexing, retrieval, and generation: whether to pull retrieval results as nodes, triples, paths, or subgraphs. The difference between LightRAG and PathRAG in §4.4 is exactly this axis.
 
-<a href="https://arxiv.org/abs/2408.08921" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: The academic map of the GraphRAG pipeline — from G-Indexing through G-Retrieval and graph representation formats to G-Generation (source: Peng et al., Graph Retrieval-Augmented Generation: A Survey, 2024, Figure 2)">
+<a href="https://arxiv.org/html/2408.08921v2/x2.png" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: The academic map of the GraphRAG pipeline — from G-Indexing through G-Retrieval and graph representation formats to G-Generation (source: Peng et al., Graph Retrieval-Augmented Generation: A Survey, 2024, Figure 2)">
   <img src="https://arxiv.org/html/2408.08921v2/x2.png" alt="GraphRAG pipeline diagram. Starting from Graph Database and G-Indexing at lower left, flowing up into G-Retrieval (query expansion and decomposition, retrievers, merging and pruning). The middle Retrieval Results column lists nodes, triples, paths, subgraphs, and hybrids, while the Graph Format column converts to one of adjacency tables, natural language, code form, syntax trees, node sequences, or graph embeddings, feeding into G-Generation's pre-, mid-, and post-generation augmentation stages on the right to produce the final response." />
 </a>
 
@@ -281,7 +281,7 @@ The [GA announcement](https://aws.amazon.com/blogs/machine-learning/announcing-g
 
 The architecture diagram in the AWS blog draws the managed boundary exactly. Inside the dotted box marked "Graph Knowledge Base (managed by Amazon Bedrock)" — chunking, embedding, entity extraction, and graph storage — everything belongs to the service. What the user touches is only S3 ingestion and querying, outside the box.
 
-<a href="https://aws.amazon.com/blogs/machine-learning/build-graphrag-applications-using-amazon-bedrock-knowledge-bases/" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: The managed boundary — inside the dotted line (chunking, embedding, entities, graph storage) belongs to the service; only ingestion and querying belong to you (source: AWS Machine Learning Blog, Build GraphRAG applications using Amazon Bedrock Knowledge Bases, 2025 — AWS's own material)">
+<a href="https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2025/05/19/ML-18340_002_architecture.png" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: The managed boundary — inside the dotted line (chunking, embedding, entities, graph storage) belongs to the service; only ingestion and querying belong to you (source: AWS Machine Learning Blog, Build GraphRAG applications using Amazon Bedrock Knowledge Bases, 2025 — AWS's own material)">
   <img src="https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2025/05/19/ML-18340_002_architecture.png" alt="Bedrock Knowledge Bases GraphRAG architecture diagram. PDF and CSV files on the left flow into Amazon S3 (raw data), and inside the dotted 'Graph Knowledge Base (managed by Amazon Bedrock)' region, chunks, embeddings, and entities are created and stored in Amazon Neptune. A user question on the right passes through Amazon Bedrock, queries this managed region, and returns as an answer." />
 </a>
 
@@ -293,7 +293,7 @@ The middle ground holds open source toolkits. [AWS Labs' GraphRAG Toolkit](https
 
 There's a reason for listing all those names. What regaining control costs becomes tangible when you look at the toolkit's data model: instead of managed GraphRAG's three node types, you get six — Source, Chunk, Topic, Statement, Fact, Entity — plus relationships like `EXTRACTED_FROM`, `BELONGS_TO`, `SUPPORTS`, and `SUBJECT`/`OBJECT`, all of which you have to understand and maintain. Separating sentence-level Statements from the Facts that support them is what lets you trace an answer's evidence back to the source passage, and that traceability *is* the schema complexity.
 
-<a href="https://aws.amazon.com/blogs/database/introducing-the-graphrag-toolkit/" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: The price tag on control — instead of managed GraphRAG's three node types, you handle six (Source, Chunk, Topic, Statement, Fact, Entity) and the relationships among them (source: AWS Database Blog, Introducing the GraphRAG Toolkit, 2025 — AWS's own material)">
+<a href="https://d2908q01vomqb2.cloudfront.net/887309d048beef83ad3eabf2a79a64a389ab1c9f/2025/01/14/DBBLOG-4573-datamodel.png" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: The price tag on control — instead of managed GraphRAG's three node types, you handle six (Source, Chunk, Topic, Statement, Fact, Entity) and the relationships among them (source: AWS Database Blog, Introducing the GraphRAG Toolkit, 2025 — AWS's own material)">
   <img src="https://d2908q01vomqb2.cloudfront.net/887309d048beef83ad3eabf2a79a64a389ab1c9f/2025/01/14/DBBLOG-4573-datamodel.png" alt="The graphrag-toolkit lexical graph data model. A Source at the top has multiple Chunks hanging off it via EXTRACTED_FROM, with Chunks linked to each other by NEXT and PREVIOUS. Topics in the middle point at Chunks via MENTIONED_IN, and Statements below attach to Topics via BELONGS_TO. Entities at the bottom form Facts through SUBJECT, OBJECT, and RELATION, and Facts support Statements via SUPPORTS." />
 </a>
 
@@ -315,7 +315,7 @@ One [independent measurement](https://arxiv.org/abs/2502.11371) found constructi
 
 The first prescription came from KET-RAG itself, the same paper that produced the $33,000 estimate, and it's captured in their indexing diagram. Instead of sweeping the whole corpus with an LLM, extract only the key chunks with conventional GraphRAG to build a **KG skeleton**, and lay down a text-keyword bipartite graph over the rest using word tokenization with no LLM at all — a two-tier structure. At query time, a ratio $$\theta$$ splits how much gets retrieved from each tier: the expensive tier thin, the cheap tier thick.
 
-<a href="https://arxiv.org/abs/2502.09304" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: Expensive tier thin, cheap tier thick — overlaying an LLM-extracted KG skeleton with an LLM-free text-keyword bipartite graph to cut indexing cost (source: Huang, Zhang, Xiao, KET-RAG, 2025, Figure 1)">
+<a href="https://arxiv.org/html/2502.09304v2/x1.png" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: Expensive tier thin, cheap tier thick — overlaying an LLM-extracted KG skeleton with an LLM-free text-keyword bipartite graph to cut indexing cost (source: Huang, Zhang, Xiao, KET-RAG, 2025, Figure 1)">
   <img src="https://arxiv.org/html/2502.09304v2/x1.png" alt="KET-RAG architecture diagram. In the indexing stage below, input text is (1) grouped into a KNN graph, then (2) only part of it becomes a KG Skeleton via conventional GraphRAG, while (3) word and sentence tokenization builds a Text-Keyword bipartite graph linking keywords like Juliet, Romeo, and Hamlet to text chunks. In the retrieval and generation stage above, a query, a length budget, and the retrieval ratio theta feed (4) retrieval from both tiers, then (5) the merged context goes to the LLM to produce the final answer." />
 </a>
 
@@ -343,7 +343,7 @@ The third prescription comes from academic follow-ups. Where the first two touch
 
 What original GraphRAG and the two follow-ups just described pick up from the same graph is compressed into one figure from the PathRAG paper. Red marks what actually enters the prompt.
 
-<a href="https://arxiv.org/abs/2502.14902" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: Same graph, different retrieval scope — (a) GraphRAG takes whole communities, (b) LightRAG takes all neighbors of the query nodes, (c) PathRAG takes only the relational paths connecting them (source: Chen et al., PathRAG, 2025, Figure 1)">
+<a href="https://arxiv.org/html/2502.14902v1/x1.png" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: Same graph, different retrieval scope — (a) GraphRAG takes whole communities, (b) LightRAG takes all neighbors of the query nodes, (c) PathRAG takes only the relational paths connecting them (source: Chen et al., PathRAG, 2025, Figure 1)">
   <img src="https://arxiv.org/html/2502.14902v1/x1.png" alt="Graph diagram comparing retrieval scope across three methods. In (a) GraphRAG, entire community ellipses are shaded red, pulling information at community granularity. In (b) LightRAG, nearly all neighbor nodes attached to query-relevant nodes like plants, aphids, and device are selected in red. In (c) PathRAG, only the thick red paths connecting those same query nodes remain, while surrounding nodes like sun, water, and oak stay blue and excluded." />
 </a>
 
@@ -421,7 +421,7 @@ The mechanism behind it is a checkable claim: with metric calculation pinned dow
 
 The stack diagram Databricks published alongside shows the arrangement at a glance. Metric views — holding metric, dimension, and relationship modeling — sit as one layer inside the catalog, and three consumption paths (dashboards, Genie, SQL and notebooks) **all pass through that one layer** to get their numbers. The point is that metrics don't get redefined per path — and this arrangement, with metric definitions living inside the catalog, leads straight into the discovery and permission problems of the next section.
 
-<a href="https://www.databricks.com/blog/redefining-semantics-data-layer-future-bi-and-ai" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: Three consumption paths, one metric definition — dashboards, Genie, and SQL all pass through the catalog's Metric views to get the same numbers (source: Databricks, Announcing General Availability and Open Sourcing of Unity Catalog Business Semantics, 2026-04-02 — vendor's own material)">
+<a href="https://www.databricks.com/sites/default/files/inline-images/ga-unity-catalog-business-semantics-02-1.png" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: Three consumption paths, one metric definition — dashboards, Genie, and SQL all pass through the catalog's Metric views to get the same numbers (source: Databricks, Announcing General Availability and Open Sourcing of Unity Catalog Business Semantics, 2026-04-02 — vendor's own material)">
   <img src="https://www.databricks.com/sites/default/files/inline-images/ga-unity-catalog-business-semantics-02-1.png" alt="Unity Catalog Business Semantics stack diagram. The large box below is Unity Catalog Business Semantics, and inside its dotted Metric views region, pre-computation for performance, measures and dimensions, and relationship modeling are stacked in layers. Three arrows rise from there to connect to the three consumption paths: AI/BI dashboards, Genie natural language queries, and SQL and notebooks." />
 </a>
 
@@ -619,7 +619,7 @@ More uncomfortable is the variance between models. Same corpus, same procedure,
 
 The paper patches this fragmentation with post-processing: splitting compound nodes that swallowed whole sentences, then grouping scattered fragments under higher-level concepts. How one sentence changes through that process is captured in the paper's first figure. Take a sentence reporting that TV viewing at 12 months is negatively associated with cognitive ability at 4.5 years. Initial extraction produces one compound node lumping the whole sentence together (association between … and …). Splitting decomposes it into individual entities, and abstraction groups them under higher concepts like infant media exposure to connect the scattered islands. The color coding marks what entity deduplication, pronoun resolution, and provenance tracking each contribute at every stage.
 
-<a href="https://arxiv.org/abs/2510.11297" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: From compound nodes to splitting to higher-concept abstraction — how one sentence's triples change across three stages (source: Chen et al., Are Large Language Models Effective Knowledge Graph Constructors?, 2025, Figure 1)">
+<a href="https://arxiv.org/html/2510.11297v1/x1.png" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: From compound nodes to splitting to higher-concept abstraction — how one sentence's triples change across three stages (source: Chen et al., Are Large Language Models Effective Knowledge Graph Constructors?, 2025, Figure 1)">
   <img src="https://arxiv.org/html/2510.11297v1/x1.png" alt="Diagram of triple changes as one sentence passes through three stages. From the example sentence at the bottom, Initial Extraction produces an 'association between …' compound node lumping the whole sentence together; Splitting decomposes it into reference triples pointing at individual entities; and Abstraction produces is_an_instance_of triples grouping them under higher concepts like 'infant media exposure' and 'child cognitive development'. The legend at right marks green as entity deduplication, purple as pronoun resolution, and orange as provenance tracking." />
 </a>
 
@@ -660,7 +660,7 @@ The paper prescribes two remedies: route by query type, or integrate both result
 
 These outcomes mostly survive adding retrieval post-processing. The same evaluation crossed in two techniques. **Reranking** rescores retrieved chunks to change their order. **IRCoT** alternates retrieval and reasoning, asking after each round what else to look for given the evidence gathered so far, rather than answering in one shot. Both were applied, and the per-query-type advantages held.
 
-<a href="https://arxiv.org/html/2502.11371v3/#S4.F1" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: QA performance by reasoning strategy (Rerank, Vanilla, IRCoT) — vector RAG leads on single-hop (NQ) and graph-based HippoRAG2 leads on multi-hop (MultiHop-RAG), regardless of strategy (source: Han et al., RAG vs. GraphRAG: A Systematic Evaluation and Key Insights, 2025, Figure 1)">
+<a href="https://arxiv.org/html/2502.11371v3/x1.png" class="glightbox" data-gallery="ai-ready-data-en" data-glightbox="title: QA performance by reasoning strategy (Rerank, Vanilla, IRCoT) — vector RAG leads on single-hop (NQ) and graph-based HippoRAG2 leads on multi-hop (MultiHop-RAG), regardless of strategy (source: Han et al., RAG vs. GraphRAG: A Systematic Evaluation and Key Insights, 2025, Figure 1)">
   <img src="https://arxiv.org/html/2502.11371v3/x1.png" alt="Two line charts comparing QA performance by reasoning strategy. On the left, NQ (single-hop), vector RAG maintains the highest F1 across all three strategies (Rerank, Vanilla, IRCoT). On the right, MultiHop-RAG (multi-hop), graph-based HippoRAG2 is highest across all three. Changing strategy preserves the ordering among methods, except that MultiHop-RAG's Community-GraphRAG (Local) drops below Vanilla under IRCoT." />
 </a>