# **Architecting Robust Music Metadata Pipelines: Remediation of Legacy Extraction Systems and Implementation of Polyglot Ingestion Strategies**

## **1\. The Crisis of Metadata Extraction in Modern Digital Music Architectures**

The acquisition of high-fidelity music metadata—encompassing the intricate web of artists, releases, tracks, labels, and their interrelationships—has evolved from a trivial task of web crawling into a complex engineering challenge. The user’s current predicament, characterized by the simultaneous failure of a Bandcamp scraper relying on JSON-LD and a Wikidata extractor utilizing SPARQL, is not an isolated incident but a symptom of a broader shift in web architecture and data governance.

Historically, the "open web" allowed for passive extraction via the parsing of static HTML documents. However, the contemporary digital music supply chain is increasingly fragmented across Single Page Applications (SPAs) that obfuscate data behind hydration layers, and Semantic Web endpoints that enforce strict computational limits to protect their graph infrastructures. The failure of the existing JSON-LD scraper on Bandcamp indicates a misalignment with the platform's transition to React-based state management, while the struggles with Wikidata’s SPARQL endpoint suggest a misunderstanding of graph query optimization and the computational costs of federated knowledge retrieval.

This report provides an exhaustive technical analysis and remediation roadmap for these systems. It moves beyond superficial scripting fixes to propose a robust, polyglot ingestion architecture. The analysis establishes that the remediation of the Bandcamp subsystem requires targeting the application state blob rather than the SEO-facing JSON-LD. Simultaneously, the Wikidata subsystem must pivot from naive scraping patterns to optimized, keyset-paginated graph traversals. Furthermore, the report argues that relying solely on these two sources is architecturally unsound. A resilient pipeline must integrate **MusicBrainz** as the canonical identifier backbone, utilizing its massive relational database dumps to resolve ambiguity, while leveraging the **Spotify Web API** and **Discogs API** for enrichment, and **ListenBrainz** for fuzzy resolution.

The following sections dissect the failure modes of the current tools, provide precise architectural blueprints for their repair, and evaluate the alternative sources necessary to construct an industry-grade metadata warehouse.

## ---

**2\. Remediation of the Bandcamp Extraction Subsystem**

The reported total failure of the Bandcamp scraper ("does not work at all via JSON-LD") is a deterministic result of the platform’s frontend evolution. Bandcamp has shifted from a server-side rendered architecture, where metadata was fully exposed in the DOM (Document Object Model) and SEO tags, to a client-side hydration model. Understanding this architectural shift is prerequisite to implementing a functional scraper in 2025\.

### **2.1 Root Cause Analysis: The Deprecation of JSON-LD Reliance**

JSON-LD (JavaScript Object Notation for Linked Data) is a W3C standard designed to embed structured data within HTML documents, primarily for consumption by search engines like Google and Bing. In the past, developers treated the \<script type="application/ld+json"\> tag as a reliable API for scraping. However, for a platform like Bandcamp, JSON-LD serves a marketing function, not a data transport function.

The research indicates several critical deficiencies in relying on Bandcamp's JSON-LD implementation:

1. **Incompleteness:** The JSON-LD schema on Bandcamp pages is optimized for Google's Knowledge Graph, containing only high-level entities such as the Album Name, Artist Name, and Cover Image URL. It consistently lacks the granular metadata required for industry applications, such as precise track durations, internal file IDs, download URLs for purchased content, and detailed credits.1  
2. **Staleness:** The JSON-LD block is often statically generated or cached aggressively, meaning it may not reflect the real-time status of a release (e.g., stock levels for physical merchandise or updated licensing terms).  
3. **Data Type Mismatches:** The rigid schema of JSON-LD often forces data into simplified formats, losing the nuance of the underlying database (e.g., flattening complex artist credits into a single string).

The failure of the user's current code base is therefore not a bug in the code itself, but a strategic error in targeting a deprecated data artifact.

