Hey,
(Note: I am very jetlagged, so this is just my initial impression. I need to have a more thorough look at the involved things to provide a better solution.)
I agree that any "is redirect" flag in Entity is a bad idea.
This would require quite a bit of refactoring, and would introduce
redirects as a "first order citizen" into the Wikibase data model.
Since as you mention, the cost of this can be quite high, I'd like to verify what is actually really needed from a functionality point of view. Once that question has been settled we can determine which route to best take. Perhaps this is clear to you, though I'm unsure what exactly we hope to gain by having this in the data model itself.
In any case, I suggest we are cautious on which design changes and additions we make. In particular, we should not modify existing objects that suit the needs of their users into doing something that is less suitable, just because we have a new use case. Instead we should make an interface appropriate for that use case. Also, we should be careful not to mash concepts together and not to use the "is a" relationship between everything. Both these things have gone wrong for Entity originally.
And when making such changes, we should keep in mind our other requirements. I already wrote down quite a few points affecting Entity, some of which need to be tackled before we create any new implementation (ie QueryEntity) without introducing more technical debt.
a special *type* of Entity, besides Item and Property. This would again
allow straight forward diffs (and thus undo-operations) between the redirected and the previous, un-redirected version of a page
Can you explain this further? How does having this on the data model level, implemented as an Entity, help with diffs? Perhaps this is the case for EntityContent, though I suspect it is wrong for Entity.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --