-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've asked this before, and got some vaguely positive answers, so I'll try again...
Whould we add tables to the database that store the values of variables passed to templates for each page? Like:
template_used : ID of page, ID of template page, unique ID template_values : ID of template_used, variable name, value name
This would allow for searching the meta data that is stored in the templates. My prime example would be the "Personendaten" (person data) template on the German wikipedia. For "Albert Einstein", it looks like this:
{{Personendaten| NAME=Einstein, Albert |ALTERNATIVNAMEN= |KURZBESCHREIBUNG=[[Physiker]] |GEBURTSDATUM=[[14. März]] [[1879]] |GEBURTSORT=[[Ulm]] |STERBEDATUM=[[18. April]] [[1955]] |STERBEORT=[[Princeton (New Jersey)|Princeton]], [[USA]] }}
so one could generate a list of all people sorted by *last* name, with key information like description, alternative names, time and place of birth/death.
I thought of this again when I was contacted yesterday about a way to improve wiktionary. I gathered that short of rewriting the whole MediaWiki, one could (by default) change the edit function to display a "real" input form, in contrast to the Big Text Box (tm) for a more data-driven wiki site like wiktionary. The form info could then be merged into a single text using a template, and taken apart again when the page is edited further.
That would allow for changing the data display by merely editing the template. Also, with the template variable/value mechanism described above, (simple) search queries could be run through a special page, and automatic processing of data sets (was:pages;-) would be possible/more easy than now.
I would implement the database side, if there are no concernes about the database getting Yet More Bloated, and MySQL Even More Sluggish (both (TM) MediaWiki;-).
Magnus
Magnus Manske schrieb:
Whould we add tables to the database that store the values of variables passed to templates for each page? Like:
template_used : ID of page, ID of template page, unique ID template_values : ID of template_used, variable name, value name
Very interesting! I would also like to use user input in a wiki of mine for some kind of database retrieval and thought about a similar approach this week. As the number of templates is relatively small and doesn't change structure often I thought about storing the template values in a table for each template, but your approach of using a generalized table for all fields of all templates seems to be better as it handles the changes in template structure more easily.
I would implement the database side, if there are no concernes about the database getting Yet More Bloated, and MySQL Even More Sluggish (both (TM) MediaWiki;-).
I'd be happy to help you by reviewing, coding or whatever. Please notify me even if the whole idea gets discarded as I would then start coding something like that myself.
Ciao, Michael.
Magnus Manske wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've asked this before, and got some vaguely positive answers, so I'll try again...
Whould we add tables to the database that store the values of variables passed to templates for each page? Like:
template_used : ID of page, ID of template page, unique ID template_values : ID of template_used, variable name, value name
This would allow for searching the meta data that is stored in the templates. My prime example would be the "Personendaten" (person data) template on the German wikipedia. For "Albert Einstein", it looks like this:
{{Personendaten| NAME=Einstein, Albert |ALTERNATIVNAMEN= |KURZBESCHREIBUNG=[[Physiker]] |GEBURTSDATUM=[[14. März]] [[1879]] |GEBURTSORT=[[Ulm]] |STERBEDATUM=[[18. April]] [[1955]] |STERBEORT=[[Princeton (New Jersey)|Princeton]], [[USA]] }}
so one could generate a list of all people sorted by *last* name, with key information like description, alternative names, time and place of birth/death.
I thought of this again when I was contacted yesterday about a way to improve wiktionary. I gathered that short of rewriting the whole MediaWiki, one could (by default) change the edit function to display a "real" input form, in contrast to the Big Text Box (tm) for a more data-driven wiki site like wiktionary. The form info could then be merged into a single text using a template, and taken apart again when the page is edited further.
Hoi, At this moment in time Erik Moeller is working on Wikidata and this in turn will enable the "Ultimate Wiktionary" and a functional Wikispecies... This system is not based on templates but it uses a database to store information. What is needed for an enhanced Wiktionary functionality is a bit more than flat file functionality. If I understand well what you propose, I do not see what the added value of your proposal is given that Wikidata is being developped. One of the things your proposed functionality does not provide is a potential to localise the information or use information in more than one project or language. Thanks, GerardM
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gerard Meijssen schrieb:
Hoi, At this moment in time Erik Moeller is working on Wikidata and this in turn will enable the "Ultimate Wiktionary" and a functional Wikispecies... This system is not based on templates but it uses a database to store information. What is needed for an enhanced Wiktionary functionality is a bit more than flat file functionality. If I understand well what you propose, I do not see what the added value of your proposal is given that Wikidata is being developped.
At the very least, it would make it easier to fill wikidata tables from existing data.
One of the things your proposed functionality does not provide is a potential to localise the information or use information in more than one project or language.
Information could be queried by special pages, but no, there's no central repository like wikidata. It would be more for simple, local issues. Have a list of people in wikidata central? Great. Have a list of people in the German wikipedia? I'd have to either update wikidata on every edit in de.wikipedia, or check wikidata and then de.wikipedia again, to see which people articles actually exist here. Sounds like an unnecessary step to me, and considering server load, this is a bad thing ;-)
Magnus
Magnus Manske wrote:
Gerard Meijssen schrieb:
Hoi, At this moment in time Erik Moeller is working on Wikidata and this in turn will enable the "Ultimate Wiktionary" and a functional Wikispecies... This system is not based on templates but it uses a database to store information. What is needed for an enhanced Wiktionary functionality is a bit more than flat file functionality. If I understand well what you propose, I do not see what the added value of your proposal is given that Wikidata is being developped.
At the very least, it would make it easier to fill wikidata tables from existing data.
This is only true if the scheme you talk about already exists. At this moment you request some comments.... I do not understand how your proposal adds value to our projects.
One of the things your proposed functionality does not provide is a potential to localise the information or use information in more than one project or language.
Information could be queried by special pages, but no, there's no central repository like wikidata. It would be more for simple, local issues. Have a list of people in wikidata central? Great. Have a list of people in the German wikipedia? I'd have to either update wikidata on every edit in de.wikipedia, or check wikidata and then de.wikipedia again, to see which people articles actually exist here. Sounds like an unnecessary step to me, and considering server load, this is a bad thing ;-)
Hoi, The current server load is a problem at this moment in time. This is a problem that needs to be solved and that propably will be solved. When considering how things could work it is not a strong argument. Take the Commons pictures, it is one of the Wikimedia success stories and, it is exactly the scheme that you describe as being something we do not want ..
So when you want sharable data between the different projects, you can use Wikidata. It does not mean that you cannot edit its content. The great idea of shared data is that you benefit from the work done in other projects. This sharing of data, information and the collobaration of our effort is what makes our projects so amazingly great. Concentrating on improving information in one project is great up to a point. It would be so more cool if much of this effort is made available to all projects ..
One example of this convergence of effort and better functionality can be found in http://meta.wikimedia.org/wiki/Using_Ultimate_Wiktionary_for_Commons This describes how you can use the Ultimate Wiktionary for the localisation of keywords for Commons. This will allow an eight year old kid to enter кінь and it will find pictures with horses on it.
Now to find people to work on these kinds of functionality .. :)
Thanks, GerardM
Magnus:
I've asked this before, and got some vaguely positive answers, so I'll try again...
Ah yes, that sounds familiar: http://mail.wikimedia.org/pipermail/wikitech-l/2004-March/021553.html ;-)
As Gerard has pointed out, I'm working on Wikidata. My current line of thinking is at http://meta.wikimedia.org/wiki/Wikidata/Notes (not really meant for public consumption yet, but feel free to point out obvious stupidities).
Wikidata does not necessarily require a central repository, you can have project-local or global schemas, though in most cases, having data centrally stored will be preferable. Take, for example, country statistics: The population, the currency, the GDP, the head of state etc. are not language-dependent. You will not want to have redundant copies of all this data or you end up with a high maintenance system like the interlanguage links. ;-) Instead you will want to be able to distinguish between * data which is highly language-specific (leave it blank even if data in other languages exists) * data which is rarely language-specific (make a copy from other language(s)) * data which is never language-specific (everyone edits the same version). Ideally, you would be able to group subsets of languages together according to these criteria, and define orders of preference.
The user does not necessarily have to notice that they are using a global repository. You could have the script access the DB transparently as needed. But all this is still quite a while away, the Ultimate Wiktionary is priority number 1, and that's a separate database of its own.
When I've finished the specs (I may have to go back to the drawing board if the current fixed table approach turns out to be unworkable), I'll send out a call for open participation. I'd like to ask you to be patient until then with your own implementation. As for importing existing data, we could use a server-side script to extract data from templates, though this should be done cautiously as much of it is currently not very high quality (templates have no parameter validation).
Erik
wikitech-l@lists.wikimedia.org