### **2.2 The "Pagedata" Architecture: The Definitive Extraction Vector**

To implement a Bandcamp scraper properly, one must target the **State Hydration Blob**. Modern web applications, including Bandcamp, inject the full initial state of the application into the HTML to allow the client-side JavaScript framework (likely React or a similar library) to render the page immediately without waiting for subsequent API calls.

This state is located within a div element with the ID pagedata. This element possesses a custom attribute named data-blob. This attribute contains a URL-encoded or HTML-entity-encoded JSON string representing the complete, authoritative data model for the page.2

#### **2.2.1 Architectural Anatomy of the data-blob**

The data-blob is the "Golden Key" to Bandcamp scraping. Unlike the sanitized JSON-LD, the blob contains the raw data used by the application itself. Accessing this requires an HTML parser capable of handling large attribute values.

**Target Element:**

\<div id="pagedata" data-blob="{...}"\>\</div\>

**Key Data Structures within the Blob:**

The JSON object parsed from this blob is expansive. Critical keys for music metadata include:

| Key | Data Type | Description and Utility |
| :---- | :---- | :---- |
| artist | String | The canonical name of the artist. |
| current | Object | Contextual metadata about the current page (e.g., release\_date, about text). |
| digital\_items | Array | A comprehensive list of tracks or releases available on the page. This is the primary source for track IDs. |
| trackinfo | Array | Detailed metadata for each track, including file (streaming URLs), duration (float seconds), and title. |
| album\_release\_date | String | The exact timestamp of the release in RFC 2822 format. |
| packages | Array | Physical merchandise definitions (Vinyl, CD, Cassette), including stock status and pricing. |
| url | String | The canonical URL, essential for resolving redirects or custom domain mapping. |
| fan\_data | Object | If a user is logged in, this contains the fan\_id and authentication tokens.2 |

#### **2.2.2 Implementation Logic and Security Considerations**

To remediate the scraper, the extraction logic must be refactored to prioritize the pagedata element. The implementation pipeline should strictly adhere to the following sequence:

1. **HTTP Request:** Initiate a GET request to the target Bandcamp URL. It is imperative to include a User-Agent header mimicking a standard browser to avoid immediate IP filtering.  
2. **DOM Parsing:** Utilization of a robust HTML parser is non-negotiable. Libraries such as BeautifulSoup (Python) or Cheerio (Node.js) are standard. The parser must locate the element \#pagedata.  
3. **Attribute Extraction:** Retrieve the string value of the data-blob attribute.  
4. **JSON Decoding:** Pass the string to a standard JSON parser.

**Security Warning: The Risk of eval()** Historical scraping discussions 4 often suggest using regex to extract JavaScript variables (like var EmbedData) and then passing them to an eval() function. This is a catastrophic security vulnerability. Executing arbitrary JavaScript code retrieved from a remote server (Remote Code Execution) exposes the scraping infrastructure to compromise if the target site is malicious or compromised. The data-blob approach allows for safe JSON.parse() or json.loads(), which parses data without executing code. This distinction is vital for a production-grade system.4

### **2.3 Advanced Extraction: Hidden APIs and Private Endpoints**

For requirements extending beyond public page metadata—such as scraping user collections, wishlists, or mobile-app-specific data—HTML parsing becomes inefficient. The research identifies "Dark APIs" used by Bandcamp’s own frontend and mobile applications.

#### **2.3.1 The Fan Collection API**

Scraping user collections (e.g., "what albums does this superfan own?") is supported via a specific endpoint used by the "load more" buttons on profile pages. This requires two pieces of data from the initial pagedata blob: the fan\_id and the older\_than\_token (a pagination cursor).2

**Endpoint Protocol:**

* **URL:** https://bandcamp.com/api/fancollection/1/collection\_items  
* **Method:** POST  
* **Payload:**  
  JSON  
  {  
      "fan\_id": 123456,  
      "older\_than\_token": "1586531374:1498564527:a::",  
      "count": 20  
  }

