Knowledge Graph Generator

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"

---

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.

---

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.).
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. Deliver — output in a single code block. If saving to file, use {slug}-1.ttl or {slug}-1.jsonld, incrementing as needed, saved to /Users/kidehen/Documents/LLMs/Claude Generated/web pages/.
8. 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.

Placeholders

Placeholder	Value
{page_url}	Canonical URL of the source — used as @base
{selected_text}	Full extracted text content of the source

Prompt

text

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 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.
14. 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.
15. Where relevant, include additional entity types when discovered e.g., Product, Offer, and Service etc.
16. Language-tag the values of annotation attributes; apply properly according to JSON-LD syntax rules.
17. Describe article authors and publishers in detail.
18. Use a relatedLink attribute to comprehensively handle all inline URLs. Unless told otherwise, it should be a maximum of 20 relevant links.
19. You MUST ensure smart quotes are replaced with single quotes.
20. 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.).

"""
{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.

Post-Generation Checklist

• @base set to {page_url}
• All subject/object IRIs are hash-based relative IRIs (except known authority entities)
• At least 10 schema:Question + schema:Answer pairs present
• owl:sameAs used (not schema:sameAs) for DBpedia cross-references
• 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
• Language tags applied to annotation literals where applicable
• JSON-LD is syntactically valid
• No guessed media URLs (thumbnailUrl, contentUrl, embedUrl)

---

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

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

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.

Prompt

text

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:
1. Base URI: Use relative hash URIs grounded in {post-url} as the namespace prefix :
2. Use schema.org as the primary vocabulary, 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:
   - 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.
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 the book), schema:identifier with plain literal for unambiguous codes (e.g. "US" for ISO 3166-1 alpha-2)
   - For NAICS codes, always 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)
   - Author (:grok), original post reference (:originalXPost), Julien Bek
   - :aiAutopilotDisruption (Product), :marketDisruptionAction, :servicesMarketDisruption
   - Example task :ndaExample
   - Concrete vertical instances :insuranceBrokerageVertical and :accountingVertical (with TAM, readiness, naics, offers WithCoverage/Rillet autopilots)
   - Organizations :withCoverage and :rillet + their autopilots
   - :shortageEvent (U.S. accountant shortage)
   - :unitedStates with ISO code
   - :threadReplies, :cursorExample, :scalingChallenges
   - :innovatorsDilemma (CreativeWork with isbn "9780060521998")
6. 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)
7. 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
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.
Current date for metadata: {current date}.

NAICS Identifier Pattern

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

turtle

: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

Entity type	Pattern	Example
Industry vertical	Census Bureau NAICS URL	https://www.census.gov/naics/?input=524210&year=2022&details=524210
Country	ISO 3166-1 alpha-2 plain literal	"US"
Book	ISBN prefixed notation	"ISBN:9780060521998"
Person	Canonical profile URL	"https://x.com/JulienBek"
Organization	Official homepage URL	"https://withcoverage.com"
Software/Product	Product homepage URL	"https://www.cursor.com"
Social media post	Canonical permalink	"https://x.com/user/status/123"
Web standard	Spec URL	"https://www.w3.org/TR/sparql11-overview/"
Formal standard	Standards designation string	"ISO/IEC 9075"

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}#
• 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)
• Exactly 10 glossary terms
• Exactly 7 HowTo steps (:step1–:step7)
• TAM values exact: "$140-200B" and "$50-80B"
• schema:isbn "9780060521998" on :innovatorsDilemma
• schema:identifier "US" on :unitedStates
• Output is the Turtle code block only — no surrounding text

---

Saving Output Files

• Turtle: {descriptive-slug}-1.ttl (increment if file exists)
• JSON-LD: {descriptive-slug}-1.jsonld (increment if file exists)
• Default save location: /Users/kidehen/Documents/LLMs/Claude Generated/web pages/
• Override if user specifies a path