Wikidata is the free, open, collaborative knowledge base maintained by the Wikimedia Foundation. It serves as the structured data backbone for Wikipedia and other Wikimedia projects. This page analyses whether WikiDeal could use or integrate with Wikidata for its own data structures — contracts, user groups, service categories, and more. WM-01

1. What is Wikidata?

Wikidata (wikidata.org) is a free, open, secondary database containing structured data — entities, properties, and statements — that can be queried by anyone. Key facts:

• Maintained by the Wikimedia Foundation since 2012.
• Contains over 100 million items as of 2025.
• Multilingual by design — each item has labels in dozens of languages.
• Queryable via SPARQL (Wikidata Query Service).
• All data released under CC0 (public domain).
• API available for reading and writing data.

2. Advantages of Using Wikidata

• ✅ Linked data: Wikidata entities are interlinked with Wikipedia, OpenStreetMap, and hundreds of other datasets — enabling rich, contextual data for WikiDeal service categories, organizations, and locations.
• ✅ Multilingual: All data is natively multilingual. WikiDeal operates in FR, EN, DE, IT, ES — Wikidata supports all of these.
• ✅ Existing Infrastructure: No need to build and maintain a knowledge base from scratch. Wikidata already has millions of items relevant to WikiDeal (organizations, cities, service types, legal frameworks).
• ✅ Community maintained: Thousands of volunteers continuously update and verify Wikidata. WikiDeal benefits from this shared maintenance.
• ✅ CC0 licence: Public domain data can be integrated into WikiDeal without licence conflicts (though WikiDeal's own data would remain AGPL v3).
• ✅ SPARQL queries: Complex data relationships (e.g., "all NGOs active in Geneva, categorized by theme") can be queried directly.
• ✅ Alignment with mission: Using Wikidata is consistent with WikiDeal's open-knowledge philosophy and Wikimedia references (WM-01, WM-09, WM-10).

3. Disadvantages and Risks

• ⚠️ Governance complexity: Wikidata has its own governance model, policies, and community norms. WikiDeal cannot unilaterally control or modify Wikidata content — changes must go through Wikidata's community process.
• ⚠️ Dependency risk: If WikiDeal relies heavily on Wikidata, any change to Wikidata's API, data model, or availability could disrupt WikiDeal's operations.
• ⚠️ Data sovereignty concerns: Personal data (user profiles, contract terms, sensitive community information) cannot be stored in Wikidata — it is a public database. WikiDeal must maintain its own private data layer.
• ⚠️ Vandalism risk: Wikidata items can be edited by anyone. Critical WikiDeal reference data could be vandalized or incorrectly modified.
• ⚠️ Latency and availability: Real-time applications (e.g., live session tracking for street fundraising) cannot depend on an external API with variable latency.
• ⚠️ Schema mismatch: Wikidata's general-purpose schema may not fit WikiDeal's specific contract and marketplace data structures.
• ⚠️ Write limitations: Creating new Wikidata items for every WikiDeal service or contract is impractical and contrary to Wikidata's notability guidelines.

4. Comparison Table

5. Proposed Conclusion

Hybrid approach proposed:

1. Wikidata for reference data: Use Wikidata Q-items to identify organizations (NGOs, associations), geographic entities (cities, regions), service categories, and legal frameworks. Link WikiDeal items to Wikidata IDs where available.
2. WikiDeal own database for operational data: All contract data, user profiles, Credits (WDC), session logs, and community governance data remain in WikiDeal's own AGPL v3 database.
3. Wikidata contribution: Where WikiDeal creates new knowledge (e.g., new service categories, new contract types), contribute back to Wikidata following their notability and community guidelines.

This approach maximizes the benefits of linked data and multilingual support while maintaining data sovereignty and real-time performance. It is consistent with WikiDeal's libre licensed philosophy without creating undue external dependency.

6. References