Information Architecture and Semantic Graph Schema for BuiltToResist: An Encyclopedia of Revolution and Resistance

Full report

On this page

1. Architectural Vision and Epistemological Framework

The design of a comprehensive, scalable encyclopedia covering the complexities of human resistance requires a fundamental departure from traditional flat-file architectures, relational databases, and rigid hierarchical wikis. Historical knowledge, particularly concerning revolutions, uprisings, and asymmetrical conflicts, is inherently interconnected, deeply contested, and multi-dimensional. To support an ecosystem expected to scale beyond 10,000 pages—handling intricate socio-political dynamics, conflicting historiographical narratives, and high-resolution empirical data—the information architecture of the BuiltToResist encyclopedia must be grounded in a semantic knowledge graph.

By leveraging property graph models alongside Resource Description Framework extensions such as RDF-star and upper ontologies like the International Committee for Documentation Conceptual Reference Model (CIDOC-CRM), this architecture can model not merely the static facts of a revolution, but the provenance, confidence levels, and varying perspectives surrounding those facts1. This framework ensures that the encyclopedia serves both as an accessible public repository and a rigorous digital humanities research environment. The semantic graph approach dissolves the traditional barrier between macroscopic structural analysis and microscopic individual detail, enabling researchers to traverse seamlessly from high-level ideological movements down to specific tactical mechanisms and primary source documents3. This report details a highly structured, machine- and human-readable information architecture covering a 24-category taxonomy, canonical relationships, advanced URL structures, structured data optimization, and agentic indexing protocols tailored for Large Language Models (LLMs).

2. The Core Taxonomy and Ontological Categorization

To organize the twenty-four mandated knowledge domains into a coherent, scalable schema, they must be rigorously classified into an upper ontology that distinguishes between first-class entities (Nodes/Pages), metadata and attributes (Tags/Properties), and structural connectors (Edges/Relationships). Mapping these concepts to established ontologies, such as CIDOC-CRM for cultural heritage and events, alongside Wikidata property alignments, ensures maximum semantic interoperability across the broader Linked Open Data web4.

The CIDOC-CRM ontology is specifically intended to cover contextual information, mapping the historical, geographical, and theoretical backgrounds that give cultural heritage data its meaning6. Applying this to the domain of revolution requires adapting general event and actor classes to specific socio-political phenomena.

3. The Ontological Threshold: Distinguishing Pages from Tags

A critical architectural decision for any large-scale knowledge repository is determining which concepts deserve dedicated, uniquely addressable pages (Uniform Resource Identifiers, or URIs) and which should remain metadata tags utilized solely for classification. Mismanagement of this threshold inevitably leads to a phenomenon known as taxonomy explosion, where unrestricted folksonomies and overlapping definitions dilute search relevance, fracture the knowledge graph, and overwhelm the context windows of indexing agents7.

A concept warrants a dedicated page if it possesses distinct biographical, historical, or theoretical depth, or if it acts as a primary subject or object within a canonical graph relationship. Entities such as a specific revolution, a named leader, or a distinct ideology must exist as first-class nodes. Furthermore, operational mechanisms defined by rigorous empirical research—such as peace scholar Gene Sharp's catalog of 198 methods of nonviolent action—require dedicated pages10. Sharp's classifications, which divide nonviolent action into broad categories of protest and persuasion, social/economic/political noncooperation, and nonviolent intervention, carry immense theoretical weight and historical precedent10. A tactical mechanism like "Lysistratic nonaction" or "Satyagrahic fast" demands a full page to explain its origin, historical application, and theoretical logic, complete with links to the cases where it was deployed11.

Conversely, tags must be restricted to attributes used primarily for filtering, faceted search, and categorical bounding. Concepts describing generalized states, such as "Violent," "Non-violent," "High-participation," "19th-century," or "Maximalist-goal," are second-class entities14. Tags do not possess standalone narrative content but act as the connective tissue enabling multi-dimensional filtering across the graph. If a user wishes to find all nonviolent campaigns targeting military regimes in the 20th century, the tags facilitate this intersectional query. Elevating such adjectives to full pages creates content-thin nodes that degrade the user experience and confuse semantic search algorithms.

