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
--