Imported from OpenLinkSoftware/ai-agent-skills (kg-generator/SKILL.md). Install upstream with npx skills add OpenLinkSoftware/ai-agent-skills --skill kg-generator. Copyright stays with the author.

Knowledge Graph Generator Skill

Generate comprehensive, standards-compliant Knowledge Graphs from any file: or http[s]: URL. Produces RDF-Turtle by default; JSON-LD and other serializations available on request.

When to Use This Skill

• "Generate a knowledge graph from [URL]"
• "Generate RDF / RDF-Turtle from [URL]"
• "Generate JSON-LD from [URL]"
• "Convert this page to structured semantic data"
• "Extract schema.org data from [URL]"
• "Create an RDF rendition of this post/article/report"

Harness Alignment

This skill is a Knowledge Graph generation entry point. For document/source-to-RDF requests, interpret the request through the document-to-kg-skill Document-to-KG Harness Mode contract when that skill is available. For requests that also ask for HTML, Markdown, an infographic, or a KG Explorer, hand off to the rdf-infographic-skill RDF Infographic Harness Mode after RDF generation.

Do not let this skill drift into standalone HTML generation, source summarization, or manually invented graph visualization. RDF remains the source of truth, and companion HTML/Markdown artifacts must satisfy the RDF/HTML/MD pairing contract in rdf-infographic-skill.

Narrative and Visual-Communication Contract

When the RDF will drive a reader-facing document, model a coherent evidence-backed narrative spine rather than an undifferentiated fact inventory. Preserve the source's thesis, contrasts, causal chain, quantitative evidence, limitations, and conclusion as ordered, queryable entities and relationships. Model comparison dimensions, metric observations, claims, provenance, and SPARQL recipes explicitly so the companion document can communicate them through the most appropriate visual form.

For any visual or interactive companion, operate as a UI/UX expert, visual-communications designer, and storyteller, and inherit the full rdf-infographic-skill operating modality. The reader journey must determine hierarchy and pacing; tables serve exact comparisons, flows serve sequence or causality, diagrams serve architecture, charts serve quantitative patterns, and prose serves interpretation. Live SPARQL interaction is part of the story surface when it lets readers test or extend the document's claims; it must not be relegated to decorative or disconnected query text.