* **Response:** A JSON object containing a batch of items (releases) in the user's collection, including their review text and purchase date. This method is significantly more robust than iterating over DOM elements, which changes with CSS updates.

#### **2.3.2 The Mobile Sync Endpoint**

Deep research into the Bandcamp mobile application traffic 6 reveals an endpoint at /api/collectionsync/1/collection. This endpoint is designed to sync the user's purchases to their device. While powerful, accessing this requires generating a Bearer Token (Authorization: Bearer \<token\>), which involves reverse-engineering the authentication handshake of the mobile app. While technically feasible, this crosses into a higher risk category regarding Terms of Service violation compared to public scraping and should be reserved for scenarios where public data is insufficient.

### **2.4 Bandcamp Remediation Summary**

The user's Bandcamp scraper fails because it looks for a ghost (JSON-LD). The fix is to look for the engine (the pagedata blob). By refactoring the extractor to parse this JSON object safely, the system gains access to the complete, high-fidelity dataset that powers the Bandcamp website itself, ensuring resilience against superficial layout changes.

## ---

**3\. Optimization of the Wikidata and SPARQL Subsystem**

The user's second failure point is the "Wikidata via SPARQL" scraper. The phrasing "attempt to scrape Wikipedia" reveals a fundamental misconception. Wikidata is not Wikipedia; it is a structured graph database (knowledge base) that underpins Wikipedia. Querying it requires adherence to Graph Theory principles and the specific constraints of the **Blazegraph** database engine that powers the Wikidata Query Service (WDQS).

### **3.1 The Mechanics of Failure: Timeouts and Unoptimized Scans**

The most common failure mode for generic SPARQL scrapers is the **Timeout** (500 Internal Server Error or 503 Service Unavailable). The WDQS imposes a hard execution time limit (typically 60 seconds) and a memory limit. Queries that attempt to "scan" the database (e.g., "Find all artists") without strict indexing force the engine to load billions of triples into memory, resulting in instant termination.7

The user's current "scraper" likely attempts to iterate through items or search by strings (e.g., FILTER regex(?name, "Band Name")). Regex searches on a database of 100+ million items are computationally prohibitive and will invariably fail.

### **3.2 Optimization Strategy 1: Ontology-Driven Constraints**

To fix the scraper, the query logic must be inverted. Instead of searching for *names*, the scraper must search for *types*. In Wikidata, this is done using the wdt:P31 (Instance of) property. This property is heavily indexed and allows the query optimizer to drastically reduce the search space immediately.9

**Core Musical Ontology for Query Construction:**

Understanding the specific Q-codes (Item IDs) is mandatory for constructing efficient queries.

| Entity Type | Q-Code | Description |
| :---- | :---- | :---- |
| **Human** | wd:Q5 | The base type for individual people. |
| **Musician** | wd:Q639669 | Occupation (P106) linked to Humans. |
| **Musical Group** | wd:Q215380 | The base type for bands, orchestras, and choirs. |
| **Album** | wd:Q482994 | The generic class for music albums. |
| **Studio Album** | wd:Q208569 | A specific subclass of Album. |
| **Single** | wd:Q134556 | A single track release. |
| **Extended Play (EP)** | wd:Q169930 | A release shorter than an album. |

**Optimized Query Pattern:**

A proper query constraints the dataset *first*.

Code snippet

SELECT?group?groupLabel WHERE {  
 ?group wdt:P31 wd:Q215380.  \# MUST be a Musical Group  
 ?group rdfs:label "Metallica"@en.  
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }  
}

This query executes in milliseconds because the wdt:P31 index narrows the search from 100 million items to a few million, and the label index narrows it further.7

### **3.3 Optimization Strategy 2: The MINUS Pattern for Noise Reduction**

