kg-registry-validation

Validates KG-Registry resource page edits for schema compliance and provenance correctness.

27|5|Updated Sep 2, 2021

Search Tags:#provenance #schema validation #duckdb #kg-registry #curation QA #markdown resources #stub cleanup

Ready to run

npx skills add https://github.com/Knowledge-Graph-Hub/kg-registry --skill kg-registry-validation

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: kg-registry-validation
Source: https://github.com/Knowledge-Graph-Hub/kg-registry/tree/main/.agents/skills/kg-registry-validation
Command: npx skills add https://github.com/Knowledge-Graph-Hub/kg-registry --skill kg-registry-validation

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents KG-Registry resource pages from silently failing quality checks by ensuring schema compliance while also catching provenance-slot mistakes and stub-cleanup leftovers after curation edits.

Core Features & Use Cases

Structural validation for resource files: Runs local validation on a specific resource/<id>/<id>.md page and optionally prettifies before re-validating.
Curation-specific quality assurance: Confirms the page is still under resource/, contains required content signals (like at least one products entry), updates last_modified_date for the edit, avoids incorrectly setting curators, and ensures stub remnants were properly removed.
Provenance correctness checks: Verifies that original_source and secondary_source are proper SourceAssociation objects with valid source identifiers and appropriate default PROV-O relations for primary/secondary provenance.
Referenced ID resolvability and intent: Ensures source IDs are registry/product IDs (not URLs or labels) and that intentionally new upstream-derived identifiers are unique and safe rather than replaced with free text.

Quick Start

Use the skill to validate and quality-check a single edited resource file at resource/<id>/<id>.md by running the repository-local validation workflow from a local KG-Registry clone.

Frequently Asked Questions about kg-registry-validation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I validate KG-Registry resource markdown files after curation edits?▼

To validate KG-Registry resource markdown files after curation, run the local validation workflow using uv run make validate-file on the specific resource/<id>/<id>.md page to catch schema and provenance errors before merging.

What does provenance validation check for in KG-Registry curation QA?▼

Provenance validation in KG-Registry curation QA verifies that original_source and secondary_source are proper SourceAssociation objects containing valid registry or product IDs, ensuring correct PROV-O relation defaults for primary and secondary provenance tracking.

Why does my KG-Registry markdown page pass schema validation but fail curation quality checks?▼

A KG-Registry markdown page can pass schema validation but fail curation quality checks due to provenance-slot mistakes, incorrectly set curators, missing products entries, or leftover stub remnants that require stub-removal correctness verification.

Can I use DuckDB to quality-check stub cleanup and last_modified_date in resource markdown?▼

DuckDB is listed among the keywords for this workflow, but quality-checking stub cleanup and last_modified_date in resource markdown specifically requires running the repository-local uv run make validate-file command within your local KG-Registry clone.

How do I ensure source IDs in provenance fields are resolvable registry identifiers?▼

To ensure source IDs in provenance fields are resolvable, verify that original_source and secondary_source identifiers use KG-Registry resource or product IDs rather than URLs or free text labels, confirming intentionally new upstream-derived identifiers remain unique.

What are the limitations of running local validation on a single KG-Registry resource file?▼

Limitations of running local validation on a single KG-Registry resource file include its scope being restricted to individual resource/<id>/<id>.md checks, meaning it applies after curation edits and does not validate broader repository-wide structural dependencies.