On Mon, Mar 31, 2008 at 12:43 AM, Daniel Kinzler daniel@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