4. Taxonomy Governance and the Prevention of Folksonomic Explosion

To prevent tag explosion—a scenario where user-generated or uncurated folksonomies create thousands of redundant, misspelled, or semantically overlapping tags—the architecture must enforce a highly structured controlled vocabulary governed by international metadata standards7. The system will not allow arbitrary tag creation by editors; instead, all metadata will be managed through an ontology management interface.

BuiltToResist will utilize the Simple Knowledge Organization System (SKOS) data model, strictly aligned with the ISO 25964 standard for information retrieval thesauri and interoperability17. ISO 25964 dictates stringent design rules for controlled vocabularies: concept labels must be unique, relationships cannot be circular, and multi-language equivalence must be maintained18. SKOS translates these archival principles into web-native, machine-readable formats using XML/RDF20.

The SKOS framework maps the encyclopedia's concepts using precise hierarchical and associative properties. The skos:prefLabel establishes the canonical, preferred name for a concept, ensuring uniformity across the database. To accommodate natural variations in language and search behavior, skos:altLabel captures synonyms or alternative spellings; for instance, a search for "walkout" will automatically resolve to the preferred label "Strike"17. Hierarchical depth is managed through skos:broader and skos:narrower relationships, which map concepts to wider parent categories or specific child categories, respectively21. Under this model, "Strike" holds a skos:broader relationship to "Economic Noncooperation," while holding a skos:narrower relationship to "Wildcat Strike"13. Finally, skos:related connects associative but non-hierarchical concepts, acknowledging the nuanced realities of political resistance without breaking the strict parent-child taxonomy18. By enforcing this SKOS architecture, if an editor attempts to tag a new case study with an unapproved term, the semantic engine will automatically map the input to the correct skos:prefLabel or demand the formal creation of a new concept within the ISO 25964 hierarchy, thereby preserving the integrity of the knowledge graph over decades of expansion.

5. Graph Database Schema and Canonical Relationships

Traditional relational databases require complex, computationally expensive joins to traverse historical connections, often failing to capture the multi-directional influence of actors, ideas, and events. A property graph database natively stores relationships as distinct edges, allowing for multi-hop traversals in milliseconds22. This architecture is vital for analyzing the ripple effects of uprisings, tracing ideological lineages, and mapping the intricate webs of human resistance.

The graph schema defines exactly how entities are permitted to connect, ensuring that every relationship is directional and semantically precise. Leveraging standard Wikidata properties ensures the encyclopedia remains interoperable with the broader Semantic Web, allowing external digital humanities platforms to query BuiltToResist seamlessly5. The architecture enforces a strict set of canonical relationships to model historical dynamics accurately.

5.1 Enforced Canonical Relationships

The following relationships represent the structural backbone of the encyclopedia's knowledge graph. Each edge is heavily typed and directional, meaning the flow of historical action or logical dependency is explicitly modeled22.

This canonical design facilitates complex inquiry resolution. The mandated structure Question → answer → deep analysis → sources transforms the encyclopedia from a passive repository into an active epistemological tool. A Question node (e.g., "Why do nonviolent campaigns succeed against military juntas?") points via a directed edge to a concise Answer node. This answer, recognizing the brevity required for immediate comprehension, is structurally dependent on a Deep analysis node that explores the nuances of tactical defection and regime fragility. This deep analysis node is then comprehensively linked via CITED\_WORKS edges to the respective Scholars, Books, and Research reports, ensuring complete traceability of the intellectual argument.

6. Encoding Empirical Variables and Historical Uncertainty