A common issue with scraping Wikidata is "dirty" data. A query for "Musicians" might return an actor who sang one song in a movie, or a fictional character. To ensure high-quality metadata relevant to the music industry, the MINUS clause is essential.9

For example, to exclude Classical musicians (who may introduce data formatting issues or irrelevance for a pop/rock database), the scraper can explicitly subtract them:

Code snippet

MINUS {  
 ?item wdt:P136?genre.  
  VALUES?genre { wd:Q9730 wd:Q8361 } \# Classical Music, Baroque Music  
}

This filtering occurs at the database level, preventing the scraper from wasting bandwidth on irrelevant records.

### **3.4 Optimization Strategy 3: Keyset Pagination (The "Offset" Trap)**

The most critical architectural fix for a "bulk" scraper is the pagination strategy. Standard SQL-style pagination (LIMIT 100 OFFSET 10000\) is disastrous in SPARQL. As the offset increases, the database must compute and sort all previous rows before discarding them. At high offsets, this guarantees a timeout.11

**The Solution: ID-Based (Keyset) Pagination**

Wikidata IDs (Q-IDs) are integers. The robust way to scrape the entire database is to sort by ID and filter for items greater than the last seen ID.

**Algorithm:**

1. **Query 1:** SELECT?item WHERE {?item wdt:P31 wd:Q215380. } ORDER BY?item LIMIT 500\.  
2. **Process:** Extract the data. Note the last Q-ID (e.g., Q5000).  
3. **Query 2:** SELECT?item WHERE {?item wdt:P31 wd:Q215380. FILTER (?item \> wd:Q5000) } ORDER BY?item LIMIT 500\.

This method has O(1) complexity for the database, ensuring that the scraper never times out, regardless of how deep into the dataset it traverses.

### **3.5 Federated Identity Resolution**

The true power of Wikidata lies not in its raw metadata (which can be sparse), but in its **External Identifiers**. Wikidata acts as a "Rosetta Stone," mapping a single entity to its IDs in dozens of other databases.

To implement the scraper "properly," it should be configured to retrieve these specific properties:

* **P434:** MusicBrainz Artist ID (The Industry Standard).  
* **P1902:** Spotify Artist ID.  
* **P3283:** Bandcamp Artist ID.  
* **P1953:** Discogs Artist ID.

By fetching these IDs, the Wikidata scraper ceases to be a standalone tool and becomes the **Ingestion Bridge** that enables the entire pipeline to access the specialized APIs of Spotify, Discogs, and Bandcamp without complex text searching.13

## ---

**4\. The Canonical Backbone: MusicBrainz**

The user requested "other sources." In the domain of music metadata, **MusicBrainz** is the undisputed "Source of Truth." It is an open music encyclopedia that maintains a rigorous schema distinguishing between **Release Groups** (the abstract concept of an album), **Releases** (specific physical or digital issues), **Recordings** (unique audio mixes), and **Works** (the composition itself).

### **4.1 Architecture: Database Dumps vs. API**

For an "exhaustive" project, utilizing the MusicBrainz API is often an architectural bottleneck.

#### **4.1.1 The API Rate Limit Constraint**

The MusicBrainz API enforces a strict rate limit of **1 request per second** per IP address.15 While this is sufficient for on-demand lookups, it is prohibitive for bulk ingestion. Scraping metadata for 1 million artists would take approximately 11.5 days of continuous operation. Furthermore, the API does not support "bursting"; exceeding the limit results in immediate 503 Service Unavailable errors or IP banning.16

#### **4.1.2 The PostgreSQL Dump Strategy**

The superior implementation for bulk data acquisition is to bypass the API entirely and utilize the **MusicBrainz Database Dumps**. These are massive snapshots of the entire database, released twice weekly.

