Generate comprehensive Knowledge Graphs (RDF-Turtle by default, or JSON-LD and other RDF serializations on request) from content at file: or http(s): scheme URLs. Uses curated prompt templates: a Generic template for general web content (producing JSON-LD), and a Business and Market Analysis template for strategy/analysis content (producing RDF-Turtle with NAICS industry code identifiers, lightweight ontology, FAQ, glossary, and HowTo sections). Trigger when users ask to: generate a knowledge graph, generate RDF or RDF-Turtle, generate JSON-LD, convert a URL to structured semantic data, or extract schema.org data from a page or document.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Generate comprehensive Knowledge Graphs (RDF-Turtle by default, or JSON-LD and other RDF serializations on request) from content at file: or http(s): scheme URLs. Uses curated prompt templates: a Generic template for general web content (producing JSON-LD), and a Business and Market Analysis template for strategy/analysis content (producing RDF-Turtle with NAICS industry code identifiers, lightweight ontology, FAQ, glossary, and HowTo sections). Trigger when users ask to: generate a knowledge graph, generate RDF or RDF-Turtle, generate JSON-LD, convert a URL to structured semantic data, or extract schema.org data from a page or document.
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-skillDocument-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-skillRDF 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.
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:
DBpedia IRI if a confident DBpedia resource exists.
Wikidata IRI if no confident DBpedia resource exists but a confident Wikidata entity exists.
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:
DBpedia country IRI if a confident DBpedia resource exists.
Wikidata country IRI if no confident DBpedia resource exists but a confident Wikidata entity exists.
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:
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.
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.
Wikidata IRI third — if no confident DBpedia resource exists but a confident Wikidata entity exists, use the Wikidata IRI as the primary subject.
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:
Inspect available sitemap, search index, navigation, table of contents, and strongly linked child pages before finalizing the graph.
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.
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.
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.
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.
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
Content type
Template
Default output
General articles, blog posts, documentation
Generic
JSON-LD
Business strategy, market analysis, industry threads
Business & Market Analysis
RDF-Turtle
User requests JSON-LD explicitly
Generic
JSON-LD
User requests RDF-Turtle explicitly
Business & Market Analysis
RDF-Turtle
When uncertain, default to the Generic template and ask the user if they want the Business & Market Analysis variant.
RDF Format Elicitation
Before generation, elicit the RDF serialization format unless already specified by the user:
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?"
Mode
Mechanism
Best for
LLM-Direct
LLM writes TTL/JSON-LD, HTML, MD end-to-end
Small posts, <15 entities, simple structure, quick iterations
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:
#
Requirement
Skill Source
Status
1
@prefix : = canonical source URL with #
kg-gen checklist
✓
2
schema: = http://schema.org/ (HTTP)
kg-gen checklist
✓
...
...
...
...
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:
Direct native access (file read, WebFetch, or curl) to the source URL
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
URIBurner REST functions for content retrieval and RDF services
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
MCP via https://linkeddata.uriburner.com/chat/mcp/messages or https://linkeddata.uriburner.com/chat/mcp/sse
Authenticated LLM-mediated execution via https://linkeddata.uriburner.com/chat/functions/chatPromptComplete
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
Identify the source URL — extract the file: or http[s]: URL from the user's request.
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.
Select template — use the table above; check for explicit user preference.
Determine output format — RDF-Turtle is the default; respect explicit requests.
Populate and apply the template — substitute all {placeholders} and generate the output.
Validate — confirm syntactic correctness (balanced braces/brackets for JSON-LD; valid prefixes and triple syntax for Turtle).
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.
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}.
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
Placeholder
Value
{page_url}
Canonical URL of the source — used as @base
{selected_text}
Full extracted text content of the source
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 : .
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 :`, 12 FAQ + 10 glossary + 7 HowTo present, 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 `#`) |
| `{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):**
**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
### Prompt
You are an expert in semantic web modeling, RDF/Turtle serialization, and schema.org + lightweight ontology design.
Given the post at {url} and its thread (which discusses 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),
produce a comprehensive RDF/Turtle document that represents the full business & strategy analysis.
Follow ALL of these final design requirements exactly:
Base URI: Use relative hash URIs grounded in {post-url} as the namespace prefix :
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
Create a small custom lightweight ontology in the same namespace:
Define :Industry as rdfs:Class (base class for verticals)
Define two subclass rdfs:Class resources: :InsuranceBrokerageIndustry and :AccountingIndustry
Define two custom properties on :Industry:
:hasLaborTAM (range xsd:string)
:hasAutomationReadiness (range xsd:string)
Create explicit instances of these classes (e.g. :insuranceBrokerageVertical a :InsuranceBrokerageIndustry ; ...) to hold concrete data (TAM values, readiness, NAICS, offers, DBpedia links). Do NOT put instance data directly on the class definitions.
Use low-redundancy schema.org identifier modeling (Option 3 style):
Use dedicated properties when they exist: schema:naics (on industry instances), schema:isbn (on the book), schema:identifier with plain literal for unambiguous codes (e.g. "US" for ISO 3166-1 alpha-2)
:innovatorsDilemma (CreativeWork with isbn "9780060521998")
Mandatory structured sections (all must be present and complete):
schema:FAQPage (:faqSection) with exactly 12 schema:Question items (:q1–:q12)
skos:ConceptScheme + schema:DefinedTermSet (:glossarySection) with exactly 10 terms (:termAutopilot through :termVerticalMapping)
schema:HowTo (:howtoSection) with exactly 7 schema:HowToStep items (:step1–:step7)
Include all original details:
Labor TAM ranges exactly as stated ($140-200B insurance, $50-80B accounting)
Automation readiness "High" for both
340,000 accountant shortage statistic
Data compounding explanation
Outcome-as-a-Service model
Innovator's dilemma application
Copilot → autopilot transition challenges
Founder collaboration via tagging / datasets
Keep descriptions concise yet precise; avoid unnecessary verbosity in literals.
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.
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).
All DBpedia references MUST use fully expanded IRIs (e.g., http://dbpedia.org/resource/...) — never CURIEs or prefixed names.
All Wikidata references MUST use fully expanded IRIs (e.g., http://www.wikidata.org/entity/...) — never CURIEs or prefixed names.
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.
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.
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 ; ... ].
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.
CRITICAL — Before outputting the Turtle, you MUST perform a compliance self-audit. Verify each item and report PASS or FAIL (with the violation fixed):
:analysis has schema:hasPart linking :faqSection, :glossarySection, :howtoSection
:faqSection is a schema:FAQPage with schema:mainEntity listing all :q1–:q12
:glossarySection is a schema:DefinedTermSet with schema:hasDefinedTerm listing all 10 terms
:howtoSection is a schema:HowTo with schema:step listing all :step1–:step7
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
NAICS codes use ?input=&year=2022&details= pattern (not ?code=)
No file: scheme IRIs exist anywhere
Ontology has schema:name + schema:description + schema:identifier; all custom classes/properties have rdfs:isDefinedBy :
No blank nodes for schema:Answer — every answer is a named entity (:aN) with schema:acceptedAnswer :aN
Inverse relationships explicit: every schema:isPartOf has a corresponding schema:hasPart, etc.
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.
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.
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 bothschema: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.
Lightweight ontology present: :Industry, two subclasses, two custom properties
Instance data on instances only — not on class definitions
Both schema:naics and schema:identifier (Census URL) on each vertical instance
Exactly 12 FAQ questions (:q1–:q12) wrapped in schema:FAQPage with schema:mainEntity
Each FAQ question has schema:isPartOf :faqSection linking back to the FAQ section
Exactly 10 glossary terms wrapped in schema:DefinedTermSet with schema:hasDefinedTerm
Exactly 7 HowTo steps (:step1–:step7) wrapped in schema:HowTo with schema:step
Each HowTo step has schema:isPartOf :howtoSection linking back to the HowTo section
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.
TAM values exact: "$140-200B" and "$50-80B"
schema:isbn "9780060521998" on :innovatorsDilemma
schema:identifier "US" on :unitedStates
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 the canonical IRI <https://github.com/OpenLinkSoftware/ai-agent-skills/tree/main/kg-generator#this>, with schema:name, schema:url (GitHub without #this), schema:description
Ontology has schema:name + schema:description + schema:identifier; all classes/properties have rdfs:isDefinedBy :
Every entity's rdf:type matches its semantic role: HowToStep → schema:HowToStep, Question → schema:Question, Answer → schema:Answer, DefinedTerm → schema:DefinedTerm, ArticleSection → schema:CreativeWork, ontology classes → their declared types. No entity typed as schema:Thing when a specific type exists.
Output is the Turtle code block only — no surrounding text
owl:sameAs never has the same IRI in both subject and object (including www/non-www variants of the same platform)
When the user asks for an HTML infographic companion to a generated Knowledge Graph, invoke the rdf-infographic-skillRDF Infographic Harness Mode requirements.
⛔ PRE-BUILD CHECK: Before generating HTML, load rdf-infographic-skill and re-read the "Harness Contract" (13-point checklist) and "Validation Checklist." Confirm: shared stem, resolver-backed entity links, POSH + JSON-LD pairing, floating nav (collapsed by default), theme toggle, KG Explorer (Basic + Advanced), attribution footer, MD parity, authority denotation rules (SoftwareApplication, Country), 0-failure delivery gate. Every item is a build target, not a post-delivery check. For the complete HTML/RDF/Markdown pairing specification including resolver configuration, KG Explorer behavior, navigation panel behavior, localStorage correctness, attribution, dark mode, and the full validation checklist, see the rdf-infographic-skill SKILL.md.
Output Paths
Save RDF documents to {rdf-output-directory} and HTML infographics to {html-output-directory}. Resolve from explicit user instructions or session defaults.
Confirm resolved full file paths before saving.
Entity IRIs and Resolver Links
Use {page_url} or {post-url} as the source-grounded namespace. Never use file: scheme IRIs when a canonical HTTPS URL exists.
Resolver priority: URIBurner (https://linkeddata.uriburner.com/describe/?url={entity-iri}) by default; user-designated resolver if specified; or none if user explicitly opts out.
Encode # as %23 exactly once in resolver url parameters. %2523 (double-encoded) is invalid.
Entity links open in new tabs: target="_blank" rel="noopener noreferrer".
FAQ questions, FAQ answers, glossary terms, glossary definitions, HowTo section title, and every HowTo step heading are ALL hyperlinked to their KG entity IRIs.
Visible semantic entities route through the configured resolver using their selected RDF IRIs, including DBpedia/Wikidata IRIs selected under the SoftwareApplication denotation rule.
For HTML dashboards from SPARQL named graph queries, also include "Explore Knowledge Graph" link.
About Section Template
Every HTML infographic generated from a named graph should include an About section explaining how the page was created. Use this template:
<sectionclass="section"id="about"><divclass="eyebrow-dark">About</div><divclass="section-title"><h2>About This Page</h2></div><pstyle="color:var(--muted);line-height:1.7">This knowledge graph overview was generated by querying the <ahref="https://linkeddata.uriburner.com/sparql"target="_blank"rel="noopener noreferrer"style="color:var(--accent)">URIBurner SPARQL endpoint</a> for the named graph <code>{graph-iri}</code>. The original document was transformed into RDF using {skills-used}, then uploaded to the Virtuoso-based URIBurner server. The SPARQL query retrieved {entity-types} from the knowledge graph. The HTML infographic was then rendered using {skills-used} powered by {model-id} and running on Virtuoso.</p><pstyle="margin-top:16px;font-size:0.85rem;color:var(--ink)"><strong>Technology Stack:</strong></p><ulstyle="margin-top:8px;font-size:0.85rem;color:var(--ink);list-style:disc;padding-left:20px"><li>AI Agent: <ahref="https://opencode.ai"target="_blank"rel="noopener noreferrer"style="color:var(--accent)">OpenCode</a></li><li>Skills: <ahref="https://github.com/anomalyco/opencode/tree/main/skill-name"target="_blank"rel="noopener noreferrer"style="color:var(--accent)">skill-name</a></li><li>Language Model: <ahref="https://opencode.ai/models/{model-id}"target="_blank"rel="noopener noreferrer"style="color:var(--accent)">{model-id}</a></li><li>Server Platform: <ahref="https://virtuoso.openlinksw.com/"target="_blank"rel="noopener noreferrer"style="color:var(--accent)">Virtuoso</a></li><li>Knowledge Graph: <ahref="https://linkeddata.uriburner.com/sparql"target="_blank"rel="noopener noreferrer"style="color:var(--accent)">URIBurner</a></li></ul></section>
Substitute: {graph-iri}, {skills-used}, {entity-types}, {skill-links}, and {model-id} with actual values.
Never persist collapsed dimensions in localStorage. Recover from stale state. Page-specific keys.
Dark mode: html[data-theme="dark"] and @media (prefers-color-scheme: dark) produce equivalent rendering. All colors via CSS variables.
GATE: 0 failures required. Validate: HTML parse, JS syntax, RDF parse + compliance audit, resolver links, local RDF link, nav behavior, skills attribution, dark mode consistency.
MD Document Companion Requirements
When generating a Markdown document alongside RDF and HTML outputs, the MD MUST follow these requirements:
⛔ PRE-BUILD CHECK: Before writing MD, re-read the "Checklist" at the end of this section. Confirm: all entity names/property names in relationships section resolver-hyperlinked, FAQ questions resolver-hyperlinked, glossary terms resolver-hyperlinked, HowTo step titles resolver-hyperlinked, Related Resources includes relative links to companion RDF and HTML, no plain-text code blocks for relationships. Build to pass every item.
Structure
Title + metadata block — author, date, source URL, reading time (if available).
Overview — 2–3 sentence summary of what the document covers.
How-To guide — when the RDF includes schema:HowTo, render all steps as a numbered list with step titles and descriptions.
FAQ — when the RDF includes schema:FAQPage, render all Q&A pairs. Each question hyperlinks to its KG entity IRI via the URIBurner resolver.
Glossary — when the RDF includes schema:DefinedTermSet, render all terms with definitions. Each term name hyperlinks to its KG entity IRI via the resolver.
Related Resources — links to the original source, companion RDF file, and companion HTML file (all relative paths).
Entity Hyperlinks
Every entity reference in the MD (classes, properties, instances, concepts, persons, organizations) MUST be hyperlinked using the URIBurner resolver pattern:
Relationships section — every entity and property name in relationship descriptions must be a resolver link.
Entity tables — entity names in table cells must be resolver links.
Glossary — each term name must be a resolver link.
FAQ — each question must be a resolver link.
How-To steps — each step title must be a resolver link.
Relationships Section
The MD MUST include a relationships section that:
Names every relationship (object property) linking domain entities.
Hyperlinks both the source entity, the property, and the target entity using resolver links.
Organizes relationships from the central/coordinating entity outward (e.g., Trip as the dispatch hub).
Uses bulleted or indented lists for visual hierarchy — not plain-text code blocks.
Checklist
All entity names in the relationships section are resolver-hyperlinked.
All property names in the relationships section are resolver-hyperlinked.
FAQ questions are resolver-hyperlinked.
Glossary terms are resolver-hyperlinked.
How-To step titles are resolver-hyperlinked.
Related Resources section includes relative links to companion RDF and HTML files.
No plain-text code blocks used for relationship descriptions that should be hyperlinked.
"Explore Knowledge Graph using SPARQL" CTA link present at the top of the Related Resources section, using a SPARQL query with an explicit FROM <{graph-iri}> clause scoped to the named graph IRI derived from the DAV upload location (https://linkeddata.uriburner.com/DAV/demos/daas/{filename}.ttl). The query must use SELECT DISTINCT ?subject ?type (SAMPLE(?label) AS ?name) … GROUP BY ?subject ?type ORDER BY ?type LIMIT 50 — no default-graph-uri= URL parameter, no FILTER(STRSTARTS(...)) workaround.
Saving Output Files
Turtle: {descriptive-slug}-{model-id}.ttl (increment if file exists)
JSON-LD: {descriptive-slug}-{model-id}.jsonld (increment if file exists)
Default save location: {output-directory} — ask the user if not specified, or infer from context
Override if user specifies a path
Replace - with _ in {model-id} for filesystem safety (e.g., minimax_m2.5free)
Ontology Identifier Selection Rules
When generating RDF from documents, use these priority rules for entity types:
Use schema.org first — If schema.org/{Type} exists (e.g., schema:Person, schema:Organization), use it.
Check shared ontologies — Use well-known RDF vocabularies (e.g., Dublin Core (dc:), SKOS, FOAF, PROV, schema.org/ alternate terms). Do NOT assume a term exists without verification.
Create on-the-fly — If neither schema.org nor a shared ontology has the needed type:
Create a namespace IRI using the document base (e.g., https://linkeddata.uriburner.com/DAV/docs-for-knowledge-graph-and-embeddings-generation/UB-PDFs/ontology#)
Define the new class/property in the output with proper rdfs:comment for documentation.
Include the ontology IRI in the generated RDF's @prefix declarations.
Example:
@prefix somt: <https://linkeddata.uriburner.com/DAV/docs-for-knowledge-graph-and-embeddings-generation/UB-PDFs/ontology#> .
somt:Interview a rdfs:Class ;
rdfs:label "Interview" ;
rdfs:comment "An interview or conversation with a person, typically in a professional context." ;
rdfs:isDefinedBy somt: .
Do NOT use non-existent schema.org terms like schema:Interview — this causes errors and breaks SPARQL queries.
The output filenames SHOULD include a lowercase, filesystem-safe version of the underlying LLM model identifier to enable provenance tracking. Extract the model ID from the environment or task context:
Model Source
Example ID
minimax
minimax_m2.5free
openai
openai_gpt4o
anthropic
anthropic_sonnet4
google
google_gemini2
claudeCode
claude_code
Other
{provider}_{model} (lowercase, underscores, no spaces)
When generating a Knowledge Graph collection, produce both RDF Turtle and JSON-LD formats by default. This enables the HTML infographic companion to provide a format toggle in the footer SPARQL button.
Generation Workflow
Generate Turtle first — Use the selected template (Generic or Business & Market Analysis) to produce the primary .ttl file.
Convert to JSON-LD — Use rdflib to parse the Turtle and serialize as JSON-LD:
import rdflib
g = rdflib.Graph()
g.parse('output.ttl', format='turtle')
g.serialize('output.jsonld', format='json-ld', indent=2)
Verify both files — Ensure syntactic validity for each format before delivering.
Output Files
Both formats use the same slug and version:
Format
Filename
Purpose
Turtle
{slug}-{model-id}-{n}.ttl
Primary RDF (schema.org-friendly)
JSON-LD
{slug}-{model-id}-{n}.jsonld
Alternate RDF (JSON-native)
Both files share the same base namespace (@prefix : <{source-url}#>) and entity IRIs.
HTML Infographic Footer — SPARQL Button with Format Toggle
The footer of every HTML infographic MUST include a SPARQL button that lets users query the knowledge graph via URIBurner. Include format toggle tabs so users can select which RDF document to query.
⛔ PRE-BUILD CHECK: Before writing the footer HTML/JS, re-read this section's "Required HTML Structure," "Required CSS," and "Required JavaScript." Confirm: format toggle tabs (Turtle/JSON-LD), setSparqlFormat() function, GRAPH IRI uses DAV/demos/daas/{filename} (not source URL), query URL uses encodeURIComponent, #sparqlBtn href updates on toggle.
Required HTML Structure
<footer><divclass="kg-format-tabs"><buttonclass="active"id="fmtTtl"onclick="setSparqlFormat('ttl')">RDF Turtle</button><buttonid="fmtJsonld"onclick="setSparqlFormat('jsonld')">JSON-LD</button></div><pstyle="margin-bottom:20px"><aid="sparqlBtn"href="..."target="_blank"rel="noopener noreferrer">Explore Knowledge Graph using SPARQL</a></p></footer>