To elevate the encyclopedia from a standard qualitative wiki to a rigorous empirical research tool, the graph schema will natively integrate structured variables from established political science datasets. Prominently, this includes the Nonviolent and Violent Campaigns and Outcomes (NAVCO) dataset, which brings together hundreds of cases of maximalist resistance campaigns aimed at regime change, anti-apartheid social change, and the expulsion of foreign occupations14.

When a Movement or Revolution node is instantiated, its properties will include structured key-value pairs mirroring the NAVCO codebooks. This includes tracking distinct conflict objectives, such as territorial self-governance, secession, or institutional demands26. Social composition variables will capture the granular involvement of diverse demographics, distinguishing between agrarian elites, industrial workers, students, and defecting regime security forces, while noting whether these groups merely participated in, initiated, or entirely dominated the movement27. The schema will also ingest temporal data, mapping conflict duration via precise start and end dates to facilitate automated timeline generation26. Crucially, outcome variables are stored as discrete, queryable states (e.g., full success, limited success, failure), allowing users to execute complex searches, such as identifying all maximalist nonviolent campaigns targeting autocracies that achieved full success within a specific historical era26.

6.1 RDF-star and the Preservation of Historiographical Debate

Historical data is rarely absolute; it is characterized by ambiguity, conflicting primary sources, and shifting scholarly consensus. One historian may argue that a specific uprising succeeded primarily due to mass nonviolent persuasion, while another scholar, analyzing the exact same event, might emphasize the implicit threat of an armed radical flank. To accommodate this fundamental reality of the humanities, the graph schema will utilize RDF-star (RDF\*) functionality, which allows the database to make "statements about statements" through the use of edge properties1.

Rather than forcing the database to assert a single, rigid truth—which violates the epistemological principles of historical study—RDF-star permits the relationship edge itself to possess complex attributes, thereby preserving contextual validity and provenance1. If the graph states that a specific movement achieved success, that relationship edge will be annotated with the scholarly source asserting the claim, the confidence level of the assertion, and the underlying theoretical methodology used to reach that conclusion. This multi-dimensional approach prevents the encyclopedia from flattening history, instead allowing human researchers and AI agents to explore historiographical debates by querying the provenance of conflicting claims directly within the graph architecture2.

7. URL Structure, Persistent Identifiers, and Breadcrumbs

The routing architecture of the encyclopedia must be highly predictable, hierarchically sound, and optimized for both human readability and algorithmic web crawlers. A flat URL structure causes severe context loss, while excessively deep semantic nesting breaks under the weight of multi-faceted historical topics that belong to several categories simultaneously.

Every node in the graph database will be assigned a universally unique identifier (UUID) under the hood. This ensures absolute graph stability; if the preferred label of a historical movement changes due to shifting academic consensus, the underlying entity ID remains immutable, preventing broken relationships. However, public-facing URLs will rely on semantic slugs combined with high-level category prefixes to ensure readability and Search Engine Optimization (SEO).

The standard format will follow https://builttoresist.org/\[category-prefix\]/\[entity-slug\]. This results in clean, descriptive paths such as /revolutions/french-revolution, /mechanisms/general-strike, and /ideologies/anarcho-syndicalism.

7.1 Dynamic SKOS-Driven Breadcrumb Navigation

Breadcrumb navigation is frequently implemented poorly, mapping the literal click-path the user took to arrive at a page, which creates duplicate indexing paths and confuses users entering from external search engines. Instead, BuiltToResist will generate breadcrumbs dynamically by querying the ontological hierarchy defined by the SKOS relationships20.

For example, navigating to the page for "Wildcat Strike" will trigger a real-time graph query traversing the skos:broader relationships upwards to the top concept. The resulting breadcrumb—Home \> Mechanisms \> Noncooperation \> Economic Noncooperation \> Strikes \> Wildcat Strike—strictly follows Gene Sharp's established classification structure, implicitly educating the user on the broader conceptual framework of nonviolent action simply through interface design10. In cases where entities belong to multiple distinct hierarchies, the system will designate a single canonical primary path for indexing purposes, while allowing the frontend application to render context-aware breadcrumbs via specific GraphQL queries depending on the user's active faceted search parameters28.

