How We Built the Minnesota Dunk Squad’s Wikidata Entity and Schema From Scratch

Background

Wikidata optimization for a local sports team presents a distinct set of challenges compared to personal brands or media entities. The Minnesota Dunk Squad is a dunk performance team based in Minnesota that brings together athletes who train, perform, and progress as a group with the shared goal of raising the standard of dunking in the state. The squad performs at basketball halftime shows, school assemblies, all-star games, and community events. Its members include Gideon Scheeler, Zhai Powell, Brooke Lance, Dylan Haugen, Isaac Ononiwu, and Christian Ferguson.

Unlike individual athletes who have personal bios, birth dates, and career statistics, a performance team entity requires different Wikidata properties: instance type, sport, location, main subject, and distribution of social presence across platforms. This case study documents how we built the entity from nothing and configured the website schema, following Dennis Yu’s Wikidata methodology for a team entity that had zero prior presence in the knowledge graph.

The Task

The Minnesota Dunk Squad had no Wikidata entity at all. A search for “Minnesota Dunk Squad” on Wikidata returned zero results. The website at minnesotadunksquad.com had Rank Math SEO installed with the setup wizard completed, but the Social Meta fields were entirely empty — meaning the JSON-LD schema on the site had an Organization entity with no sameAs URLs. The XML sitemap was also returning a 404 error. The goal was to create the Wikidata entity from scratch with all required properties and references, configure the website schema with sameAs URLs pointing back to Wikidata and social profiles, fix the broken sitemap, and establish the bidirectional bridge.

What We Did on Wikidata

We created Q138752225 using the Wikidata API with the label “Minnesota Dunk Squad,” the description “American dunk performance team based in Minnesota,” and aliases “MN Dunk Squad” and “Minnesota Dunkers.” We then added 11 statements in sequence, each with a reference URL pointing to the most authoritative source available.

The core entity statements include: instance of (sports team), sport (basketball), country (United States), location (Minnesota), main subject (slam dunk), language of work or name (English), and official website (minnesotadunksquad.com with an English language qualifier). The identifier statements include: Facebook username, Instagram username (minnesotadunkers), YouTube channel ID (UCryM9P_EQ420swaQStwrvqg), and YouTube handle (MinnesotaDunkers with a channel ID qualifier to satisfy the Wikidata constraint).

Every statement was referenced to either the official website or the corresponding social platform URL. The entity was built entirely through API calls rather than the Wikidata web interface, which allowed for faster execution and consistent reference formatting.

What We Did on the Website

On minnesotadunksquad.com, we navigated to Rank Math’s Titles and Meta settings under the Social Meta tab. The Facebook Page URL was set to the squad’s Facebook profile. The Additional Profiles textarea was filled with four sameAs URLs: the Wikidata entity (Q138752225), Instagram, YouTube, and Facebook.

After saving, we verified the frontend JSON-LD output. The Organization entity now outputs five sameAs URLs including the Wikidata entry. We also discovered the XML sitemap was returning a 404 error. Flushing the WordPress permalink rewrite rules by saving the Permalink Settings page resolved this, and the sitemap is now live with three sub-sitemaps for posts, pages, and categories.

Five Critical Decisions

First, we caught a wrong Q-item mapping for the “main subject” property. The initial search for “slam dunk” returned Q2302355, which turned out to be Paraninoe simpla — a species of moth. Entity name collisions in Wikidata are common and dangerous if not caught. We removed the wrong item and replaced it with Q870803 (slam dunk, the basketball technique). This is the same class of error Dennis describes in his article: plausible-looking Q-items that point to entirely unrelated entities.

Second, we had to determine the correct YouTube channel ID. The channel URL uses the handle @MinnesotaDunkers, but Wikidata’s P2397 property requires the internal channel ID (UCryM9P_EQ420swaQStwrvqg), not the vanity handle. We extracted this from the page source of the YouTube channel page.

Third, we chose “sports team” (Q12973014) as the instance type rather than “organization” or “sports club.” This is the most precise classification for a dunk performance group that trains and performs together, and it aligns with how similar entities like exhibition basketball teams are categorized in Wikidata.

Fourth, the Minnesota Dunk Squad does not have a Twitter/X account. The footer on the website has a “Twitter” icon, but it actually links to the YouTube channel. Rather than adding a non-existent social profile, we left the Twitter Username field empty in Rank Math and omitted the X property from Wikidata entirely. Accuracy matters more than completeness.

