How We Built the Dunk Talk Podcast’s Wikidata Entity and Schema From Scratch

Background

Wikidata optimization for a podcast entity is a different challenge than optimizing a personal brand. The Dunk Talk Podcast is a podcast dedicated to documenting basketball dunking culture through long-form conversations with athletes, coaches, and creators. Hosted by Dylan Haugen and Hunter Castona, the show has published over 68 episodes featuring some of the most respected names in modern dunking — from Jordan Kilganon and Isaiah Rivera to Dom Gonzales and Anthony Height. The podcast is available on YouTube, Spotify, and Apple Podcasts, with clips distributed across Instagram and TikTok.

Unlike individual athlete profiles, a podcast entity presents a unique challenge for knowledge graph optimization. The entity type is different (podcast vs. person), the properties are different (hosts, distribution platforms, episode counts vs. birthdate, height, occupation), and the schema type is Organization rather than Person. This case study documents how we applied Dennis Yu’s Wikidata methodology to a media entity rather than a personal brand.

The Task

The Dunk Talk already had a partially built Wikidata entity (Q138580636) with 16 statements and a basic description, but every single statement had zero references. The podcast’s website at dunktalks.com had Rank Math SEO installed with the setup wizard completed, but the Social Meta fields were empty — meaning the JSON-LD schema had no sameAs URLs linking back to Wikidata or any social profiles. The goal was to add references to all 16 existing claims, add missing properties, fix any incorrect entity mappings, configure the website schema with sameAs URLs, and establish the bidirectional bridge between Wikidata and the site.

What We Did on Wikidata

We started by pulling all 16 claim IDs from the Wikidata API and batch-adding references to every statement. Each reference was matched to the most authoritative source available: Apple Podcasts URLs for inception date and podcast ID, Spotify URLs for the Spotify show ID, YouTube URLs for the channel ID and episode count, and the official website URL for subject matter, genre, language, and country properties.

Beyond references, we added several missing properties. The Apple Podcasts podcast ID was added with a reference to the Apple Podcasts listing. A Facebook username was added pointing to the podcast’s Facebook page. The X/Twitter username (dunktalkpodcast) was added under the correct property (P2002). We also added Apple Podcasts as a distribution platform alongside Spotify and YouTube, which were already listed. Finally, we added a language qualifier to the official website statement for consistency with Dennis’s checklist.

The entity now has 20 statements, all with references, covering instance type, inception, title, subjects, genre, distribution platforms, country, language, episode count, official website, and six identifier properties.

What We Did on the Website

On dunktalks.com, we navigated to Rank Math’s Titles and Meta settings under the Social Meta tab. The Facebook Page URL was set to the podcast’s Facebook profile. The Twitter Username was set to dunktalkpodcast. The Additional Profiles textarea — which maps directly to the sameAs property in schema — was filled with seven URLs: the Wikidata entity, Instagram, YouTube, Spotify, Apple Podcasts, X/Twitter, and Facebook.

After saving, we verified the frontend JSON-LD output. The Organization entity on dunktalks.com now outputs eight sameAs URLs, including the Wikidata entry. The Person entity (for the site owner) remains separate. We also confirmed the XML sitemap at dunktalks.com/sitemap_index.xml was loading correctly with three sub-sitemaps for posts, pages, and categories.

Five Critical Decisions

First, we had to catch and fix a wrong Q-item mapping. The initial attempt to add Apple Podcasts as a distribution platform linked to Q4781255 (Apple Valley Airport) instead of Q70058728 (Apple Podcasts). Entity name collisions are common in Wikidata — the search returns the closest text match, not necessarily the correct entity. We caught this through verification and replaced it with the correct item.

Second, the X/Twitter property required the right property selection. Wikidata has both P6552 (X numeric user ID) and P2002 (X username). The initial claim was added under the wrong property using a username value. We removed it and re-added under P2002 with the correct value format.

Third, applying a person-focused methodology to a podcast entity required rethinking which properties matter. Properties like birthDate, height, and alumniOf are irrelevant for a podcast. Instead, the key properties are inception, number of episodes, distributed by, host/presenter, genre, and main subject. Dennis’s checklist transfers well once you map person properties to their media equivalents.

Fourth, the schema type distinction matters. A podcast website should use Organization (or PodcastSeries) as its primary schema type, not Person. Rank Math was already configured correctly for this, but the sameAs array was empty — which meant the schema existed in name only without the entity connections that give it meaning.

Fifth, the Facebook username presented an edge case. The Dunk Talk’s Facebook page uses a numeric ID (61577990706901) rather than a vanity URL. We stored the numeric ID as the Facebook username property value in Wikidata and used the full profile URL with the numeric ID as the sameAs value in the schema. Both formats are valid, but they need to resolve to the same page.

Effort and Cost Comparison

