Jump to content

User:GZWDer/JSONPageList

From mediawiki.org

To do

[edit]
  • 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

[edit]
  • Filter entries (complex)

Not to be done (for now)

[edit]
  • JavaScript-based edit interface

See also

[edit]
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.[1] 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[2] 100s[3][4][5] 100s[6] 800s
Community 145+ developers[7] 172+ developers[8] 63+ developers[9] 45
Storage MediaWiki database, Elasticsearch, 5 different SPARQL stores[10] MediaWiki database, Elasticsearch, SPARQL store (Blazegraph for wikidata.org) MediaWiki database (or a separate database)[11] 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.[12] 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[13] 17[14][15] 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[16] ~ 75[17] no native result display; data may be visualized via: ~ 25[18] no native result display yes but not in MVP one, but multiple via Visualizers
Development GitHub Gerrit Gerrit Gerrit
Complementary extensions 28[19] ~ 51[20], e.g. Semantic Result Formats , Semantic Bundle , Semantic Scribunto ~12[21], 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.[22]