8. Human Navigation and Graph-Driven Discovery

Discoverability is the primary function of an encyclopedia. Relying solely on manual inline hyperlinking is grossly insufficient for a platform scaling to 10,000+ pages, as it inevitably creates orphaned pages and limits serendipitous discovery. The architecture will employ dynamic, algorithmically driven recommendation rules utilizing Cypher graph traversal queries22.

Faceted navigation will allow users to filter vast arrays of nodes using the SKOS-controlled metadata tags, offering relational navigation that empowers digital humanities research16. A user viewing the global directory of "Uprisings" can instantly filter the view to display only events occurring in the 20th Century, utilizing nonviolent intervention mechanisms, targeting military dictatorships, and resulting in limited success.

Beyond faceted search, the sidebar of every article will feature dynamically populated related content based on graph proximity, effectively turning every page into a research hub22. The recommendation logic relies on layered Cypher traversals. First, the system retrieves direct 1-hop edges, showing entities directly connected to the current node (e.g., displaying all books authored by a specific scholar). Second, the algorithm retrieves 2-hop shared attributes, recommending entities that share significant edges. If a user is reading about the Salt March, the query will identify the specific mechanisms utilized, and return a list of other historical cases that employed identical tactics of civil disobedience. Finally, through the use of sub-symbolic graph embeddings, the system can recommend pages that share identical empirical NAVCO variables—such as matching participant demographics and regime targets—even if the historical events occurred in entirely different centuries and continents30.

9. Structured Data Optimization and Semantic SEO

To ensure the encyclopedia interfaces seamlessly with external search engines, academic aggregators, and knowledge graph panels (such as Google Knowledge Graph), all pages will automatically inject JSON-LD (JavaScript Object Notation for Linked Data) structured data into the HTML header32. JSON-LD provides a method of encoding Linked Data using JSON, allowing external systems to understand the exact nature of the content without relying on natural language processing of the text body.

Using established vocabularies from Schema.org, the unstructured narrative text of the encyclopedia is translated into precise, machine-readable objects33.

• Historical Events: Nodes classified as Revolutions, Uprisings, or Cases will be mapped to Schema.org/Event (or specialized extensions like HistoricalEvent), mandating fields such as name, startDate, endDate, location, description, and participating actor35.
• Actors and Groups: Leaders and Scholars map to Schema.org/Person, while Movements, Organizations, and Institutions map to Schema.org/Organization.
• Literature and Sources: Books, Primary sources, and Research reports map to Schema.org/Book or Schema.org/CreativeWork.
• Concepts: Ideologies, Legal doctrines, and Mechanisms map to Schema.org/DefinedTerm, deeply linked back to the SKOS taxonomy URIs.

By rigorously structuring the data, BuiltToResist will trigger rich search results, interactive event carousels, and authoritative knowledge panels in standard search engine results pages, drastically increasing public discoverability and establishing the platform as the definitive semantic authority on political resistance38.

10. Agent-Readable Indexes and LLM Integration

As Large Language Models and autonomous AI agents increasingly dominate information retrieval and synthesis, digital platforms must provide optimized, context-dense pathways for machine ingestion. Crawling traditional HTML is highly inefficient for AI; it consumes excessive tokens, is slowed by styling and scripts, and is highly prone to hallucinations caused by parsing navigation menus and boilerplate text39. To support the next generation of digital research, BuiltToResist will implement the proposed llms.txt standard and its associated shadow corpora natively39.

10.1 The llms.txt Curated Map

Located at the absolute root directory of the domain, the llms.txt file acts as a heavily curated, machine-readable index tailored specifically for AI assistants39. This markdown file provides the agent with the site's core purpose and a hierarchical map of the most vital gateway pages and structural schemas, allowing the agent to decide exactly what information it needs to fetch to satisfy a user's prompt40.

