User:GZWDer/JSONPageList

To do

• Filter statements
• I18n support (partial)
• Custom template display
• JSON display (machine readable format)
• Projection (importing entries from external page + joining)
• Basic WDQS fact check
• Template/Module populated field
• Derived field

Wishlist

• Filter entries (complex)

Not to be done (for now)

• JavaScript-based edit interface

See also

Feature	Semantic MediaWiki	Wikibase	Cargo	JsonConfig(specifically Tabular Data)	JSONPageList	Structured infobox
Main usecase	Managing data within a MediaWiki installation, based on Semantic Web standards.	Powering Wikidata.	Managing data within a MediaWiki installation.	store JSON (including tabular and map data) in wiki pages, and allow accessing them via Lua	Allow users to store JSON-based page lists in (both local and Commons) data namespace	Managing machine-readable infobox data
Approach	Data (properties) are annotated within regular wikitext or by templates. With the datatype "reference", properties can be used to describe items using statements.	Properties are defined and used to describe Items using statements.	Data is stored in database tables, with each table corresponding to a template.	Data is stored in a Data namespace	Same as JsonConfig	Phase 1: data are annotated within regular wikitext Phase 2: data are stored in a specific slot of each page
Available since	2005	2012	2015	2013	proposed	proposed
Active installations	1000s	100s	100s	800s
Community	145+ developers	172+ developers	63+ developers	45
Storage	MediaWiki database, Elasticsearch, 5 different SPARQL stores	MediaWiki database, Elasticsearch, SPARQL store (Blazegraph for wikidata.org)	MediaWiki database (or a separate database)	MediaWiki database	For now: MediaWiki database Long term: possible embeded SQLite-like database	MediaWiki database
Property definition	By typing wikitext. Properties can be invented freely. They will be of datatype page by default and can be defined later. Datatypes can be changed any time.	Properties have to be defined before usage and can not be changed easily.	Instead of using properties, data tables are defined with a predetermined (but reconfigurable) set of fields per table.	Data tables are defined with a predetermined (but reconfigurable) set of fields per table.	Same as JsonConfig	Phase 1 and 2: Properties can be invented freely Phase 3 and 4: We need to store property metadata somehow
Value declaration	Inline ([[MyProperty::MyValue]]) or with templates. Form-based data entry with Page Forms .	Wikibase default form-like input interface.	With parser functions in templates. Form-based data entry with Page Forms .	Via the data namespace page	(1) Via the data namespace page (2) Populated from Wikidata (3) Populated via specific template or module (4) Derived from other fields (5) Calculated from some Wikifunctions function	Phase 1: Inline (with parser functions in templates) Phase 2: Form-like input interface
Predefined data types	18	17	18	4 (string, number, boolean, localized)		at least 2 (wikitext, number)
Property management	type definitions, constraint schemas, ontology import	custom, or import of Wikidata ontology	Instead of using properties, data tables are defined with a predetermined (but reconfigurable) set of fields per table.	Instead of using properties, data tables are defined with a predetermined (but reconfigurable) set of fields per table.	Same as JsonConfig	Phase 1 and 2: No property metadata Phase 3 and 4: ...
Page names and internal linking	Pages have normal names and can be linked to with their names.	Page names are stored with their Q-numbers (displaying labels in available languages). Internal linking must be done to the Q-number; you cannot link to a label.	Pages have normal names and can be linked to with their names.	All data are stored in one page in Data namespace with arbitrary name (For now, only commons has tabular data enabled)	Same as JsonConfig, but in all wikis	Pages have normal names and can be linked to with their names. However one page can define multiple entities
Inline queries	yes, with parser functions	no (external SPARQL queries); planned supported via third-party extension LinkedWiki	yes, with parser functions	For now can only query via w:Template:Tabular_query (see also phab:T181319)	Same as JsonConfig, but will be a built-in feature; In long term there may be SQL-like query supported	proposed in Phase 3
External querying	yes, with either an API or SPARQL querying (available through special extensions such as RDFIO and LinkedWiki)	yes, with SPARQL Query service	yes, with an API	no except by parsing tabular query template	yes but not required in MVP	yes but not required in MVP
Result formats	~ 75	no native result display; data may be visualized via: Query Service or other external tools on wiki data access via LUA (no query support) Extension:Graph Extension:LinkedWiki - third-party	~ 25	no native result display	yes but not in MVP	one, but multiple via Visualizers
Development	GitHub	Gerrit	Gerrit	Gerrit
Complementary extensions	28 ~ 51, e.g. Semantic Result Formats , Semantic Bundle , Semantic Scribunto	~12, e.g. Wikibase Client , WikibaseLexeme , Query Service	2 (Page Forms, Page Schemas). Cargo provides some or all of the functionality of Semantic MediaWiki, Semantic Result Formats, Maps, Semantic Drilldown, Semantic Compound Queries, Semantic Internal Objects and Semantic Scribunto.