* **Mechanism:** Download the mbdump.tar.bz2 archive (approx. several GBs).  
* **Deployment:** Load the dump into a local PostgreSQL instance (Docker containers are available for this specific purpose).  
* **Advantage:** This allows for **Infinite Query Velocity**. Complex SQL queries (e.g., "Find all tracks longer than 10 minutes released in 1995 on Vinyl") can be executed locally in milliseconds without hitting any rate limits.17  
* **Integration:** This local database becomes the backbone of the metadata system, providing the canonical MBIDs (MusicBrainz IDs) that link all other sources.

### **4.2 Handling "Messy" Data: ListenBrainz**

A common challenge in scraping is handling unstructured or "messy" filenames (e.g., 01\_song\_name\_final\_mix.mp3). **ListenBrainz**, a sister project to MusicBrainz, offers a specialized API endpoint for this.

**The metadata/lookup Endpoint:** This endpoint accepts fuzzy parameters (artist name, track name) and returns the canonical MusicBrainz metadata. It acts as a normalization layer, converting dirty scraper data into clean, ID-linked records.18

## ---

**5\. The Commercial and Social Ecosystem: Specialized APIs**

To achieve "nuanced understanding" and "rich insight" as requested, the system must integrate data from commercial platforms. These sources provide data types (popularity, lyrics, physical format details) that open databases often lack.

### **5.1 Spotify Web API: Popularity and Audio Analysis**

Spotify is the premier source for "audio intelligence" and consumption metrics.

**Authentication: The Client Credentials Flow** Unlike user-facing apps, a metadata scraper should use the **Client Credentials Flow**. This server-to-server authentication method requires only a Client ID and Client Secret and does *not* require a user to log in. It grants access to all public data (Artist profiles, Album tracklists, Audio Features).20

* **Endpoint:** https://accounts.spotify.com/api/token  
* **Grant Type:** client\_credentials  
* **Scope:** None required for public metadata.

**Rate Limits:** Spotify utilizes a rolling 30-second window for rate limiting. Empirical data suggests a limit of approximately **180 requests per rolling 30 seconds**. The scraper must implement "exponential backoff" logic to handle 429 Too Many Requests responses gracefully.21

**Unique Data Points:**

* **Audio Features:** Danceability, Energy, Valence, Tempo (BPM), Key.  
* **Popularity:** A 0-100 index derived from recent stream counts.

### **5.2 Discogs API: The Authority on Physical Media**

Discogs is essential if the metadata requirements include information on Vinyl, Cassettes, Matrix Runout codes, or specific pressings.

**Technical Constraints:**

* **Rate Limit:** The API permits **60 requests per minute** for authenticated users.23  
* **Authentication:** Authorization: Discogs key=YOUR\_KEY, secret=YOUR\_SECRET.  
* **Image Scraping Warning:** Discogs protects its image CDN (i.discogs.com) with aggressive Cloudflare bot detection. While metadata (JSON) is accessible via the API, scraping high-resolution cover art requires complex headers or browser automation, which risks IP bans. The API provides image URLs, but accessing them is the bottleneck.24

### **5.3 Genius API: Lyrics and Annotations**

For metadata concerning the *content* of the music (lyrics, meaning), Genius is the primary source.

* **Authentication:** OAuth2 (Bearer Token).  
* **Data Structure:** The API treats songs as "documents" and artists as "creators." It is particularly useful for linking a track to its "referents" (annotations explaining the lyrics).25  
* **Rate Limits:** Standard HTTP 429 responses indicate exhaustion; limits are generous for text metadata but stricter for search endpoints.

### **5.4 TheAudioDB and Last.fm**

* **TheAudioDB:** A community-driven database excellent for visual assets (Artist Logos, Clearart, Thumbnails) often missing from MusicBrainz.  
  * **Constraint:** The Free Tier (Test Key "2") is throttled to **2 requests per second**. A Patreon subscription ($8/mo) is required for production-level access.26  
* **Last.fm:** Valuable for crowd-sourced "Tags" (e.g., "shoegaze", "female vocalist") and "Scrobble Counts" (total listens), which serve as a proxy for historical popularity.27