Fifth, the broken sitemap required a fix beyond the Wikidata and schema work. A 404 sitemap means Google cannot efficiently discover and crawl the site’s pages, which undermines the entire knowledge panel strategy. Flushing the WordPress rewrite rules resolved this without requiring any plugin changes or server configuration.

Effort and Cost Comparison

Creating the Wikidata entity from scratch — including the initial entity creation, adding 11 statements with references, catching and correcting one wrong Q-item, adding qualifiers, and verifying the final state — took approximately 5 minutes of agent execution time. The schema configuration on minnesotadunksquad.com — filling Social Meta fields, fixing the sitemap, and verifying frontend output — took another 3 minutes. Total agent time was roughly 8 minutes.

For a human doing this manually, creating a new Wikidata entity through the web interface involves filling out the creation form, then adding each statement one by one with entity searches, reference additions, and qualifier settings. This typically takes 45 to 90 minutes for someone familiar with Wikidata. The schema and sitemap work adds another 20 to 30 minutes. A reasonable total estimate for a human is 1 to 2 hours.

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

What Required a Human vs. What the Agent Did Autonomously

The agent handled the entire workflow autonomously: creating the Wikidata entity via API, adding all statements and references, detecting the moth species Q-item error and self-correcting, extracting the YouTube channel ID from page source, configuring Rank Math Social Meta, fixing the broken sitemap, and verifying both the Wikidata entity and frontend schema output.

Human involvement was limited to three areas. First, the instruction to create the entity and follow Dennis’s methodology. Second, logging into the WordPress admin (the agent cannot enter passwords). Third, reviewing the completed work before publishing this documentation.

Information Ingestion Inventory

To complete this task, the agent consumed content from the following sources: the Wikidata search results page (confirming no existing entity), the Wikidata API for entity creation and claim management, the minnesotadunksquad.com homepage for team description and member names, the Book Us page for service details, the blog page for activity context, the YouTube channel page for extracting the channel ID, the Rank Math Social Meta settings page, the WordPress Permalink Settings page for sitemap repair, the frontend JSON-LD output for schema verification, and the sitemap URL for indexing confirmation. Total API calls to the Wikidata API numbered approximately 16 (1 entity creation, 11 claim additions, 1 removal, 1 correction, 2 qualifier additions). Estimated token usage was approximately 110,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, one caught and fixed (moth species replaced with slam dunk). Description is accurate and specific: yes. Aliases cover common name variations: yes (MN Dunk Squad, Minnesota Dunkers). 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 (fixed from 404). JSON-LD validates on frontend: yes. Social profiles are consistent across Wikidata and schema: yes. YouTube channel ID is correct (not a placeholder or handle): yes. Facebook numeric ID resolves correctly: yes. Instance type is appropriately specific: yes. All 15 of 15 compliance checks pass.

Why This Creates Specific Value for the Minnesota Dunk Squad

The Minnesota Dunk Squad is a performance team — not an individual — which means its Wikidata entity serves a different purpose than a personal brand. For the squad, having a verified Wikidata entity at Q138752225 means that Google can recognize the team as a distinct entity connected to its members (Dylan Haugen, Brooke Lance, Gideon Scheeler, and others), its performances (halftime shows, school assemblies, all-star games), and its mission of raising the standard of dunking in Minnesota. This entity becomes the anchor that connects every future mention of the Minnesota Dunk Squad across the web — event listings, news coverage, social media — back to a single verified identity. For a team seeking sponsorships, event bookings, and media coverage, being a recognized Google entity is the difference between being findable and being invisible.

Why This Creates Value for BlitzMetrics

This is the first team entity in the BlitzMetrics Wikidata series — proving that the same framework used for personal brands scales to organizations, groups, and teams. Building a Wikidata entity from scratch for a local sports team with no pre-existing Wikipedia presence is a harder challenge than optimizing an existing entity, and the documented process shows exactly how it was done. For BlitzMetrics, this expands the addressable market from individuals to organizations of any size — sports teams, podcasts, bands, nonprofits, local businesses — any entity that needs to be recognized by Google’s Knowledge Graph.

The Bidirectional Bridge

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

This is the fourth entity we have optimized following this methodology — after Trenton Sandler (person/athlete), Brooke Lance (person/athlete), and the Dunk Talk Podcast (media entity). The Minnesota Dunk Squad is the first team entity in the series — built entirely from scratch with no pre-existing Wikidata presence. The same Wikidata optimization and schema framework continues to scale across entity types. The Wikidata entity is live at Q138752225, and the schema can be verified on minnesotadunksquad.com.