The Wikidata work — pulling claim IDs, batch-adding 16 references via API, adding 4 new properties, catching and fixing 2 wrong entity mappings, and adding a language qualifier — took approximately 4 minutes of agent execution time. The schema configuration on dunktalks.com — filling Social Meta fields and verifying frontend output — took another 3 minutes. Total agent time was roughly 7 minutes.

For a human doing this manually through the Wikidata web interface, adding references to 16 claims involves clicking edit, add reference, typing the URL, and saving for each one — roughly 2 to 3 minutes per claim, or 30 to 50 minutes total. Adding new properties and catching wrong Q-items requires searching, verifying, and potentially removing incorrect claims. The schema work requires navigating WordPress admin, understanding which Rank Math fields map to which schema properties, and verifying the output. A reasonable estimate for a human is 1.5 to 2.5 hours, assuming familiarity with both platforms.

At the BlitzMetrics rate of fifteen to thirty dollars per hour for a trained virtual assistant, the human cost would be twenty-two to seventy-five dollars. The agent cost for API calls and compute was approximately fifteen cents.

What Required a Human vs. What the Agent Did Autonomously

The agent handled the entire Wikidata workflow autonomously: pulling entity data via the API, identifying unreferenced claims, batch-adding references with appropriate source URLs, adding missing properties, detecting and correcting wrong Q-item mappings, and adding qualifiers. It also handled the full Rank Math Social Meta configuration and frontend schema verification.

Human involvement was limited to two areas. First, the initial decision of what entity to work on and the instruction to follow Dennis’s methodology. Second, the review of completed work to confirm accuracy before publishing this documentation. The agent flagged the Apple Valley Airport and X property errors on its own and self-corrected without human prompting.

Information Ingestion Inventory

To complete this task, the agent consumed content from the following sources: the Wikidata entity page for Q138580636, the Wikidata API for entity data and claim IDs, the dunktalks.com homepage and about page for background information and social links, the dunktalks.com sitemap for indexing verification, the Rank Math Social Meta settings page, the frontend JSON-LD output on dunktalks.com, and the Apple Podcasts, Spotify, YouTube, Instagram, Facebook, and X profile pages for reference URLs. Total API calls to the Wikidata API numbered approximately 22 (16 reference additions, 4 new property additions, 2 corrections). Estimated token usage across all page reads, API calls, and content generation was approximately 130,000 tokens.

Guidelines Compliance Scorecard

Every claim has at least one reference: yes. All references point to authoritative, live URLs: yes. No entity conflation (wrong Q-items resolved): yes, two caught and fixed. Description is accurate and specific: yes. Aliases cover common name variations: yes (Dunk Talk Podcast, Dunk Talk, The Dunk Talk Podcast). Official website has language qualifier: yes. Schema includes sameAs pointing to Wikidata: yes. Wikidata includes official website pointing to site: yes. Bidirectional bridge is active: yes. Sitemap is accessible: yes. JSON-LD validates on frontend: yes. Social profiles are consistent across Wikidata and schema: yes. Facebook numeric ID resolves correctly: yes. X/Twitter uses correct property (P2002): yes. Apple Podcasts uses correct entity (Q70058728): yes. Distribution platforms are complete (Spotify, YouTube, Apple Podcasts): yes. All 16 of 16 compliance checks pass.

Why This Creates Specific Value for the Dunk Talk Podcast

The Dunk Talk Podcast has published over 68 episodes featuring some of the most respected names in modern dunking — from Jordan Kilganon and Isaiah Rivera to Dom Gonzales and Anthony Height. Having a Wikidata entity at Q138580636 means Google can now recognize Dunk Talk as a distinct media entity connected to its hosts (Dylan Haugen and Hunter Castona), its guests, and the broader dunking culture it documents. For a podcast competing for listeners on YouTube, Spotify, and Apple Podcasts, entity recognition translates directly into discoverability: when someone searches for dunking culture, basketball entertainment, or any of the guests who have appeared on the show, the podcast’s verified entity creates a pathway to discovery that did not exist before.

Why This Creates Value for BlitzMetrics

The Dunk Talk build is the first media entity in the Wikidata series, demonstrating that podcasts can and should have their own Wikidata entries separate from their hosts’ personal entities. This distinction matters because many podcasters assume their personal Knowledge Panel will cover their show — but Google treats people and media entities as separate things. Documenting this build creates a replicable template for any podcast that wants to establish its own entity presence in the Knowledge Graph, expanding BlitzMetrics’ service offering to the podcasting vertical.

The Bidirectional Bridge

The same principle from Dennis Yu’s Wikidata article applies to media entities: the Wikidata official website property points to dunktalks.com, and dunktalks.com’s schema sameAs points back to Wikidata Q138580636. That bidirectional link is what tells Google these two data sources describe the same entity.

This is the third entity we have optimized following this methodology — after Trenton Sandler (person/athlete) and Brooke Lance (person/athlete). The Dunk Talk is the first media entity in the series, demonstrating that the same Wikidata optimization and schema framework scales across entity types. The Wikidata entity is live at Q138580636, and the schema can be verified on dunktalks.com.