The file opens with an H1 title and a concise blockquote summary that an LLM can quote verbatim, explicitly stating the integration of NAVCO variables and Gene Sharp's frameworks. Following this, H2 sections categorize clean markdown links to the most critical hub pages39. The URL structure for these links will automatically append a .md extension. The server architecture will dynamically intercept these specific requests and return a clean, unstyled Markdown version of the requested page, stripped of all HTML overhead. This strategy preserves semantic meaning (headers, lists, data tables) while reducing token usage by up to 95%, ensuring the encyclopedia remains highly performant during LLM ingestion43.

10.2 The llms-full.txt Ingestion Corpus

For specialized agents seeking to ingest the entire theoretical framework of the encyclopedia in a single pass—such as a researcher fine-tuning a model on resistance mechanisms—the system will auto-generate an llms-full.txt file40. This file concatenates the raw markdown bodies of the core analytical and theoretical pages into a single, massive text document, separated by distinct logical delimiters. This enables an AI agent to execute Retrieval-Augmented Generation (RAG) against the entire knowledge base via a single synchronous fetch, completely bypassing the latency and complexity of recursive web crawling41. To maintain this massive index efficiently, backend scripts will utilize state persistence (e.g., maintaining a crawl\_state.json file) to only parse and append newly updated nodes during nightly builds, while quality gates will automatically reject any pages returning errors or lacking substantial meta-descriptions44.

11. Entity Resolution in Historical Archives

A persistent and debilitating challenge in archival research and the digital humanities is entity resolution—the complex process of determining whether two ambiguous references in disparate sources refer to the exact same historical figure or event3. Without rigorous entity resolution, the knowledge graph will inevitably fracture, creating isolated, disconnected nodes that ruin the accuracy of statistical queries.

To manage a dataset scaling to tens of thousands of historical actors and events, BuiltToResist will implement a hybrid entity resolution pipeline that combines machine learning with deterministic logic. First, the system utilizes sub-symbolic graph embeddings to encode the broader graph context of ambiguous entities into a multi-dimensional vector space. If two differently named entities share a highly similar relational context—for instance, both are linked to the exact same location, the same revolution, and the identical set of ideological tags—the algorithm flags them as highly probable duplicates30.

However, vector similarity is insufficient for rigorous historical data, which possesses hard temporal and physical constraints. Therefore, the system will apply domain-specific rational axioms to block false algorithmic merges. An axiom coded into the graph engine might state that a person with a verified death date of year [Figure omitted from source export] cannot possibly be the initiator of an event occurring in year [Figure omitted from source export], where [Figure omitted from source export]30. High-confidence matches that clear all rational axioms are merged automatically by the graph engine, while edge-cases and contested identities are surfaced to a dashboard for manual review by human historians, ensuring the integrity of the data model.

12. Minimum Viable Schema (MVS) for Rapid Scaling

To launch the encyclopedia effectively and avoid the paralysis of over-engineering an empty database, the architecture will deploy a Minimum Viable Schema (MVS) that is structurally robust enough to support 10,000+ pages, yet streamlined enough for immediate data entry.

The MVS blueprint focuses on establishing the absolute foundational graph mechanics. The system will initially deploy only the top-level 24 categories as primary Node Types, resisting the urge to hardcode granular subclasses. For example, the system will instantiate an Institution node type, but will not hardcode specific node variants like Military\_Institution or Financial\_Institution into the base schema; that level of detail will be handled entirely by the SKOS metadata tags. The 12 canonical relationships defined previously will be deployed as the exclusive allowable edges, forcing early editors to conform to the standardized ontological logic.

All tagging operations will be strictly governed by the ISO 25964-compliant SKOS framework17. Any new tag requested by an author must be mapped to an existing skos:broader parent concept before it can be committed to the database, ensuring the taxonomy remains perfectly hierarchical from day one21. Finally, the entire graph database will be wrapped in a GraphQL API layer, augmented by OpenAPI 3.1 schema definitions for maximum interoperability45. GraphQL’s strict schema typing allows the frontend application to request precisely the data required for a given view—fetching a movement, its leader, its applied mechanisms, and its outcome in a single query—solving the severe under-fetching and over-fetching issues that plague standard REST architectures in complex graph environments28.