If this skill produces or templates any HTML directly, it must inherit the rdf-infographic-skill open-tab contract: every generated HTML <a> whose href is not a same-page fragment (#section) uses target="_blank" rel="noopener noreferrer", while same-page fragment navigation remains same-tab. Attribution links must hyperlink the attributed label itself, not generic labels such as Visit or Learn more.

SoftwareApplication IRI Alignment

When generated RDF introduces or normalizes a schema:SoftwareApplication, use the denotation priority rule shared with document-to-kg-skill and rdf-infographic-skill:

1. DBpedia IRI if a confident DBpedia resource exists.
2. Wikidata IRI if no confident DBpedia resource exists but a confident Wikidata entity exists.
3. Official product/application homepage URL with #this appended when neither can be confirmed.

When using a homepage fallback and a confirmed DBpedia/Wikidata identity exists, add owl:sameAs and declare owl: as http://www.w3.org/2002/07/owl#. Do not fabricate DBpedia or Wikidata IRIs.

Country IRI Alignment

When generated RDF introduces or normalizes a schema:Country, use the denotation priority rule shared with document-to-kg-skill and rdf-infographic-skill:

1. DBpedia country IRI if a confident DBpedia resource exists.
2. Wikidata country IRI if no confident DBpedia resource exists but a confident Wikidata entity exists.
3. Source-grounded document hash IRI only when neither DBpedia nor Wikidata can be confirmed.

When using DBpedia as the primary country IRI and a confirmed Wikidata equivalent exists, add owl:sameAs to the Wikidata entity. When using Wikidata as a fallback and a DBpedia equivalent later becomes available, normalize to DBpedia or add owl:sameAs if preserving an existing artifact is necessary. Do not use local document hash IRIs for known countries when DBpedia or Wikidata authority IRIs are available. Visible country names in HTML/Markdown companions and KG Explorer nodes must use the selected country IRI via the resolver pattern.

DefinedTerm / Glossary IRI Alignment

When generated RDF introduces schema:DefinedTerm or skos:Concept glossary entries, choose the subject IRI using this priority order:

1. Standards-body or platform IRI first — if the term has a well-known W3C, schema.org, IANA, or other standards-body IRI (e.g., Semantic Web → https://www.w3.org/2001/sw/#this), use that as the primary IRI with owl:sameAs linking to the document-local representation.
2. DBpedia IRI second — if no standards-body IRI exists but a confident DBpedia resource exists for the term, use via owl:sameAs from the document-local IRI.
3. Wikidata IRI third — if no confident DBpedia resource exists but a confident Wikidata entity exists, use the Wikidata IRI as the primary subject.
4. Document-local hash IRI — the most common case: use a source-grounded hash IRI derived from {page_url} with a mnemonic fragment.

Canonical subject rule (applies to tiers 1–3): When a confirmed DBpedia IRI (tier 2) or Wikidata IRI (tier 3) exists, that IRI IS the entity's subject — use it directly as the primary subject, never create a document-local alias and add owl:sameAs dbr:X. The entity IS dbr:X; the local alias is redundant and bloats the graph. Use owl:sameAs only for genuine cross-vocabulary alignment: dbr:SPARQL owl:sameAs wd:Q54871 is correct (DBpedia ↔ Wikidata); :sparqlConcept owl:sameAs dbr:SPARQL is the anti-pattern to avoid. Document-local IRIs (tier 4) are correct only when no confirmed authority IRI exists. Do not hardcode a fixed list of cross-referenceable terms — evaluate each term against DBpedia/Wikidata at generation time. Do not fabricate external IRIs.

Collection and Service Detection

When generating RDF from a documentation collection, manual, docs portal, sitemap-backed site, MkDocs/Docusaurus/VitePress collection, GitBook, or source mesh:

1. Inspect available sitemap, search index, navigation, table of contents, and strongly linked child pages before finalizing the graph.
2. Treat child pages about APIs, SPARQL, endpoints, query examples, services, reporting workflows, data models, server/runtime platforms, authentication, and integration instructions as high-signal sources that must be summarized into the RDF unless the user explicitly narrows scope.
3. If source content mentions a SPARQL endpoint, REST API, query service, data service, server platform, or runtime infrastructure, model it explicitly using appropriate entities such as schema:WebAPI, schema:DataCatalog, schema:DataFeed, schema:SoftwareApplication, schema:Service, or schema:SoftwareSourceCode.
4. For query-example pages, represent major query families or named queries as distinct resources when they are central to the document. Link each query to its target endpoint/service and to the concepts it reports on.
5. Apply the SoftwareApplication denotation rule to server/software platforms such as Virtuoso, PostgreSQL, Databricks, Snowflake, GitLab Pages, MkDocs, or application connectors. Prefer confident DBpedia/Wikidata IRIs for known platforms; otherwise use the official homepage URL with #this.
6. For SPARQL examples, preserve executable query text in RDF using schema:SoftwareSourceCode, schema:programmingLanguage "SPARQL", schema:text, schema:codeSampleType, and schema:target pointing to the endpoint/service. Model live execution links as schema:SearchAction or equivalent schema:potentialAction resources with correctly URL-encoded query parameters for the endpoint. If placeholders remain in the source query, keep them visibly marked and do not imply the query is executable without user edits.

Template Selection

When uncertain, default to the Generic template and ask the user which RDF-Turtle variant fits better.

RDF Format Elicitation

Before generation, elicit the RDF serialization format unless already specified by the user:

"Output format: (1) RDF-Turtle only, (2) JSON-LD only, or (3) Both?"

Do NOT default to dual-format generation. Only produce both when explicitly requested or when the user asks for HTML/MD companions that require a format toggle in the footer. Producing an unneeded format wastes tokens on rdflib conversion and file I/O.

Generation Modality

Before generation, elicit the modality unless the user has already specified one:

"Generate via: (1) LLM-Direct — I write all artifacts end-to-end, (2) Script-Assisted — I extract entities as JSON, Python builds RDF deterministically, then I generate HTML+MD from validated RDF, or (3) Agent's Choice — I pick the most token-efficient mode based on content complexity?"

Agent's Choice heuristic:

• Entities > 20, comments > 3, or SPARQL queries present → Script-Assisted
• Entities ≤ 20, no comments, no SPARQL → LLM-Direct

Plan Presentation Rule

Before executing any generation, present a tabulated plan with every item checked against the applicable validation gates. Use this format:

If any gate has no corresponding check in the skills, mark it MISSING GATE and pause for the user to resolve before proceeding. Do not execute until the user approves the plan.

Execution Routing

Default execution order for fetching content and invoking web services:

1. Direct native access (file read, WebFetch, or curl) to the source URL
2. PinchTab browser automation — for JS-heavy pages, login-protected content, or sites requiring browser interaction (e.g., LinkedIn posts, X/Twitter feeds). Use when curl returns 401, 403, or empty content but the page loads in a browser.

   Installation check: If pinchtab is not found in PATH, ask the user for permission to install it before proceeding. Install options: brew install pinchtab (macOS) or cargo install pinchtab (via Rust)

   • Start PinchTab server: pinchtab server (or pinchtab daemon install for persistent service)
   • Start instance: pinchtab instance start or curl -X POST http://localhost:9867/instances/start
   • Navigate: curl -X POST http://localhost:9867/navigate -d '{"url":"..."}'
   • Extract text: curl http://localhost:9867/text or curl http://localhost:9867/snapshot
   • Cleanup: pinchtab instance stop when done
3. URIBurner REST functions for content retrieval and RDF services
4. Terminal-owned OAuth flow — when the endpoint requires OAuth 2.0 authentication, execute the OAuth flow from the terminal (authorization code, client credentials, or device flow), capture the Bearer token, and inject it into subsequent REST/OpenAPI calls via Authorization: Bearer {token} headers
5. MCP via https://linkeddata.uriburner.com/chat/mcp/messages or https://linkeddata.uriburner.com/chat/mcp/sse
6. Authenticated LLM-mediated execution via https://linkeddata.uriburner.com/chat/functions/chatPromptComplete
7. OPAL Agent routing using recognizable OPAL function names

If the user explicitly names a protocol, follow that preference instead.

Important: This routing applies only to the content FETCH phase (steps 1-7 above). Once source content is retrieved (via curl, PinchTab, WebFetch, or file read), the transformation to RDF/JSON-LD proceeds directly using the template prompts in section 2 — no further routing through steps 2-7 is needed unless you specifically need to query a live endpoint for additional data during transformation.

Workflow

1. Identify the source URL — extract the file: or http[s]: URL from the user's request.
2. Fetch content — retrieve page or document text using available tools (browser automation, WebFetch, file read, etc.).

   PinchTab fallback: Use when curl/WebFetch returns 401, 403, empty content, or clearly JS-rendered output. Common scenarios:

   • LinkedIn profiles, posts, company pages
   • X/Twitter profiles, threads, replies
   • Sites with login walls or infinite scroll
   • Pages requiring JavaScript execution to render content Important: If PinchTab is not installed, ask the user explicitly for permission to install it before proceeding.

3. Select template — use the table above; check for explicit user preference.
4. Determine output format — RDF-Turtle is the default; respect explicit requests.
5. Populate and apply the template — substitute all {placeholders} and generate the output.
6. Validate — confirm syntactic correctness (balanced braces/brackets for JSON-LD; valid prefixes and triple syntax for Turtle).
7. Compliance check — run the automated compliance audit (see scripts/validate-kg-compliance.sh or the inline checklist below) against the generated output. Fix all FAIL items before proceeding.
8. Deliver — output in a single code block. If saving to file, use {slug}-1.ttl or {slug}-1.jsonld, incrementing as needed, saved to {output-directory}.
9. Final validation — validate the RDF syntax for the requested format (Turtle, JSON-LD, RDF/XML, etc.) before responding.

Template 1 — Generic (JSON-LD)

Use for general web pages, articles, blog posts, and documentation.

⛔ PRE-BUILD CHECK: Before producing JSON-LD, re-read the "Post-Generation Checklist" below and the "Compliance Self-Audit" in the prompt. Confirm: @base = {page_url}, schema: = http://schema.org/ (HTTP), "@language": "en" in @context, FAQ → schema:FAQPage + schema:mainEntity, glossary → schema:DefinedTermSet + schema:hasDefinedTerm, person IRI priority (LinkedIn → X → Substack → hash fallback), organization IRI priority (DBpedia 1st → Wikidata 2nd → LinkedIn #this 3rd → X #this 4th → Homepage #this 5th — primary subject must be canonical, not document-local; owl:sameAs for all remaining platform identities), concept/DefinedTerm IRI priority (standards-body/platform → DBpedia → Wikidata → document-local; document-local is default, owl:sameAs for external authorities), no file: IRIs, owl:sameAs not schema:sameAs, no blank nodes for schema:Answer. Build to pass every item — do not retro-fit.

Placeholders

Prompt

Using a code block, generate a comprehensive representation of this information in JSON-LD using valid terms from <http://schema.org>. You MUST use {page_url} for @base, which is then used in deriving relative hash-based hyperlinks that denote subjects and objects. This rule doesn't apply to entities that are already denoted by hyperlinks (e.g., DBpedia, Wikidata, Wikipedia, etc), and expand @context accordingly. Note the following guidelines:
1. Use @vocab appropriately.
2. If applicable, include at least 10 Questions and associated Answers.
3. Utilize annotation properties to enhance the representations of Questions, Answers, Defined Term Set, HowTos, and HowToSteps, if they are included in the response, and associate them with article sections (if they exist) or article using schema:hasPart.
4. Where relevant, add attributes for about, abstract, article body, and article section limited to a maximum of 30 words.
5. Denote values of about using hash-based IRIs derived from entity home page or Wikipedia page URL.
6. Where possible, if confident, add a DBpedia IRI to the list of about attribute values and then connect the list using owl:sameAs; note, never use schema:sameAs in this regard. In addition, never assign literal values to this attribute i.e., they MUST be IRIs by properly using @id.
7. Where relevant, add article sections and fleshed out body to ensure richness of literal objects.
8. Where possible, align images with relevant article and howto step sections.
9. Add a label to each how-to step.
10. Add descriptions of any other relevant entity types.
11. If not generating JSON-LD, triple-quote literal values containing more than 20 words.
12. Whenever you encounter inline double quotes within the value of an annotation attribute, change the inline double quotes to single quotes.
13. Whenever you encounter images, handle using schema:image on the relevant entity. For each distinct image found in the source content, create a schema:ImageObject describing it with properties such as name, description, contentUrl, thumbnailUrl, uploadDate, and caption where available — don't guess and insert non-existent information. Associate each ImageObject with its relevant article section or HowTo step via schema:hasPart or schema:about.
14. Whenever you encounter video, handle using the VideoObject type, specifying properties such as name, description, thumbnailUrl, uploadDate, contentUrl, and embedUrl — don't guess and insert non-existent information.
15. Whenever you encounter audio, handle using the AudioObject type, specifying properties such as name, description, thumbnailUrl, uploadDate, contentUrl, and embedUrl — don't guess and insert non-existent information.
16. For every person entity (authors, commentators, or explicitly mentioned individuals): use the highest-priority platform profile URL found in the source as the primary person IRI with `#this` appended, in this order: (a) LinkedIn profile URL → `{linkedin-url}#this`; (b) X/Twitter profile URL → `{x-url}#this`; (c) Substack author profile URL → `{substack-url}#this`; (d) Reddit user profile URL → `{reddit-url}#this`; (e) other social media or blog platform author/profile URL → `{platform-url}#this`; (f) otherwise derive a hash-based IRI from {page_url}. Add `schema:url` pointing to the bare profile URL and `schema:identifier` with the canonical profile URL. In every case, ALL discovered platform identities MUST be linked via owl:sameAs — e.g., owl:sameAs <https://www.linkedin.com/in/name/#this>, <https://x.com/handle/#this>, <https://substack.com/@handle/#this> — ensuring the person is resolvable from any direction. For JSON-LD, use @id for all owl:sameAs values.
    16a. **NEVER fabricate person names.** Use names exactly as they appear in the source document — character for character. Never guess, infer, or complete a partial name. If the source says only "Mr. Lutkus", the person's name is "Lutkus" (or whatever exact form appears). Do not add a first name unless the source explicitly provides it. If only a handle or username is given (e.g., "@jdoe"), use that handle as the name. Fabricating names produces wrong IRIs, wrong search results, and wrong attribution.
    16b. **Actively search for LinkedIn profiles.** When no platform profile URL is found in the source for a named person, attempt to find their LinkedIn profile via web search before falling back to a hash-based IRI. Search for the person's exact name as it appears in the source plus their organizational context (company, role, publication). Use the highest-confidence LinkedIn URL found. If no LinkedIn profile can be confidently matched, proceed to search for X/Twitter, then Substack, then other platforms. Only use the hash-based fallback after search attempts are exhausted.
     16c. **Actively resolve organization identities.** For every named organization, use the highest-priority identity in this order as the PRIMARY SUBJECT IRI: (a) DBpedia resource IRI → `http://dbpedia.org/resource/{name}`; (b) Wikidata entity IRI → `http://www.wikidata.org/entity/Q{...}`; (c) LinkedIn company page URL → `{linkedin-company-url}#this`; (d) X/Twitter org account URL → `{x-org-url}#this`; (e) official homepage URL → `{homepage-url}#this`; (f) otherwise derive a hash-based IRI from {page_url}. Never use a document-local IRI as the primary subject when a canonical platform IRI is available. Add `owl:sameAs` for all remaining discovered platform identities — e.g., owl:sameAs <http://dbpedia.org/resource/OpenAI>, <https://www.linkedin.com/company/openai/> — ensuring the organization is resolvable from any direction. For JSON-LD, use @id for all owl:sameAs values.
     16d. **NEVER fabricate organization names.** Use names exactly as they appear in the source document. If the source says "Google", use "Google" — not "Google LLC" or "Alphabet Inc." unless the source explicitly states the full legal name.
     16e. **Reconcile LinkedIn www and non-www forms.** When a person's primary LinkedIn IRI uses `linkedin.com/in/` (no www), add `owl:sameAs` to the `www.linkedin.com/in/` form, and vice versa. Both `https://linkedin.com/in/username#this` and `https://www.linkedin.com/in/username#this` denote the same profile and MUST be linked via `owl:sameAs` to ensure the person is resolvable from both forms.
17. Where relevant, include additional entity types when discovered e.g., Product, Offer, and Service etc.
18. Language-tag all annotation attribute values. In Turtle, every string literal MUST carry an `@en` language tag (e.g., `"text"@en`). In JSON-LD, the `@context` MUST include `"@language": "en"` so all string values inherit the tag implicitly. Both serializations MUST be semantically equivalent — untagged JSON-LD strings are a contract violation.
19. Describe article authors and publishers in detail.
20. Use a relatedLink attribute to comprehensively handle all inline URLs. Unless told otherwise, it should be a maximum of 20 relevant links.
21. You MUST ensure smart quotes are replaced with single quotes.
22. You MUST check and fix any JSON-LD usage errors based on its syntax rules e.g., missing @id designation for IRI values of attributes that only accept IRI values (e.g., schema:sameAs, owl:sameAs, etc.).
23. You MUST use http://schema.org/ (HTTP, not HTTPS) as the schema: namespace URI. Never use https://schema.org/.
24. You MUST wrap FAQ questions in a schema:FAQPage with schema:mainEntity listing all question IRIs. The FAQPage MUST be linked from the main article via schema:hasPart.
25. You MUST wrap glossary terms in a schema:DefinedTermSet with schema:hasDefinedTerm listing all term IRIs. The DefinedTermSet MUST be linked from the main article via schema:hasPart.
26. ALL DBpedia, Wikidata, and Wikipedia entity references MUST use fully expanded IRIs (e.g., http://dbpedia.org/resource/Tim_Berners-Lee) — never CURIEs or prefixed names.
27. For every country entity modeled as `schema:Country`, use a DBpedia country IRI as the primary subject IRI when confidently known; otherwise use a Wikidata country IRI when confidently known; only use a `{page_url}` hash IRI when neither can be confirmed. Add `owl:sameAs` between the selected country IRI and any confirmed DBpedia/Wikidata equivalent.
28. You MUST NOT use file: scheme IRIs anywhere. The @base or @prefix : MUST use the canonical https: URL of the source document with a # suffix.
29. If the response includes a lightweight ontology (custom classes, properties, or an owl:Ontology declaration), you MUST: (a) name and describe the ontology using schema:name and schema:description alongside rdfs:label and rdfs:comment; (b) add schema:identifier with the canonical source URL; (c) associate every class and property with the ontology using rdfs:isDefinedBy : . The owl:Ontology entity MUST be its own distinct resource — never a second rdf:type added to the document's `<>` schema:CreativeWork entity — and its schema:name/schema:description MUST be textually differentiated from the document entity's, never identical strings on both (e.g. document: "{Ontology Name} Document" / "Document about ..."; ontology: "{Ontology Name}" / the actual substantive TBox description). See agent-rdf-memory/howto/ontology-document-name-differentiation.ttl.
30. You MUST NOT use blank nodes for schema:Answer instances. Every schema:Answer MUST be a named entity with its own hash-based IRI (e.g., :a1, :a2) connected via schema:acceptedAnswer :aN — never schema:acceptedAnswer [ a schema:Answer ; ... ].
31. When you assert a directional relationship (e.g., schema:isPartOf), you MUST also assert its inverse on the target entity (e.g., schema:hasPart) — RDF does not infer inverses automatically, so both directions are needed for completeness.
32. Every logical entity group beyond FAQ/glossary/HowTo (e.g., use cases, technologies, architectural layers, key concepts) MUST be wrapped in a schema:CreativeWork and linked to the main article via schema:hasPart. No entity should be orphaned — every entity must be reachable from the main article through some path.
33. The main article MUST include prov:wasGeneratedBy linking to a schema:SoftwareApplication entity representing the skill that produced it. Declare @prefix prov: <http://www.w3.org/ns/prov#> . The skill entity IRI MUST use the canonical GitHub repository URL with #this appended: <https://github.com/OpenLinkSoftware/ai-agent-skills/tree/main/kg-generator#this> for kg-generator, and <https://github.com/OpenLinkSoftware/ai-agent-skills/tree/main/rdf-infographic-skill#this> for rdf-infographic-skill. The skill entity MUST have schema:name (e.g., "kg-generator skill"), schema:url pointing to its GitHub source without #this (e.g., <https://github.com/OpenLinkSoftware/ai-agent-skills/tree/main/kg-generator>), and schema:description. If multiple skills were used, use multiple prov:wasGeneratedBy triples. Do not mint document-local hash IRIs such as {source-url}#kgGeneratorSkill or {source-url}#rdfInfographicSkill for these skill entities.
33. For documentation/manual collections, inspect sitemap/search index/navigation for high-signal child pages. Pages covering APIs, SPARQL endpoints, query examples, services, data models, server/runtime platforms, and reporting workflows MUST be incorporated when they materially change the graph.
34. When a SPARQL endpoint, API endpoint, query service, or server platform is present, model it explicitly. SPARQL endpoints SHOULD use `schema:WebAPI` or another appropriate service class with `schema:url`; query families MAY use `schema:SoftwareSourceCode` and SHOULD link to the endpoint with `schema:target` or an equivalent property.
35. When SPARQL query examples or recipes are present, the query body MUST be preserved as `schema:text` on a `schema:SoftwareSourceCode` resource with `schema:programmingLanguage "SPARQL"`, linked to its endpoint via `schema:target`, and linked to a URL-encoded live query action via `schema:potentialAction` where the endpoint supports a GET query URL.

"""
{selected_text}
"""

Following your initial response, perform the following tasks:
1. Check and fix any syntax errors in the response.
2. Provide a list of additional questions, defined terms, or howtos for my approval.
3. Provide a list of additional entity types that could be described for my approval.
4. If the suggested additional entity types are approved, you MUST then return a revised final description comprising the original and added entity descriptions.

CRITICAL — Before presenting the final output, you MUST perform a compliance self-audit. Verify each of these items and report the result (PASS or FAIL with the specific violation):
1. schema: namespace uses http://schema.org/ (not https://schema.org/)
2. FAQ questions are wrapped in a schema:FAQPage linked via schema:mainEntity
3. Glossary terms are wrapped in a schema:DefinedTermSet linked via schema:hasDefinedTerm
4. The main article has schema:hasPart linking to FAQPage, DefinedTermSet, HowTo, the ontology (:), and all entity group sections (use cases, technologies, etc.)
5. All DBpedia/Wikidata/Wikipedia IRIs are fully expanded (not CURIEs)
6. No file: scheme IRIs exist anywhere in the output
7. owl:sameAs is used for DBpedia cross-references (never schema:sameAs)
7a. All organization entities use the highest-priority canonical platform IRI as their primary subject (DBpedia 1st, Wikidata 2nd, LinkedIn `#this` 3rd, X `#this` 4th, Homepage `#this` 5th) — never a document-local IRI with `owl:sameAs` pointing to the canonical one. `owl:sameAs` links all remaining discovered platform identities.
7b. Organization names match source document exactly — no fabricated legal names or suffixes
8. @base or @prefix : is the canonical https: source URL with # suffix
9. If an ontology is present: (a) it has schema:name and schema:description, (b) schema:identifier with canonical URL, (c) all classes and properties have rdfs:isDefinedBy :
10. No blank nodes used for schema:Answer — every answer is a named entity (:a1, :a2, ...) with schema:acceptedAnswer :aN
11. Inverse relationships are explicit: for every schema:isPartOf there is a corresponding schema:hasPart, etc.
12. prov:wasGeneratedBy links the main article to a skill entity using the canonical IRI with #this (e.g., <https://github.com/OpenLinkSoftware/ai-agent-skills/tree/main/kg-generator#this>), with schema:name, schema:url (GitHub without #this), and schema:description
13. Every entity's rdf:type matches its semantic role: HowToStep entities are a schema:HowToStep, FAQ questions are a schema:Question, FAQ answers are a schema:Answer, glossary terms are a schema:DefinedTerm (or appropriate type), sections are a schema:CreativeWork. No entity has a generic or mismatched type when a specific type is available.
14. owl:sameAs never has the same IRI in both subject and object positions — including www/non-www variants of the same platform (e.g., `https://www.linkedin.com/in/kidehen#this` owl:sameAs `https://linkedin.com/in/kidehen#this` is forbidden). Self-referential sameAs is a data integrity error, not a cross-reference.
15. Every entity type category uses the correct canonical IRI priority ladder as its primary subject: Organization (DBpedia → Wikidata → vendor site `#this` → LinkedIn `#this` → X `#this` → document-local), SoftwareApplication (vendor `#this` → DBpedia → Wikidata → document-local), Concept/DefinedTerm (standards-body/platform → DBpedia → Wikidata → document-local). `owl:sameAs` links all remaining discovered identities. No entity uses a document-local IRI as primary subject when a higher-priority canonical IRI exists.
Report: "COMPLIANCE SELF-AUDIT: X/16 passed. [list any FAIL items with the specific fix applied]. Final output follows."

GATE: 0 FAIL required before delivery. Every numbered rule in this prompt has a corresponding check in this audit. No rule without verification — unchecked rules are aspirational, not enforceable.```

### Post-Generation Checklist

- [ ] `@base` set to `{page_url}`
- [ ] `schema:` namespace uses `http://schema.org/` (HTTP, not HTTPS)
- [ ] All subject/object IRIs are hash-based relative IRIs (except known authority entities)
- [ ] FAQ questions wrapped in `schema:FAQPage` with `schema:mainEntity`
- [ ] Each FAQ question has `schema:isPartOf :faqSection` linking back to the FAQ section
- [ ] Glossary terms wrapped in `schema:DefinedTermSet` with `schema:hasDefinedTerm`
- [ ] Main article has `schema:hasPart` linking FAQPage, DefinedTermSet, HowTo, the ontology (:), and all entity group sections
- [ ] At least 10 `schema:Question` + `schema:Answer` pairs present
- [ ] Every entity's rdf:type matches its semantic role: HowToStep → schema:HowToStep, Question → schema:Question, Answer → schema:Answer, DefinedTerm → schema:DefinedTerm, ArticleSection → schema:CreativeWork. No entity typed as schema:Thing when a specific type is appropriate.
- [ ] `owl:sameAs` used (not `schema:sameAs`) for DBpedia cross-references
- [ ] All DBpedia/Wikidata/Wikipedia IRIs fully expanded (not CURIEs)
- [ ] Every `schema:Country` subject IRI follows the country denotation priority rule: DBpedia IRI if confirmed, else Wikidata IRI if confirmed, else source-grounded document IRI; add `owl:sameAs` for confirmed DBpedia/Wikidata equivalents.
- [ ] No `file:` scheme IRIs anywhere
- [ ] All IRI-valued attributes use `@id` — no plain string literals for IRI-only properties
- [ ] Inline double quotes within literals converted to single quotes
- [ ] Smart/curly quotes replaced with straight single quotes
- [ ] `relatedLink` includes up to 20 relevant inline URLs
- [ ] `@context` includes `"@language": "en"` so all string literals inherit the English language tag
- [ ] JSON-LD is syntactically valid
- [ ] No guessed media URLs (thumbnailUrl, contentUrl, embedUrl)
- [ ] Images from source content described using `schema:image` with `schema:ImageObject` where distinct
- [ ] Person names used exactly as they appear in source — no fabrication, no guessing first names from surnames
- [ ] LinkedIn profile actively searched for each named person without a platform URL in source before hash-based fallback
- [ ] Person IRIs derived from LinkedIn/X/Substack/Reddit/other-platform profile URLs where found; all platform identities linked via `owl:sameAs`
- [ ] Organization IRIs follow priority: DBpedia → Wikidata → LinkedIn → X → homepage → hash fallback. The highest-priority IRI is the primary subject — not a document-local IRI with `owl:sameAs`. `owl:sameAs` for all remaining discovered platform identities.
- [ ] Organization names match source exactly — no fabricated legal names
- [ ] Concept/DefinedTerm IRIs follow priority: standards-body/platform → DBpedia → Wikidata → document-local hash. When a standards-body/platform IRI exists, it is the primary subject; otherwise document-local is the primary subject with `owl:sameAs` for confirmed DBpedia/Wikidata equivalents.
- [ ] If ontology present: `schema:name` + `schema:description`, `schema:identifier`, all classes/properties have `rdfs:isDefinedBy :`
- [ ] `prov:wasGeneratedBy` links article to a skill entity using the canonical IRI with `#this` (e.g., `<https://github.com/OpenLinkSoftware/ai-agent-skills/tree/main/kg-generator#this>`), with `schema:name`, `schema:url` (GitHub without `#this`), `schema:description`
- [ ] SPARQL query examples are preserved as `schema:SoftwareSourceCode` with query text, target endpoint/service, and correctly encoded live query actions when applicable
- [ ] `owl:sameAs` never has the same IRI in both subject and object (including www/non-www variants of the same platform)
- [ ] Entity canonical IRI priority ladders enforced: Organization (DBpedia 1st → Wikidata 2nd → vendor site `#this` 3rd → LinkedIn `#this` 4th → X `#this` 5th → document-local), SoftwareApplication (vendor `#this` 1st → DBpedia 2nd → Wikidata 3rd → document-local), Concept/DefinedTerm (standards-body/platform 1st → DBpedia 2nd → Wikidata 3rd → document-local)

## Template 2 — Business & Market Analysis (RDF-Turtle)

Use for business strategy posts, X/social threads, market analyses, and industry deep-dives.

⛔ **PRE-BUILD CHECK**: Before producing RDF-Turtle, re-read the "Post-Generation Checklist" below and the "Compliance Self-Audit" in the prompt. Confirm: `@prefix :` = `{post-url}#`, `schema:` = `http://schema.org/` (HTTP), ontology with `schema:name` + `schema:description` + `schema:identifier`, all custom classes/properties have `rdfs:isDefinedBy :`, at least 12 FAQ + at least 10 glossary + all procedural steps present as HowTo — covering every distinct question-worthy claim and defined term in the source, never capped at a fixed number once reached, organization IRI priority (DBpedia 1st → Wikidata 2nd → LinkedIn `#this` 3rd → X `#this` 4th → Homepage `#this` 5th — primary subject must be canonical, not document-local; `owl:sameAs` for all remaining platform identities), concept/DefinedTerm IRI priority (standards-body/platform → DBpedia → Wikidata → document-local; document-local is default, `owl:sameAs` for external authorities), NAICS codes with `?input=&year=2022&details=` pattern, no blank nodes for `schema:Answer`, `prov:wasGeneratedBy` on `:analysis`, no `file:` IRIs, all string literals carry `@en` language tags. Build to pass every item — do not retro-fit.

### Placeholders

| Placeholder | Value |
|---|---|
| `{url}` | URL of the original post or content being analysed |
| `{post-url}` | Used as the Turtle `@prefix :` base (append `#`) |
| `{selected_text}` | Full extracted text content of the source (post + thread/replies, if any) |
| `{current date}` | ISO 8601 date e.g. `2026-03-13` |

> `{post-url}` and `{url}` are often the same value.

**Example — X post (Robert Scoble vishing incident):**

{url} = "https://x.com/Scobleizer/status/2053367142045847649" {post-url} = "https://x.com/Scobleizer/status/2053367142045847649"

RDF: @prefix : https://x.com/Scobleizer/status/2053367142045847649# . HTML footer: RDF Resolver → https://x.com/Scobleizer/status/2053367142045847649 MD header: RDF Resolver → https://x.com/Scobleizer/status/2053367142045847649 Glossary terms: Vishing

**Output file footer requirements:**
- HTML: Include `RDF: <a href="{source-url}">Resolver</a>` link in footer, plus link to Turtle file
- MD: Include `**RDF Resolver:** [URL](URL)` in header, plus `#term` fragment links in glossary

**Example — worked application of this template:** see "Example — Business Analysis Worked Example" below for a full illustration of how these generic instructions apply to a real source (a Julien Bek X-thread on AI "autopilots" disrupting services markets). That block is reference material only — do not copy its entity names, class names, or figures into an unrelated source's output.

### Example — Business Analysis Worked Example

This is a **worked illustration**, not part of the prompt the model executes. It shows how the generic instructions above resolve when applied to one specific source — a Julien Bek X-thread discussing AI-driven "autopilots" disrupting services markets by selling outcomes rather than tools, starting with outsourced intelligence-heavy tasks such as NDA drafting, insurance brokerage (~$140–200B labor TAM), and accounting (~$50–80B labor TAM), with structural shortages like the loss of ~340k U.S. accountants, data compounding enabling eventual judgment handling, debates around copilots vs. full autopilots, the innovator's dilemma, and founder collaboration opportunities.

Applying step 3 (lightweight ontology) to this source produced:
- Base class `:Industry` (the source's central recurring category — services verticals)
- Subclasses `:InsuranceBrokerageIndustry` and `:AccountingIndustry` (the two verticals the source compares)
- Custom properties `:hasLaborTAM` (range `xsd:string`) and `:hasAutomationReadiness` (range `xsd:string`) — the two recurring structured attributes the source assigns to each vertical
- Instances `:insuranceBrokerageVertical` and `:accountingVertical` holding the concrete TAM, readiness, NAICS, and offer data

Applying step 5 (core entities) to this source produced:
- The main analysis (`:analysis`), author (`:grok`), original post reference (`:originalXPost`), and Julien Bek as the person entity
- `:aiAutopilotDisruption` (Product), `:marketDisruptionAction`, `:servicesMarketDisruption` — the central phenomenon/thesis entities
- `:ndaExample` as a concrete illustrative task
- Organizations `:withCoverage` and `:rillet` and their respective autopilot products
- `:shortageEvent` for the U.S. accountant shortage statistic
- `:unitedStates` with its ISO code
- `:threadReplies`, `:cursorExample`, `:scalingChallenges` for discussion/example entities raised in the thread
- `:innovatorsDilemma` as a `CreativeWork` with `schema:isbn "9780060521998"`

Applying step 7 (preserve original details) to this source meant retaining, verbatim: the `$140-200B` and `$50-80B` TAM ranges, "High" automation readiness for both verticals, the 340,000 accountant shortage figure, the data-compounding explanation, the "Outcome-as-a-Service" model name, the innovator's-dilemma framing, the copilot-to-autopilot transition debate, and the founder-collaboration call to action.

### Prompt

You are an expert in semantic web modeling, RDF/Turtle serialization, and schema.org + lightweight ontology design. Given the post/content at {url} (and its thread or surrounding discussion, if any): """ {selected_text} """ produce a comprehensive RDF/Turtle document that represents the full business & strategy analysis. Follow ALL of these final design requirements exactly:

1. Base URI: Use relative hash URIs grounded in {post-url} as the namespace prefix :
2. Use schema.org as the primary vocabulary — use http://schema.org/ (HTTP, not HTTPS) as the schema: namespace URI — supplemented by:
   • skos: for glossary/concept definitions
   • org: for organizations
   • dbo: for selected DBpedia cross-references (via rdfs:seeAlso)
   • rdfs: for class/property definitions
3. Create a small custom lightweight ontology in the same namespace, derived from the actual structure of the source:
   • Identify the source's central recurring category (e.g., an industry, a technology domain, a product line, a comparison dimension) and define it as a base rdfs:Class in the local namespace.
   • Define one subclass rdfs:Class resource for each distinct instance of that category the source discusses (e.g., if the source compares several industry verticals, define one subclass per vertical; if it compares several technologies, define one subclass per technology).
   • Define custom properties on the base class for the recurring structured attributes the source assigns to each category instance (e.g., a size/market metric, a readiness/maturity rating, a status) — choose property names and xsd: ranges that fit what the source actually measures.
   • Create explicit instances of these subclasses to hold the concrete data the source provides (figures, ratings, identifiers, cross-references). Do NOT put instance data directly on the class definitions.
   • If the source has no natural category/vertical structure, a minimal ontology (base class + one or two properties, no subclasses) is acceptable — do not force an artificial hierarchy.
4. Use low-redundancy schema.org identifier modeling (Option 3 style):
   • Use dedicated properties when they exist: schema:naics (on industry instances), schema:isbn (on books), schema:identifier with a plain literal for unambiguous codes (e.g. an ISO 3166-1 alpha-2 country code)
   • When the source discusses one or more industry verticals, pair schema:naics (plain code string) with schema:identifier using the Census Bureau canonical lookup URL: https://www.census.gov/naics/?input={code}&year=2022&details={code}
   • Avoid unnecessary schema:PropertyValue wrappers unless genuinely required for disambiguation or extra metadata
5. Core entities that must be included:
   • The main analysis CreativeWork (:analysis)
   • The author/speaker entity and the original post/document reference, using the person/organization IRI priority rules in item 13 below
   • Identify the core entities, concepts, actions, and named things the source actually discusses (e.g., the central phenomenon or thesis being analyzed, any products/services named, any organizations named, any statistical/structural events cited, any countries or jurisdictions referenced, any books/works cited) and model each as an instance of the most specific applicable schema.org (or local ontology) class. Do not invent entities the source does not mention, and do not omit an entity the source treats as significant.
6. Mandatory structured sections (all must be present and complete — counts are a floor covering every distinct question-worthy claim/term/step in the source, not a fixed target):
   • schema:FAQPage (:faqSection) with at least 12 schema:Question items (:q1, :q2, :q3, … numbered sequentially; extend the range as needed to cover every distinct question-worthy claim in the source)
   • skos:ConceptScheme + schema:DefinedTermSet (:glossarySection) with at least 10 terms (:term1, :term2, … or mnemonic fragments; extend as needed to cover every distinct term the source introduces or defines)
   • schema:HowTo (:howtoSection) with schema:HowToStep items covering every procedural step in the source (:step1, :step2, … numbered sequentially)
7. Include all original details:
   • Preserve every quantitative detail exactly as stated in the source — statistics, monetary figures/ranges, dates, percentages, counts — do not paraphrase, round, or approximate them.
   • Preserve every named claim, model, or framework the source references (e.g., a named business model, a named theory, a named transition or debate it describes) as a distinct entity or literal, not folded into generic prose.
   • Preserve any concrete example, case, or anecdote the source uses to illustrate its argument.
   • Preserve any call to action, collaboration opportunity, or forward-looking statement the source makes.
8. Keep descriptions concise yet precise; avoid unnecessary verbosity in literals.
9. Output only the complete, valid Turtle document inside a single code block. Do not include explanations, comments outside Turtle, or any other text before/after the code block.
10. The main analysis CreativeWork (:analysis) MUST have schema:hasPart linking to :faqSection, :glossarySection, :howtoSection, and ALL other entity group sections (e.g., industry verticals, use cases, technologies).
11. All DBpedia references MUST use fully expanded IRIs (e.g., http://dbpedia.org/resource/...) — never CURIEs or prefixed names.
12. All Wikidata references MUST use fully expanded IRIs (e.g., http://www.wikidata.org/entity/...) — never CURIEs or prefixed names.
13. For every person entity: use the highest-priority platform profile URL found in the source as the primary person IRI with #this appended, in this order: (a) LinkedIn profile URL → {linkedin-url}#this; (b) X/Twitter profile URL → {x-url}#this; (c) Substack author profile URL → {substack-url}#this; (d) Reddit user profile URL → {reddit-url}#this; (e) other social media or blog platform author/profile URL → {platform-url}#this; (f) otherwise derive a hash-based IRI from {post-url}. Add schema:url pointing to the bare profile URL and schema:identifier with the canonical profile URL. In every case, ALL discovered platform identities MUST be linked via owl:sameAs — e.g., owl:sameAs https://www.linkedin.com/in/name/#this, https://x.com/handle/#this, https://substack.com/@handle/#this. 13a. NEVER fabricate person names. Use names exactly as they appear in the source — character for character. Never guess, infer, or complete a partial name. If the source says "Mr. Lutkus", the person's name is "Lutkus" — do not add a first name. If only a handle is given, use that handle. 13b. Actively search for LinkedIn profiles. When no platform profile URL is in the source for a named person, search for their LinkedIn via web search using their exact name and organizational context before falling back to a hash-based IRI. Only use the hash fallback after search attempts are exhausted. 13c. Actively resolve organization identities. For every named organization, use the highest-priority identity in this order as the PRIMARY SUBJECT IRI: (a) DBpedia resource IRI → http://dbpedia.org/resource/{name}; (b) Wikidata entity IRI → http://www.wikidata.org/entity/Q{...}; (c) LinkedIn company page URL → {linkedin-company-url}#this; (d) X/Twitter org account URL → {x-org-url}#this; (e) official homepage URL → {homepage-url}#this; (f) otherwise derive a hash-based IRI from {page_url}. Never use a document-local IRI as the primary subject when a canonical platform IRI is available. Add owl:sameAs for all remaining discovered platform identities — ensuring the organization is resolvable from any direction. For JSON-LD, use @id for all owl:sameAs values. 13d. NEVER fabricate organization names. Use names exactly as they appear in the source document. If the source says "Google", use "Google" — not "Google LLC" or "Alphabet Inc." unless the source explicitly states the full legal name. 13e. Reconcile LinkedIn www and non-www forms. When a person's primary LinkedIn IRI uses linkedin.com/in/ (no www), add owl:sameAs to the www.linkedin.com/in/ form, and vice versa. Both denote the same profile and MUST be linked via owl:sameAs to ensure resolvability from both forms.
14. The lightweight ontology MUST be named and described using schema:name and schema:description alongside rdfs:label/rdfs:comment, with schema:identifier carrying the canonical source URL. Every class and property MUST have rdfs:isDefinedBy : linking it to the ontology.
15. You MUST NOT use blank nodes for schema:Answer instances. Every schema:Answer MUST be a named entity with its own hash-based IRI (e.g., :a1, :a2) connected via schema:acceptedAnswer :aN — never schema:acceptedAnswer [ a schema:Answer ; ... ].
16. For every directional relationship you assert (e.g., schema:isPartOf), you MUST also assert its inverse on the target entity (e.g., schema:hasPart) — RDF does not infer inverses, so both directions are necessary.
17. The main analysis (:analysis) MUST include prov:wasGeneratedBy linking to a schema:SoftwareApplication entity representing the kg-generator skill. Declare @prefix prov: http://www.w3.org/ns/prov# . The skill entity IRI MUST be https://github.com/OpenLinkSoftware/ai-agent-skills/tree/main/kg-generator#this. The skill entity MUST have schema:name "kg-generator skill", schema:url https://github.com/OpenLinkSoftware/ai-agent-skills/tree/main/kg-generator, and schema:description. Do not mint document-local hash IRIs such as {source-url}#kgGeneratorSkill for skill entities. Current date for metadata: {current date}.

CRITICAL — Before outputting the Turtle, you MUST perform a compliance self-audit. Verify each item and report PASS or FAIL (with the violation fixed):

1. schema: namespace is http://schema.org/ (not https://schema.org/)
2. :analysis has schema:hasPart linking :faqSection, :glossarySection, :howtoSection
3. :faqSection is a schema:FAQPage with schema:mainEntity listing at least 12 schema:Question items, covering every distinct question-worthy claim in the source (not capped at 12)
4. :glossarySection is a schema:DefinedTermSet with schema:hasDefinedTerm listing at least 10 terms, covering every distinct term the source introduces or defines (not capped at 10)
5. :howtoSection is a schema:HowTo with schema:step listing every procedural step in the source, numbered sequentially
6. All DBpedia/Wikidata IRIs are fully expanded (not CURIEs) 6a. All organization entities use the highest-priority canonical platform IRI as their primary subject (DBpedia 1st, Wikidata 2nd, LinkedIn #this 3rd, X #this 4th, Homepage #this 5th) — never a document-local IRI with owl:sameAs pointing to the canonical one. owl:sameAs links all remaining discovered platform identities. 6b. Organization names match source document exactly — no fabricated legal names or suffixes
7. NAICS codes use ?input=&year=2022&details= pattern (not ?code=)
8. No file: scheme IRIs exist anywhere
9. Ontology has schema:name + schema:description + schema:identifier; all custom classes/properties have rdfs:isDefinedBy :
10. No blank nodes for schema:Answer — every answer is a named entity (:aN) with schema:acceptedAnswer :aN
11. Inverse relationships explicit: every schema:isPartOf has a corresponding schema:hasPart, etc.
12. prov:wasGeneratedBy links :analysis to a skill entity using the canonical IRI https://github.com/OpenLinkSoftware/ai-agent-skills/tree/main/kg-generator#this, with schema:name, schema:url (GitHub without #this), and schema:description
13. Every entity's rdf:type matches its semantic role: HowToStep entities are a schema:HowToStep, FAQ questions are a schema:Question, FAQ answers are a schema:Answer, glossary terms are a schema:DefinedTerm, sections are a schema:CreativeWork. No entity has a generic or mismatched type when a specific type is available.
14. owl:sameAs never has the same IRI in both subject and object positions — including www/non-www variants of the same platform (e.g., https://www.linkedin.com/in/kidehen#this owl:sameAs https://linkedin.com/in/kidehen#this is forbidden). Self-referential sameAs is a data integrity error, not a cross-reference.
15. Every entity type category uses the correct canonical IRI priority ladder as its primary subject: Organization (DBpedia → Wikidata → vendor site #this → LinkedIn #this → X #this → document-local), SoftwareApplication (vendor #this → DBpedia → Wikidata → document-local), Concept/DefinedTerm (standards-body/platform → DBpedia → Wikidata → document-local). owl:sameAs links all remaining discovered identities. No entity uses a document-local IRI as primary subject when a higher-priority canonical IRI exists. Report: "COMPLIANCE SELF-AUDIT: X/16 passed. [list any FAIL items, already fixed]. Output follows."

GATE: 0 FAIL required before delivery. Every numbered rule in this prompt has a corresponding check in this audit. No rule without verification — unchecked rules are aspirational, not enforceable.```

NAICS Identifier Pattern

Always use both schema:naics and schema:identifier together on industry vertical instances:

:insuranceBrokerageVertical a :InsuranceBrokerageIndustry ;
    schema:naics "524210" ;
    schema:identifier "https://www.census.gov/naics/?input=524210&year=2022&details=524210" .

:accountingVertical a :AccountingIndustry ;
    schema:naics "541211" ;
    schema:identifier "https://www.census.gov/naics/?input=541211&year=2022&details=541211" .

Never use the deprecated ?code={code} URL pattern.

schema:identifier Patterns by Entity Type

Anti-patterns to avoid:

• ❌ schema:sameAs for DBpedia links → use owl:sameAs or rdfs:seeAlso
• ❌ schema:PropertyValue wrappers for simple codes → use plain literals
• ❌ ?code={code} NAICS URL pattern → use ?input={code}&year=2022&details={code}
• ❌ Plain string literals for IRI-only properties → always use @id in JSON-LD

Post-Generation Checklist

• @prefix : set to {post-url}#
• schema: namespace uses http://schema.org/ (HTTP, not HTTPS)
• :analysis schema:hasPart :faqSection, :glossarySection, :howtoSection
• Lightweight ontology present: base class derived from the source's central category, subclasses per distinct instance of that category (or none, if the source has no natural category structure), and custom properties for the source's recurring structured attributes
• Instance data on instances only — not on class definitions
• Both schema:naics and schema:identifier (Census URL) on each industry vertical instance, when the source discusses industry verticals
• At least 12 FAQ questions (numbered sequentially, extended if the source supports more distinct questions) wrapped in schema:FAQPage with schema:mainEntity — count covers every distinct question-worthy claim, not capped once 12 is reached
• Each FAQ question has schema:isPartOf :faqSection linking back to the FAQ section
• At least 10 glossary terms (extended if more distinct terms exist) wrapped in schema:DefinedTermSet with schema:hasDefinedTerm — count covers every distinct term, not capped once 10 is reached
• All procedural steps present as HowTo steps (numbered sequentially) wrapped in schema:HowTo with schema:step
• Each HowTo step has schema:isPartOf :howtoSection linking back to the HowTo section
• All DBpedia/Wikidata IRIs fully expanded (not CURIEs)
• Organization IRIs follow priority: DBpedia → Wikidata → LinkedIn → X → homepage → hash fallback. The highest-priority IRI is the primary subject — not a document-local IRI with owl:sameAs. owl:sameAs for all remaining discovered platform identities.
• Organization names match source exactly — no fabricated legal names
• Concept/DefinedTerm IRIs follow priority: standards-body/platform → DBpedia → Wikidata → document-local hash. When a standards-body/platform IRI exists, it is the primary subject; otherwise document-local is the primary subject with owl:sameAs for confirmed DBpedia/Wikidata equivalents.
• All quantitative details (statistics, monetary figures/ranges, dates, percentages, counts) preserved exactly as stated in the source — not paraphrased, rounded, or approximated
• schema:isbn present on any book/work entity the source cites with an ISBN
• schema:identifier present with the appropriate plain-literal code (e.g. ISO 3166-1 alpha-2) on any country entity the source references
• NAICS URLs use ?input=&year=2022&details= pattern (not ?code=)
• All string literals carry @en language tags (e.g., "text"@en)
• No file: scheme IRIs anywhere
• prov:wasGeneratedBy links :analysis to a skill entity using

Truncated - read the full file at https://github.com/OpenLinkSoftware/ai-agent-skills/blob/cf39051a69b6ed79e059e16e30d23128fa919644/kg-generator/SKILL.md.