## ---

**6\. Architectural Synthesis: The Polyglot Pipeline**

To satisfy the user's request to "implement these scrapers properly," we must synthesize these disparate sources into a coherent system. A single script is insufficient; a **Polyglot Pipeline** is required.

### **6.1 Architecture Overview**

The recommended architecture follows a "Hub-and-Spoke" model:

1. **The Hub (Identity Layer):** A local **MusicBrainz PostgreSQL** database serves as the authoritative source of IDs. It provides the skeletal structure (Artist \-\> Release Group \-\> Release \-\> Track).  
2. **The Bridge (Federation Layer):** An optimized **Wikidata Scraper** (using ID-based pagination) runs periodically to fetch new mappings between MusicBrainz IDs and external services (Spotify, Bandcamp, Discogs).  
3. **The Spokes (Enrichment Layer):**  
   * **Bandcamp Scraper:** Targeted execution. Instead of crawling random pages, it consumes a list of Bandcamp URLs derived from the Wikidata bridge. It parses the pagedata blob to fetch purchase links and merchandise status.  
   * **Spotify Ingest:** Queries the API via Client Credentials using the Spotify IDs found in Wikidata/MusicBrainz to fetch Audio Features and Popularity.  
   * **Discogs Ingest:** Fetches physical release details for items where MusicBrainz data is sparse.

### **6.2 Data Flow Diagram (Conceptual)**

 \<== (Basis of Truth) \==\>  
|  
        \+--\> \--(SPARQL P434)--\>  
|  
                  \+--\> \--(Audio Features)--\> \[Enriched Metadata\]  
|  
                  \+--\> \--(Merch/DLs)--\> \[Enriched Metadata\]  
|  
                  \+--\> \--(Vinyl Data)--\> \[Enriched Metadata\]

### **6.3 Conclusion**

The remediation of the user's codebase requires a fundamental shift in technical strategy. The "broken" Bandcamp scraper must be refactored to consume the pagedata state blob, bypassing the deprecated JSON-LD. The "failing" Wikidata scraper must be re-engineered to respect Blazegraph's constraints through wdt:P31 filtering and keyset pagination.

However, the robust solution lies in reducing reliance on scraping altogether. By adopting **MusicBrainz** as the central architectural pillar and utilizing the specialized APIs of **Spotify**, **Discogs**, and **Genius** for enrichment, the system evolves from a fragile set of scripts into a professional, resilient metadata warehouse capable of handling the scale and complexity of the modern music industry.

## ---

**7\. Comparative Analysis of Data Sources**

The following table summarizes the operational characteristics of the discussed sources to guide the user's implementation strategy.

| Source | Primary Data Type | Access Method | Rate Limit / Constraint | Remediation/Strategy |
| :---- | :---- | :---- | :---- | :---- |
| **Bandcamp** | Indie Releases, Merch, DL Links | **Scraping** (HTML Blob) | Unofficial (IP based) | Parse \#pagedata JSON blob. Avoid JSON-LD. |
| **Wikidata** | IDs, Social Links, Bio | **SPARQL** (Graph) | 60s Timeout / Memory | Use wdt:P31 filters & ID-based pagination. |
| **MusicBrainz** | Canonical Schema, Relations | **DB Dump** / API | 1 req/sec (API) | Use Local DB Dumps for bulk ingestion. |
| **Spotify** | Audio Features, Popularity | **API** (REST) | Rolling 30s (\~180/min) | Use Client Credentials Flow (Server-side). |
| **Discogs** | Physical Formats (Vinyl) | **API** (REST) | 60 req/min | Auth required. Beware image throttling. |
| **Genius** | Lyrics, Annotations | **API** (REST) | Standard HTTP 429 | Use OAuth Bearer tokens. |
| **TheAudioDB** | Visual Assets (Logos) | **API** (REST) | 2 req/sec (Free) | Use strictly for visuals; pay for production. |
| **ListenBrainz** | Fuzzy Matching / History | **API** (REST) | Moderate | Use metadata/lookup to fix messy filenames. |