By rigorously defining the boundaries between nodes, edges, and attributes, and by enforcing uncompromising semantic standards across the technology stack, the information architecture of BuiltToResist guarantees its evolution from a mere digital catalog into an interconnected, machine-readable intelligence platform, uniquely capable of uncovering the latent systemic dynamics of global resistance.

Works cited

1. The Semantic Units Framework, a technology-agnostic ... \- PMC \- NIH, https://pmc.ncbi.nlm.nih.gov/articles/PMC13294353/

2. (PDF) Preserving contextual information in cultural heritage, https://www.researchgate.net/publication/414123719\_Preserving\_contextual\_information\_in\_cultural\_heritage\_metadata\_through\_multidimensional\_knowledge\_graphs

3. Fine-Tuning the Historian's Macroscope: Data Reuse and Medieval, https://culturalanalytics.org/article/id/1027/

4. Classes & Properties Declarations of CIDOC-CRM version: 7.0.1, https://cidoc-crm.org/html/cidoc\_crm\_v7.0.1.html

5. MediaWiki:Wikibase-SortedProperties \- Wikidata, https://www.wikidata.org/wiki/MediaWiki:Wikibase-SortedProperties

6. Version 7.1.3 \- CIDOC CRM, https://cidoc-crm.org/sites/default/files/Documents/cidoc\_crm\_version\_7.1.3.html

7. DeepTagRec: A Content-cum-User Based Tag Recommendation, https://www.researchgate.net/publication/332255273\_DeepTagRec\_A\_Content-cum-User\_Based\_Tag\_Recommendation\_Framework\_for\_Stack\_Overflow

8. What are the best practices for building a VoC tagging taxonomy for, https://userhero.io/knowledge/what\_are\_the\_best\_practices\_for\_building\_a\_voc\_tagging\_taxonomy\_for\_b2b\_product\_and\_support\_teams.php

9. Enriching the library subject headings with folksonomy | Request PDF, https://www.researchgate.net/publication/340205812\_Enriching\_the\_library\_subject\_headings\_with\_folksonomy

10. Forms of nonviolent action \- War Resisters' International, https://nonviolence.wri-irg.org/en/node/40521

11. Browse Methods | Global Nonviolent Action Database, https://nvdatabase.swarthmore.edu/browse-methods

12. 198 Methods of Nonviolent Action, https://www.gk-mirror.org/posts/downloads/1OHiJaZj5TiQQwzt8I9zqHTtkiq6TN5Wo8MVdbQ6ayW4.pdf

13. 198 Methods of Nonviolent Action by Gene Sharp \- Commons Library, https://commonslibrary.org/198-methods-of-nonviolent-action/

14. NAVCO 1.3 Codebook List | PDF | Nonviolence | Violence \- Scribd, https://www.scribd.com/document/999694063/NAVCO-1-3-Codebook-List

15. Group Size and the Use of Violence by Resistance Campaigns, https://www.emerald.com/books/edited-volume/13514/chapter/84159682/Group-Size-and-the-Use-of-Violence-by-Resistance

16. International Max Planck Research School for Computer Science, https://www.imprs-cs.de/files/2017/08/imprs\_yearbook\_2014-15.pdf

17. Best practices for structuring a thesaurus \- Opentheso, https://opentheso.hypotheses.org/2776

18. ISO 25964 \- Wikipedia, https://en.wikipedia.org/wiki/ISO\_25964

19. Thesaurus Standards for Taxonomies, https://taxonomystrategies.com/thesaurus-standards-for-taxonomies/

20. Using formal thesauri and controlled vocabulary as the interface, https://www.nist.gov/document/using-formal-thesauri-and-controlled-vocabulary-interface-between-unstructured-data-and

