Last modified: 2012-04-14 09:19:46 UTC
Some articles contain tables of data, and some contain several tables of the same data sorted different ways (see the list of Eurovision winners as an example). Wouldn't it be lovely to have a system to store tables of data, and a syntax in wikitext to render an output table using this underlying table of data, with the possibility for the user to dynamically reorder the table by clicking on a sort button? Say we had the following table of data, in a simple XML format, envelopped into some special wikitext tags on the page: <wikidata ID="ESCwinners"> <winner> <year>1956</year> <country code="CHE">Switzerland</country> <song>Refrain</song> <performer>Lys Assia</performer> </winner> <winner> <year>1957</year> <country code="NLD">Netherlands</country> <song>Net Als Toen</song> <performer>Corry Brokken</performer> </winner> <winner> <year>1958</year> <country code="FRA">France</country> <song>Dors, mon amour</song> <performer>André Claveau</performer> </winner> </wikidata> And if you want to render this as a table you might put something like this in the wikitext, with xpath expressions to describe which data we're actually pulling out for each column of the table: {| class="wikitable" |- style="background:#efefef" datasource="wikidata[@ID='ESCwinners']" ! Year { sortbutton="winner/year" ascending } !! Country { sortbutton="winner/country" } !! Song !! Performer |- winner/year || {{winner/country/@code}} || [[winner/song]] || [[winner/performer]] |} So the idea then is that the table is filled with as many rows as there are child nodes returned by evaluating the xpath expression in the datasource tag. |- style="background:#efefef" datasource="wikidata[@ID='ESCwinners']" The table header row will contain useful things like sort buttons. ! Year { sortbutton="winner/year" ascending } !! Country { sortbutton="winner/country" } !! Song !! Performer When the text is rendered, the { sortbutton ... } tag will be replaced with an icon that the user can click on to sort the table in ascending or descending order. The default sorting for when the page is first rendered can be put in the tag of the page code. Then the nodes/table rows are iterated over, and each new row of the table is filled with data using the xpath expresisons in the row description code. |- winner/year || {{winner/country/@code}} || [[winner/song]] || [[winner/performer]] And there you have it. Of course, just using unbridled XML and xpath provides tons of possiblities right out of the box, but it might be a bit much for the average editor. So perhaps a more resicted syntax for the XML data and the table description markup would be just as good. (Maybe it would be better to limit the XML data to element-centric or attribute- centric formatting to keep it simple, for ex.) So... well, I'm a programmer. Can't promise a lot of my time, but if this idea has any appeal I could make an effort. Rgds, Daniel
I think about this too, it will be very good to have some project like commons for images, but for data. Let's say, number of goals of some football player and something like that. And latter, on other projects we just use some sintax for "calling" this data from that "main" data project. Sasa
That would definitely make it even more useful. Though I can see two disadvantages to a common data centre. First, it would make it more difficult for a casual editor to see how to change the data. More importantly, there would be a maintainability issue when changes are made to the data in the common database. If someone decides that "goals" is too general and splits the data into "kicked goals", "headbutts", "penalties", etc. and they only think that one article uses this data, it could break the tables in other articles that use this data. If the data and table description are obligatorily in the same page, then the editor will see the full effect of their changes right away. Looking at the problem from a different angle, editors should feel confident that they can make changes without breaking something. Otherwise, they might be discouraged from adding useful information. But on the positive side, it is a very attractive idea to have all this data centralised so that different pages (on different subjects, or the same subject in different languages) call the same unique data. So maybe there is a way to work around the problems...
This is hardly a new idea; it's been thrown around for a few years now. See [[m:Wikidata]], and (for two currently-maintained attempts at an incarnation) the extensions "Semantic MediaWiki" and "WiktionaryZ". The major problems this has faced so far are technical: getting people to write it and making sure it's efficient enough to run acceptably. I guess there's no bug for this, so this may as well stay open, but see the product MediaWiki extensions, components WiktionaryZ and Semantic MediaWiki.
Please have a look at http://www.kennel17.co.uk/testwiki/WikiDB for an extension that I am currently developing that seems to do what you are asking. It's still in the early stages, so not completely working and not particularly optimised. Feedback is welcome.
Please have a look at the latest version of DynamicPageList at http://semeb.com/dpldemo The idea is that you DO NOT HAVE TO USE extra syntax, but create reports from existing wiki elements like headings, categories, links and template invocations. The combination of these four elements - together with contents transclusion - is quite powerful. You can easily write a DPL query which lists a certain chapter of every article which belongs to category "Poet" or uses a template called "Poet" and contains a link to another article called "Dublin". You can show arguments which are passed to the template "Poet" (using a different template) and you can transclude chapters with headings like "work" or "life".
*** Bug 6237 has been marked as a duplicate of this bug. ***
