https://bugzilla.wikimedia.org/show_bug.cgi?id=38962
Daniel Kinzler <daniel.kinz...@wikimedia.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|PATCH_TO_REVIEW |ASSIGNED
--- Comment #12 from Daniel Kinzler <daniel.kinz...@wikimedia.de> ---
@Bene: i mean Wikibase should handle redirects with the MediaWiki built-in
feature for them. That sort of thing is exactly why the Content interface
exists.
But I'm unsure how to go about it. I just sent a mail to wikidata-tech, asking
for feedback. Here's the mail:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hello all!
Once more, I'm taking a whack at implementing support for entity redirects -
that is, we want Q1234 to become a redirect to Q2345 after we merged Q1234 into
Q2345.
My question is how to best model this.
First off, a quick primer of the PHP classes involved:
* We have the Entity base class, with Item and Property deriving from it, for
modeling entities.
* As "glue" for treating entities as MediaWiki page content, we have the
EntityContent base class, and ItemContent and PropertyContent deriving from
that
(along with their handler/factory classes, EntityHandler, ItemHandler and
PropertyHandler).
Presently, each type of Entity is assigned a MediaWiki namespace, and all pages
in that namespace have the corresponding content type.
Now, there are various ways to model redirects. I have tried a few:
1) first I tried implementing redirects as a "mode" any Entity may have. The
advantage is that redirects can seamlessly occur anywhere "real" entities can
occur, e.g. in dumps, diffs, undo operations, etc. However, many operations
that
are defined on "real" entities are not defined on redirects (e.g. "set label",
etc), so we would end up with a lot if "if redirect, do this, else, do that"
checks all over the code base.
2) second I tried implementing redirects as a "mode" any EntityContent may
have,
following the idea that redirects are really a MediaWiki concept, and should be
implemented outside the Wikibase data model. This still requires a lot of "if
redirect, do this, else, do that" checks, but only in places dealing with
EntityContent, not all places dealing with Entities.
3) third I tried using a separate entity type for representing redirects: a
RedirectContent points to an EntityContent, there is no "mode", no need for
extra checks, no chance for confusion. However, we break a few basic
assumptions, most importantly the assumption that all pages in an entity
namespace contain an EntityContent of the respective type.
None of these solutions seem satisfactory for the indicated reasons, and also
some additional consideration explained below.
4) This lead me to come fully cycle and consider another option: make redirects
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; Also, it would not compromise code
that operates on Item on Property objects. But since there are still many
operations defined for Entity that make no sense for redirects, we would need
to
insert another class into the hierarchy (let's call it LabeledEntity) which
would be a base class for Item and Property, but not for Redirect.
This would require quite a bit of refactoring, and would introduce redirects as
a "first order citizen" into the Wikibase data model.
Which of the four options do you prefer? Or can you think of another, better,
option?
Below are some more points to consider when deciding on a design:
In a addition to the OO design questions outlined above, one important question
is how to handle redirects in the wb_entity_per_page table; that table contains
a 1:1 mapping of entity_id <-> page_id. It is used, among other things, for
listing all entities and for checking whether an entity exists. HOw should
redirects be represented in that table? They could be:
a) omitted (making it hard to list redirects),
b) or use the redirect's page ID (maintaining the 1:1 nature, but pointing to a
page that actually does not contain an entity),
c) or use the target entities page ID (breaking the 1:1 nature of the table,
but
associating the ID with the accurate place).
For b) and c), a new column would be needed to mark redirects as such.
When deciding on how to represent redirects internally, we need to consider how
they should be handled externally. Of course, when asking for an entity that
got
redirected, we should get the target entity's content, be it using the
"regular"
HTML page interface, the API, the linked data interface, etc.
In RDF dumps, we would probably want redirects to show up as owl:sameAs
relations (or something similar that allows one URI to be indicated as the
primary one). Should redirects also be present in JSON dumps? If so, should it
also be possible to retrieve the JSON representation of entities from the API,
in places where usually "real" entities would be?
-- daniel
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