21. Introduction \- \- Docs \- KurrawongAI, https://docs.kurrawong.ai/concepts/vocabs/introduction/

22. Practical Graph Database Schema Design: Modeling Connections, https://www.tigergraph.com/blog/practical-graph-database-schema-design-modeling-connections-for-speed-and-clarity/

23. A System for Query, Analysis, and Visualization of Graph Databases, https://arxiv.org/html/2607.12845

24. instance of \- Wikidata, https://www.wikidata.org/wiki/Property:P31

25. Days of rage: Introducing the NAVCO 3.0 dataset \- ResearchGate, https://www.researchgate.net/publication/324619520\_Days\_of\_rage\_Introducing\_the\_NAVCO\_30\_dataset

26. Codebook Community and Consent, https://www.uu.se/download/18.d19bf0418f0a087d96cd8/1713874746766/c\_656156-l\_1-k\_090118\_community\_and\_consent\_codebook.pdf

27. Mass Mobilization in the Modern Era: Introducing the Opposition, https://pmc.ncbi.nlm.nih.gov/articles/PMC13427092/

28. GraphQL for archival metadata: An overview of the EHRI GraphQL API, https://www.researchgate.net/publication/322514975\_GraphQL\_for\_archival\_metadata\_An\_overview\_of\_the\_EHRI\_GraphQL\_API

29. Catalogue 2.0 : The future of the library catalogue 9781783300259, https://dokumen.pub/catalogue-20-the-future-of-the-library-catalogue-9781783300259-9781856047166.html

30. Utrecht University Repository \- UU Research Portal, https://research-portal.uu.nl/ws/files/134761380/SSW\_55\_SSW220012.pdf

31. Utrecht University Repository \- UU Research Portal, https://research-portal.uu.nl/files/134761380/SSW\_55\_SSW220012.pdf

32. JSON-LD Working Group Charter \- W3C, https://www.w3.org/2026/01/json-ld-wg-charter.html

33. Event Schema Markup for WordPress, https://blog.tickera.com/event-schema-markup-wordpress/

34. Organization of Schemas, https://schema.org/docs/schemas.html

35. Event \- Schema.org Type, https://schema.org/Event

36. What is Event Schema Markup & How to implement \- Infidigit, https://www.infidigit.com/blog/what-is-event-schema/

37. What is an Event Schema Markup? Functionality and SEO Implications, https://sitechecker.pro/what-is-event-schema-markup/

38. Event Schema (JSON-LD): Fields, Example & Recurring Events, https://www.greadme.com/blog/schemas/what-is-event-schema-complete-guide

39. The llms.txt Guide for 2026: What It Is, What It Isn't, and When to Bother, https://www.openhermit.com/blog/llms-txt-guide

40. llms.txt: A Practical Implementation Guide \- CDP.com, https://cdp.com/articles/llms-txt-guide/

41. What Is llms.txt? How to Create an LLM-Readable Site File (2026, https://www.shadow.inc/resources/what-is-llms-txt

42. llms.txt Explained: The Spec, Real Adoption, and 2026 Data, https://macmdviewer.com/blog/llms-txt-guide

43. llms-txt/nbs/index.qmd at main \- GitHub, https://github.com/AnswerDotAI/llms-txt/blob/main/nbs/index.qmd

44. LLMs.txt Generator | Technical Documentation, https://c3.unu.edu/projects/ai/seo/llmstxt.html

45. SEDIA: A Platform for Semantically Enriched IoT Data Integration, https://www.mdpi.com/1999-5903/15/8/276

46. OPENAPI NAMING AND DESIGN RULES TECHNICAL ... \- UNECE, https://unece.org/sites/default/files/2023-07/API-TECH-SPEC\_OpenAPI\_NDR\_version1p0.pdf

47. A Cross-Provider Analysis, Unified API, and Reference Prototype, https://arxiv.org/html/2608.08272v1