On Mon, Mar 31, 2008 at 12:43 AM, Daniel Kinzler <daniel(a)brightbyte.de> wrote:
Bryan Tong Minh wrote:
To get to a real working API the first thing we
need is to store the
meta data as author, license, etc in the database, rather than putting
it all together in one text field. You don't want an API that parses
text.
Here is something I have been thinking about for a while, which could make this
kind of storage feasible: <http://brightbyte.de/page/WikiData_light>. It's
only
an idea at the moment, but I believe it would be doable without too much
trouble, and could be made to scale. It's less powerfull than full-fletched
WikiData or Semantic MediaWiki, but it's far less comple and much easier to
integrate with Wikipedia operations - and I believe it would be flexible and
powerful enough to be useful.
Looks like a quite good and not really hard to implement idea to me.
Especially since we now have the page_props table, which would be
ideal for this.
Oh, and just for the record, let me mention
<http://commons.wikimedia.org/wiki/Commons:Tag_categories> here. From what I see
people don't follow the "all templates must be in those categories
directly"
bit, and are using subcategories - so getting the right info takes a bit more
processing, but that, too, would be doable by evaluating the tag category
hierarchy every week or so. That would most probably be a toolserver-based solution.
The problem is that people don't actually read that page. And when
they categorize, they think quite obviously that the tag is
overcategorized when it appears both in a sub cat as well as in a
parent cat. Some people suggested to me to use [[Category:All license
tags]], which is a subcat of [[Category:License tags]] itself, and
have [[Category:License tags]] on be used as category for categories.
Unfortunately this will break many tools that depend on [[Commons:Tag
categories]].
Bryan
_1_307.jpg){kind=link}