As a maintainer of wdqs I want to workaround T266999 so that I can properly detect what changed on entity between two revisions instead of relying on the notion of //current// state.
Some triples in the RDF output like page properties may not depend entirely on the data stored in the entity revision.
This cause the issue that it is impossible to reconstruct the RDF output of an entity for a particular revision.
To workaround these issue the munger could generate these values on the fly instead of relying on the ones stored in the page properties (`\Wikibase\Repo\Content\EntityContent::applyEntityPageProperties`):
- Items:
- statements should be easy as it is the number of statement and can easily be counted reading the RDF output
- sitelinks is similar at it solely depends on the data of the entity itself
- identifiers: is more delicate as it depends on the type of the properties being used
- Properties
- statements
- Lexemes:
- statements
- senses: can be inferred from the entity content (not generated currently)
- forms: can be inferred from the entity content (not generated currently)
Overall most of these values can be inferred directly from the entity content at munge time.
Sole exception is the number of //identifiers// which requires the knowledge of which entity has a `wikibase:propertyType` equal to `wikibase:ExternalId` (https://w.wiki/jnk).
Currently 5451 properties are identified as such and it should be possible to deploy small dataset within the deploy repo containing such information so that the munger can properly infer the number of identifiers at munge time.
To make it stable this dataset will be //append only// and the date of generation will be matched against the modification data of the entity being munged.
AC:
- triples `wikibase:statements`, `wikibase:sitelinks` and `wikibase:identifiers` are ignored from the wikibase dumps and generated on the fly at munge time