Last modified: 2012-04-14 09:19:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7777 - Wiki data storage and dynamic table display
Wiki data storage and dynamic table display
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 6237 (view as bug list)
Depends on: 30345
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-01 01:09 UTC by daniel raillant-clark
Modified: 2012-04-14 09:19 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description daniel raillant-clark 2006-11-01 01:09:50 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
Comment 1 Sasa Stefanovic 2006-11-01 01:14:29 UTC
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
Comment 2 daniel raillant-clark 2006-11-01 01:31:44 UTC
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...

Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-01 01:36:31 UTC
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.
Comment 4 Mark Clements (HappyDog) 2006-11-02 15:51:22 UTC
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.
Comment 5 Gero Scholz 2007-03-06 21:48:52 UTC
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". 
Comment 6 Antoine "hashar" Musso (WMF) 2007-05-20 17:57:32 UTC
*** Bug 6237 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links