#### **Works cited**

1. bandcamp.com \- Extractor failed to obtain "id" · Issue \#9195 · yt-dlp/yt-dlp \- GitHub, accessed January 29, 2026, [https://github.com/yt-dlp/yt-dlp/issues/9195](https://github.com/yt-dlp/yt-dlp/issues/9195)  
2. Scraping Bandcamp fan collections via POST \- Stack Overflow, accessed January 29, 2026, [https://stackoverflow.com/questions/64418583/scraping-bandcamp-fan-collections-via-post](https://stackoverflow.com/questions/64418583/scraping-bandcamp-fan-collections-via-post)  
3. Can a href be hidden from a scrape using beautifulsoup? \- Stack Overflow, accessed January 29, 2026, [https://stackoverflow.com/questions/45929283/can-a-href-be-hidden-from-a-scrape-using-beautifulsoup](https://stackoverflow.com/questions/45929283/can-a-href-be-hidden-from-a-scrape-using-beautifulsoup)  
4. I got bored of homework. Whipped up a Bandcamp ripping script for you all. \- Reddit, accessed January 29, 2026, [https://www.reddit.com/r/Python/comments/1ddtk2/i\_got\_bored\_of\_homework\_whipped\_up\_a\_bandcamp/](https://www.reddit.com/r/Python/comments/1ddtk2/i_got_bored_of_homework_whipped_up_a_bandcamp/)  
5. Why is my web scraping code not extracting any content? \- Stack Overflow, accessed January 29, 2026, [https://stackoverflow.com/questions/73738195/why-is-my-web-scraping-code-not-extracting-any-content](https://stackoverflow.com/questions/73738195/why-is-my-web-scraping-code-not-extracting-any-content)  
6. Reverse engineering Bandcamp authentication protocol \- Nemanja Mijailovic's Blog, accessed January 29, 2026, [https://mijailovic.net/2024/04/04/bandcamp-auth/](https://mijailovic.net/2024/04/04/bandcamp-auth/)  
7. Wikidata:SPARQL query service/query optimization, accessed January 29, 2026, [https://www.wikidata.org/wiki/Wikidata:SPARQL\_query\_service/query\_optimization](https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/query_optimization)  
8. Conceptualization and Evaluation of Idea Similarities based on Semantic Enrichment & Knowledge Graphs \- Freie Universität Berlin, accessed January 29, 2026, [https://www.mi.fu-berlin.de/en/inf/groups/hcc/theses/finished/2021-Theses/evaluation\_of\_mixed\_initiative\_concept\_annotation/2021\_Masterarbeit\_Stauss.pdf](https://www.mi.fu-berlin.de/en/inf/groups/hcc/theses/finished/2021-Theses/evaluation_of_mixed_initiative_concept_annotation/2021_Masterarbeit_Stauss.pdf)  
9. Wikidata: Get all non-classical Musicians via SPARQL query \- Stack Overflow, accessed January 29, 2026, [https://stackoverflow.com/questions/66637840/wikidata-get-all-non-classical-musicians-via-sparql-query](https://stackoverflow.com/questions/66637840/wikidata-get-all-non-classical-musicians-via-sparql-query)  
10. Wikidata:SPARQL query service/queries, accessed January 29, 2026, [https://www.wikidata.org/wiki/Wikidata:SPARQL\_query\_service/queries](https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries)  
11. How do I properly paginate a Wikidata SPARQL query? \- Stack Overflow, accessed January 29, 2026, [https://stackoverflow.com/questions/79719206/how-do-i-properly-paginate-a-wikidata-sparql-query](https://stackoverflow.com/questions/79719206/how-do-i-properly-paginate-a-wikidata-sparql-query)  
12. Pagination / Breaking up large query for Wikidata SparQL \- Stack Overflow, accessed January 29, 2026, [https://stackoverflow.com/questions/72804539/pagination-breaking-up-large-query-for-wikidata-sparql](https://stackoverflow.com/questions/72804539/pagination-breaking-up-large-query-for-wikidata-sparql)  
13. Wikidata:Database reports/List of properties/all, accessed January 29, 2026, [https://www.wikidata.org/wiki/Wikidata:Database\_reports/List\_of\_properties/all](https://www.wikidata.org/wiki/Wikidata:Database_reports/List_of_properties/all)  
14. Property talk:P434 \- Wikidata, accessed January 29, 2026, [https://www.wikidata.org/wiki/Property\_talk:P434](https://www.wikidata.org/wiki/Property_talk:P434)  
15. MusicBrainz API / Rate Limiting, accessed January 29, 2026, [https://musicbrainz.org/doc/MusicBrainz\_API/Rate\_Limiting](https://musicbrainz.org/doc/MusicBrainz_API/Rate_Limiting)  
16. Rate limit : r/MusicBrainz \- Reddit, accessed January 29, 2026, [https://www.reddit.com/r/MusicBrainz/comments/1pz5pps/rate\_limit/](https://www.reddit.com/r/MusicBrainz/comments/1pz5pps/rate_limit/)  
17. ListenBrainz, accessed January 29, 2026, [https://listenbrainz.org/](https://listenbrainz.org/)  
18. Metadata — ListenBrainz 0.1.0 documentation \- Read the Docs, accessed January 29, 2026, [https://listenbrainz.readthedocs.io/en/latest/users/api/metadata.html](https://listenbrainz.readthedocs.io/en/latest/users/api/metadata.html)  
19. ListenBrainz lookup for exact recording \- MetaBrainz Community Discourse, accessed January 29, 2026, [https://community.metabrainz.org/t/listenbrainz-lookup-for-exact-recording/724552](https://community.metabrainz.org/t/listenbrainz-lookup-for-exact-recording/724552)  
20. Client Credentials Flow \- Spotify for Developers, accessed January 29, 2026, [https://developer.spotify.com/documentation/web-api/tutorials/client-credentials-flow](https://developer.spotify.com/documentation/web-api/tutorials/client-credentials-flow)  
21. Rate Limits \- Spotify for Developers, accessed January 29, 2026, [https://developer.spotify.com/documentation/web-api/concepts/rate-limits](https://developer.spotify.com/documentation/web-api/concepts/rate-limits)  
22. Solved: Web API ratelimit \- The Spotify Community, accessed January 29, 2026, [https://community.spotify.com/t5/Spotify-for-Developers/Web-API-ratelimit/td-p/5330410](https://community.spotify.com/t5/Spotify-for-Developers/Web-API-ratelimit/td-p/5330410)  
23. Discogs Forum \- API Announcements, accessed January 29, 2026, [https://www.discogs.com/forum/thread/521520689469733cfcfd2089](https://www.discogs.com/forum/thread/521520689469733cfcfd2089)  
24. Current rate limits? \- Forum \- Discogs, accessed January 29, 2026, [https://www.discogs.com/forum/thread/997721](https://www.discogs.com/forum/thread/997721)  
25. Genius API, accessed January 29, 2026, [https://docs.genius.com/](https://docs.genius.com/)  
26. Free Music API Guide \- TheAudioDB.com, accessed January 29, 2026, [https://www.theaudiodb.com/api\_guide.php](https://www.theaudiodb.com/api_guide.php)  
27. API Terms of Service | Last.fm, accessed January 29, 2026, [https://www.last.fm/api/tos](https://www.last.fm/api/tos)  
28. API Docs | Last.fm, accessed January 29, 2026, [https://www.last.fm/api/intro](https://www.last.fm/api/intro)