With the appearance of MCR [0] it is theoretically possible to store different content "slots" for the same title entity. Again, in theory it should be possible to register a special SMW fact slot type that would only be allowed to be used via an API to manipulate facts in a structured manner (preferable in the JSON format) hereby provide means to change or remove facts using a program without parsing wikitext elements.
From the beginning of Semantic MediaWiki it has been rather difficult to change facts via an API that are embedded or part of the wikitext (or templates) making an attempt to update those facts using a program (or API) rather error prone due to the need to parse and rewrite possible wikitext artifcats.
Separating user input from API input, allowing both to exists side by side without overriding each others input.
In case of contradictory facts (user edit says "[[Is bool::true]]" while the API edit says "[[Is bool::false]]") the user input takes precedence for the value representation of that specific fact statement.
Slots act as single independent entity of a referenced title therefore it would be possible to separate wikitext embedded facts from API embedded facts and merge them together into one coherent fact representation for a title during an update.
It has been nearly 5 years since the inception of the RFC [0] but I was unable to find any example that would explain how to use slots, how to write a slot via an API, how to show information from a slot to a user during an edit.
Given the lack of information about slots and how to interact with them, I'm at an impasse to provide a real insight or progress to extend SMW.
@cicalese @hexmode I would appreciate an effort from those involved to make "MCR" more accessible to extension developers including an actual example from top to down to see how the information flow (from input to the actual update) works.
[0] https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions
@mwjames, agreed it would be nice to have a simple example or set of examples for using MCR. Unfortunately, that does not exist yet.
One reason is that the MCR project is not yet complete. The storage layer is complete and in use in the MediaInfo extension, but rendering and editing interfaces are still only partially complete. However, from what you are talking about, it sounds like the existing storage layer functionality might be sufficient for you. It would indeed be good to have an example at least in the use of that part.
A while back, I was thinking of converting my Title Icon extension to use MCR, because it is relatively simple and could perhaps be such a simple example. I have yet to have the time to work on it, and I'm a bit stalled since it would need an editing interface for the information in the slot. However, when I began looking at it, I asked @brightbyte a series question the answers of which I will summarize below as they might point you in the correct direction. If there are any errors, they are mine in selecting and summarizing bits from our conversation.
Slots don't have to be created, and they don't "exist" on a page, only on revisions. Each revision can have multiple Content objects, and each one occupies a slot.
For defining a slot role, see how MediaInfo does it:
This should probably become easier in the future. We could use ObjectFactory to make it possible to define SlotRoleHandlers in extension.json or something.
If you do not want the contents of the slot to be rendered, when calling $registry>defineRoleWithModel(), you provide ['display' => 'none' ] as the layout hint. However, you still need a ContentHandler that can provide a rendering (ParserOutput).
To save a value as JSON in a slot, get a PageUpdater from WikiPage::newPageUpdater. First call setContent() on the PageUpdater, then saveRevision().
To have access to slot data during page rendering, any data needed should be placed into page_props by calling setProperty() on the ParserOutput during rendering. The ParserOutput of all slots gets merged into a single ParserOutput. All properties get collected together and placed into page_props.
I hope that helps.
If I understand the request correctly, this can be done with the tools already present. You can create auxilliary pages in your Project namespace, fill them with external data or data created by bots being subobjects, edit-protect those pages and make the semantic templates query those subobjects for default values of their parameters.
Most helpful comment
@mwjames, agreed it would be nice to have a simple example or set of examples for using MCR. Unfortunately, that does not exist yet.
One reason is that the MCR project is not yet complete. The storage layer is complete and in use in the MediaInfo extension, but rendering and editing interfaces are still only partially complete. However, from what you are talking about, it sounds like the existing storage layer functionality might be sufficient for you. It would indeed be good to have an example at least in the use of that part.
A while back, I was thinking of converting my Title Icon extension to use MCR, because it is relatively simple and could perhaps be such a simple example. I have yet to have the time to work on it, and I'm a bit stalled since it would need an editing interface for the information in the slot. However, when I began looking at it, I asked @brightbyte a series question the answers of which I will summarize below as they might point you in the correct direction. If there are any errors, they are mine in selecting and summarizing bits from our conversation.
Slots don't have to be created, and they don't "exist" on a page, only on revisions. Each revision can have multiple Content objects, and each one occupies a slot.
For defining a slot role, see how MediaInfo does it:
https://gerrit.wikimedia.org/g/mediawiki/extensions/WikibaseMediaInfo/+/ffc6214790eb19ffbfcc09a034c496ea466f00d3/src/WikibaseMediaInfoHooks.php#74
This should probably become easier in the future. We could use ObjectFactory to make it possible to define SlotRoleHandlers in extension.json or something.
If you do not want the contents of the slot to be rendered, when calling $registry>defineRoleWithModel(), you provide ['display' => 'none' ] as the layout hint. However, you still need a ContentHandler that can provide a rendering (ParserOutput).
To save a value as JSON in a slot, get a PageUpdater from WikiPage::newPageUpdater. First call setContent() on the PageUpdater, then saveRevision().
To have access to slot data during page rendering, any data needed should be placed into page_props by calling setProperty() on the ParserOutput during rendering. The ParserOutput of all slots gets merged into a single ParserOutput. All properties get collected together and placed into page_props.
I hope that helps.