JADE/Content schemas

From MediaWiki.org
Jump to navigation Jump to search

This page records a set of complete proposals for content schemas for use in JADE. Content schemas are JSON blobs that represent a set of judgments about an entity (E.g. a revision, a diff, a page, a user, etc.).

Judgements and endorsements[edit]

This represents an iteration of the original schema that Halfak put together in summer of 2017. The general rationale is that propositions (judgments) are endorsed in a pattern similar to "!votes", and that this pattern is captured in the data structure itself and thus is open to machine analysis. Users may provide a comment explaining their endorsement. Judgments can be further described with a set of notes (that may contain hashtags or links for the construction of a folksonomy and use in grounded theory). These snippets of wikitext will be stored as fields in JSON, as in Extension:CollaborationKit or as with plaintext in Wikidata.

This is different than "bucket of judgments", because there can only be one judgment for each data value, and the notes on that judgment are collaboratively authored.

Single judgment[edit]

This represents a highly simplified schema that collapsed everything down to a single judgment, with a field for each type of judgment. The idea is that straw polls and filing disagreement would happen via BRD and thus not be machine readable. This also removes the ability to explore who/where a judgement was provided from. By focusing on the consensus judgment directly, the system and interaction patterns can be kept much more simple and straightforward.

NThis schema is not under consideration.

Bucket of judgments[edit]

This represents an effort to directly support a wide variety of workflows, such as the "append-only" pipeline between systems like Wikilabels and JADE. The rationale is to drop the constraints of consensus patterns at a schema level so that any workflow can "just dump judgment" into JADE.

N This schema is not under consideration.

Freeform wikitext[edit]

This is schema-free, using Judgment pages as the platform, with the primary goal of facilitating open-ended editor collaboration. Templates and hashtags could be used to improve machine readability. Database indexes would be provided, making it easier to match Judgment pages with their target wiki entities.

N The Scoring Platform team has consensus to use a formal structure for at least some of the content.

Content page and JSON slot[edit]

In this schema, pages in the judgment namespace are written in wikitext, and carry a Multi-Content Revision slot with additional, structured judgment data. The wikitext Judgment and Judgment_talk namespaces can be used to produce a consensus opinion and discussion respectively, while the JSON is filled in with a machine-readable conclusion.

The motivation for a wikitext page is to provide the full range of rich, collaborative practices that editors are used to. We have concerns, however, that the redundancy between a central page and the structured endorsements and judgment notes fields will damage machine-readability and may cause confusion for editors. There is an alternative to move all the wikitext to a single content page, and use revision references and page history to approximately correlate specific opinions with text changes.

Editors can read and write to the content page and the JSON slot directly, or via editable components embedded in a special-purpose UI.

In progress We have consensus that MCR is currently a risk to this implementation's success, so don't anticipate using this schema in a pilot deployment.

Content page as JSON field[edit]

This is the "endorsements" schema combined with a "content page" of top-level notes, emulating the wikitext page using a field in JSON. The purpose of this top-level field is to provide a wide margin of rich, collaborative practices. We use a JSON field rather than a wikitext main slot as a compromise, to avoid the risks of MCR's technological bleeding-edge unknowns.

During experimentation we would be able to present the field's contents as if it were a page, or as its own input field, as the experiment requires.

There's no consensus about whether this might be an interesting schema to experiment with.