If we're going to cram JADE into MediaWiki (in order to better support curation and suppression) I think it might make sense to plan to take advantage of the new work on Multi-Content Revisions. I've made an example of what I think MCR JADE stuff would look like. See JADE/MCR_example. What do you think?
Topic on Talk:JADE/Implementations
I like that we can separate Edit vs Revision judgments. It doesn't seem to solve any of our other dilemmas, unfortunately. There's only one slot per content type, per revision, so we're still looking at some weird denormalized set of judgments being crammed into a single content slot, AFAICT. It'll be challenging to do per-user suppression in that case, since suppressing a single judgment will probably require custom code to rewrite the set of judgments.
In my example, each content type gets a different slot and is transcluded onto one page. I was imagining that each specific judgement would gets its own slot.
I missed the transclusion aspect, thanks for pointing it out.
The way I'm reading Multi-Content Revisions/Content Meta-Data, there are a finite number of slots that are defined ahead of time, and each is named. On the other hand, I found this "maybe" feature which could be adapted to fit your scheme, Requests for comment/Multi-Content Revisions#Sub-slots. We'll have to ask @Duesentrieb or another MCR developer to clarify whether "sub-slots" will be supported, and if we can use a custom convention to enumerate sub-slots.
Given your read of the docs, does it seem that "defined ahead of time" means "adding slots is a pain" or "adding slots is impossible"?
This answers some of our questions: Multi-Content Revisions/Database Schema
There are finite, smallint number of, "slot roles", I'm sure we're allowed to define a few for our purposes, but we can't go around creating them dynamically. (revision, role) is the primary index, so we can't provide more than one content per slot.
I haven't found any answers about subslots, thinking they weren't implemented yet :-/
I think small N is how many slots we'll really need. E.g. we have "damaging", "goodfaith", and "edittype" for diffs and "wp10", "drafttopic", and "draftquality" for revisions.
Right, I'm pretty sure we can define finite slots for each type of score or whatever, but we can't store multiple judgments unless they're sharing these slots.
Right. I don't think storing multiple judgements makes sense in this context. Instead, we'd just have a history of "current judgement".
This MCR proposal is growing on me. Just to make some details of your MCR_example more explicit, to see if we agree:
- Each wiki entity (for now, revisions) may have a JADE namespace page which will contain the consensus judgment about that entity.
- The JADE namespace will have a custom content handler that pulls together MCR slots and renders as a single page.
- Each Jade: page has a dozen MCR slots available, one per ORES judgment schema.
- When updating a judgment, the author will sometimes be overwriting a score in an MCR slot. Any justification will be stored in the edit summary.
My concerns:
- Is MCR suppression going to be ready for prime-time, or will we be tied to something that makes editors unhappy?
- This makes it slightly awkward to have lots of judgment scoring schemas, e.g. maintaining both the old and new versions of a schema. IMO we should consider whether we can safely migrate scores to newer schemas, and only keep the latest schema in MediaWiki.