Wikitech-l December 2003

wikitech-l@lists.wikimedia.org

84 participants
155 discussions

sysop on fr
by Constans, Camille (C.C.) 12 Dec '03

12 Dec '03

Hello, 2 weeks ago, on fr, we nominated traroth and jeffdelonge as sysop. But only traroth is sysop now ! Can you give the sysop statut to jeffdelonge please ? Thank you Shaihulud

1 0

Re: [Wikipedia-l] RE: [Wikitech-l] Categories simplified
by Evan Prodromou 12 Dec '03

12 Dec '03

>>>>> "TC" == The Cunctator <cunctator(a)kband.com> writes: TC> If we accept this principle, we should replace all of the TC> [[list of ]] entries with [[Category:]] entries. TC> I'm not quite entirely convinced that the healthiest thing to TC> do is to separate category/list pages from the main namespace, TC> but it's not a bizarre concept. I'm pretty much not terribly happy with the idea. I think the category-member relationship is a whole nother kettle of fish from the issue of namespaces. I think that getting into pseudo-namespaces ("Category:" is not a namespace -- it's just a prefix) is probably not in our best long-term interest. I think that "Wikipedia:Help" or "Wikipedia:About" could and should be categories. I think that we should use field-value pairs for categorization and for tagging categories: http://meta.wikipedia.org/wiki/Categorization_with_field-value_pairs I also think that we can use a bot to move [[list of X]] to [[X]], where X doesn't already exist, mark that article as a category ([[type=category]]), and add ([[category=X]]) to any links in a list on that page. ~ESP -- Evan Prodromou <evan(a)wikitravel.org> Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide

2 1

Categories simplified (was: I never metadata I didn't like)
by Jakob 12 Dec '03

12 Dec '03

Hi, I do not understand what's wrong with the first [[Category:...]] approach. Categories are kind of metadata - not all arguments against metadata apply on them. Categories are not hidden as long as they result in a link on top of the article or somewhere else - they are not more complicated than interlanguage links (which are complicated in some way). Seperating categorisation and articles in two projects does not make categorisation more easy. In fact I'd also like to move articles and categories around in a hierarchal view but the most common action is to specify the category an article belongs to. By the way categories are nothing but hierarchical links between articles. Semantically there is no big difference between dividing an article in subtopics and creating a category with a couple of articles in it. Magnus wrote: > Example: "[[Category:Stuff]]" somewhere in the article will show a link > above (similar to language links), leading to the category page > ("Category:Stuff"). That will automagically list all pages in that > category (meaning, that link there via category link). A category page > can be edited like a normal page (the article list is automatically > shown below), and can include "super-categories" (e.g., > "[[Category:Biology]]" on "Category:Zoology"). Any page can, of course, > have many categories. Ah - that´s the fault! The link [[Category:Stuff]] should refer to the article "Stuff" and not to some special-category-only article. [[Category:Biology]] *is* [[Biology]]! Please have a look at the actual article [[en:Biology]]: What does ==Fields of study in biology== contain but a listing of subtopics? Why introduce a new artificial namespace when you can better name the article for instance "Fields of study in biology"? > The Cunctator wrote: > I could imagine a group at the MIT Media Lab or the Cyc project figuring > out some bad-ass way of navigating Wikipedia content, etc. That's still possible with categories. There are a lot of automatic posibilities - most of them based on the links between articles. A special category-link would give more input. > What I'd like to see is an explicit wiki-statement of what is the > desired functionality--that is, what is the utility missing--that a > category scheme would provide. > > Then we can discuss particular implementations separately--for example, > is it better to use a system which has a single ontology or a system > which allows for dynamic ontologies? Argl! A wikiontology is a nice scientific project but nothing any normal human beeing will ever able to edit. Evan wrote: > What I propose it that MediaWiki expand this metadata format to cover > other types of metadata, such as: > > * categorization -- saying that particle physics is in the > physics category, or that Lord of the Rings is in the fantasy > books category > * relationships between articles -- break up a single page into > multiple chapters or sections, and note that they're all part > of the same article categorization is just a kind of typed relationship. I could also imagine: [[see:A]] see-also-links that will automatically generate a backlink on article 'A' [[next:A]] ordering articles But hierarchical link are the most important ones. Greetings, Jakob

7 11

Table restructuring: Plan B
by Magnus Manske 12 Dec '03

12 Dec '03

There recently are two threads on this list: Table restructuring and Postgres. Which made me thinking: Why not use the opportunity to support both? Here's the plan (V0.1alpha): * A new table (or two) for the database, storing the proposed "essentials" * No changing of the cur/old tables due to speed concerns * Creation of a high-level database wrapper class My vision (random thought, actually;-) is this: No SQL statements *at all* in the PHP, except for the database wrapper. Advantages: * Use of all the goodies (simple PHP code, simple identification of any article version etc.) * Easy switching to postgres/sqlite/whatever So the wrapper will present a "universal" database, and do all the ugly work. I'd imagine "DBmysql", "DBpostgres", etc. as classes. That will not only make the wiki-part of the script more flexible (imagine an intranet installation running sqlite - only apache and PHP needed!), it will also make debugging and future extension easier. One downside, though: major refactoring... Magnus

1 0

Mysql tweaks
by Brion Vibber 12 Dec '03

12 Dec '03

As a precaution I've lowered the memory usage on MySQL. Below is the my.cnf currently used (minus comments). I reduced the key buffer and InnoDB buffer pool each from 1G to 768M, and the max connections from 650 (which allowed for generous attempts at double connections if every apache process were running the wiki and had a broken persistent connection, a new connection on top, and maybe some extra) to 300. (Apache is now set to allow a max of 120 connections on larousse and 150 on pliny; this leaves only a little bit extra if all those connections get used). The maximum possible memory usage should be roughly 4MB*300 connections plus 768M plus another 768M? Under 3 gigs, in theory, of the 4G geoffrin has. Under the previous configuration a complete stall-out which used the full memory maxima would have gone into swap which it may not handle well; this may be responsible for a signal 11 mysqld crash a few hours ago and the more recent hang. Unfortunately neither time I had a vmstat sitting around. [client] port = 3306 socket = /tmp/mysql.sock [mysqld] port = 3306 socket = /tmp/mysql.sock skip-locking key_buffer = 768M max_allowed_packet = 1M table_cache = 1000 sort_buffer_size = 2M read_buffer_size = 2M myisam_sort_buffer_size = 64M thread_cache = 8 query_cache_size = 32M thread_concurrency = 8 set-variable = max_connections=300 log-bin set-variable = ft_min_word_len=2 server-id = 1 tmpdir = /var/tmp/ innodb_buffer_pool_size = 768M innodb_log_file_size = 128M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 2 [mysqldump] quick max_allowed_packet = 16M [mysql] no-auto-rehash [isamchk] key_buffer = 256M sort_buffer_size = 256M read_buffer = 2M write_buffer = 2M [myisamchk] key_buffer = 256M sort_buffer_size = 256M read_buffer = 2M write_buffer = 2M [mysqlhotcopy] interactive-timeout -- brion vibber (brion @ pobox.com)

1 0

slow downs
by Green Mountain 12 Dec '03

12 Dec '03

Wikipedia usually runs very smoothly ans quickly, but there are some times (such as now), where wikipedia doesn not respond at all. Why is this? Greenmountainboy

2 1

I never metadata I didn't like
by Evan Prodromou 11 Dec '03

11 Dec '03

So, when I was weeding through the RFEs on SourceForge last week, I noted quite a few having to do with metadata, including: 579758 Consider keyword meta tags 629323 Simple article categorisation system 766213 Provide Standardized Subject Search 839394 Meta ICBM tags when appropriate I think I must have closed like 5 other RFEs and referred them to #629323. There's lots of people who want category metadata. Anyways, I wanted to float a design idea for inclusion of metadata in MediaWiki articles. None of this is particularly new, and it seems like most has been suggested at one point or another. ---8<--- WHAT IS METADATA? ----------------- Metadata is data about data. For example, the filename and count of bytes of a file on a filesystem is metadata: not part of the data, but _about_ the data. Metadata can arise naturally from the data (byte count) or can be added from outside the data (file name). Metadata helps us sort data, find data, and make decisions about data. For example, you can sort files in a directory alphabetically by filename to find a file you want. Or you can sort them by size to find the biggest or smallest. You can delete a file called "TEMPFILE.$$$" because you know it's a temporary file. We use metadata so often, we sometimes forget that it's "meta". But it is: changing the name of a file, or moving it to another folder, doesn't change the contents of the file. It just changes how we find and access the file. METADATA IN MEDIAWIKI --------------------- We use a lot of metadata for MediaWiki articles: page sizes, page histories, new pages page, recent changes page, etc. etc. Some of the metadata we use is calculated from the data itself -- sizes -- and some of it is not -- timestamps, who made changes, etc. It would probably be fair to say that article titles and redirects are metadata. One form of metadata that we now use is interlanguage links. Interlanguage links are metadata that say: "There is an article in the language XX Wikipedia (or other installation) that covers this same topic." That's pretty cool metadata to have. What I propose it that MediaWiki expand this metadata format to cover other types of metadata, such as: * categorization -- saying that particle physics is in the physics category, or that Lord of the Rings is in the fantasy books category * relationships between articles -- break up a single page into multiple chapters or sections, and note that they're all part of the same article * synopses -- providing a synopsis or description of an article * geography -- marking up pages to specify that they cover a particular geographical location * customizable per-installation metadata -- metadata that may make sense for different installations. I'm particularly interested in this last one, since it would help us with Wikitravel. METADATA IN THE DATABASE ------------------------ I think it's pretty reasonable to just think of metadata as name-value pairs, where the name key is not necessarily unique. For example, we could have a table like this for the article on David Brinkley: article id metadata_name metadata_value ------------------------------------------------ 1 category journalists 1 category American people 1 see_also CBS 1 see_also CBS News It should be relatively easy to slurp up the metadata on an article when rendering the article, and to pluck out the metadata from an article when saving it. We do this with links, broken_links, and image_links now. METADATA IN WIKITEXT -------------------- One way to do metadata is to have a different entry format for metadata than for the text and markup of an article. I'm going to reject that, since we already have a winning mechanism for marking up some metadata -- interlanguage links -- within the Wiki markup. Whether this would make it _really_ data instead of metadata is left as an exercise to the reader. There's a couple of ways we could do this in wikitext: <<name=value>> <<name:value>> [[meta:name=value]] [[meta:name:value]] [[name:value]] The first couple are kinda radical, and don't really jibe with interlinks, anyways. The last one has the potential to clash with other namespaces. I prefer [[meta:name=value]], just because it's kinda easy. I realize that the name "meta" clashes with "metawikipedia", so maybe another work would work. It's not particularly important what format we use; what's important is that we have a way to enter arbitrary name-value pairs into the text of articles. RENDERING METADATA ------------------ I think there are a couple of ways we can deal with metadata in an article when rendering it: * Add it as a <meta> tag to the HTML <head> * Add it as a <link> tag to the HTML <head> * Add it as an out-of-page link, like Interlanguage links work now * Render it in the text of the document (I can't see why this would be useful, but) * Ignore it I think we could have several pre-defined names, with predefined rendering, and other names with possible renderings configurable per-installation. OTHER USES OF METADATA ---------------------- There are some other uses of metadata, of course. One would be automatically-built directories, by category. ---8<--- So, my second big proposal of the day. ~ESP -- Evan Prodromou <evan(a)wikitravel.org> Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide

14 43

Categorization
by Evan Prodromou 11 Dec '03

11 Dec '03

So, uh, I thought I'd throw together a page on meta-wikipedia to talk about categorization. It may make things easier and will probably last longer than everyone's mail queue. http://meta.wikipedia.org/wiki/Categorization I have a feeling that this conversation has happened before and may happen again; it'd be nice to archive it. ~ESP -- Evan Prodromou <evan(a)wikitravel.org> Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide

1 0

fr ml admin
by Anthere 11 Dec '03

11 Dec '03

Hello all, Shaihulud is now the administrator of the french mailing list. Shai, if it is a problem to you, Yann va also interested in taking care of it all. Thanks Shai Ant __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree

1 0

Database oddities on fr:
by Nicolas Weeger 11 Dec '03

11 Dec '03

Hello. Some admins have noticed oddities on fr: database. For instance: A direct SQL query gives, for image #14318, the description 'Angraecum photo perso GFDL' Going to the page yields the description (even forcing the refresh with ctrl-f5): Description : Angraecum photo perso Source : Jeffdelonge Licence : GFDL Quite different, aren't there? Also, in links, a page 'MERCOSUR' has >20 links outside, when it is a REDIRECT!!!! Is that the result of some cache? Is that the right behaviour? Also, since the db server runs nicely (couldn't kill it with requests, i'm soooo sad :), maybe maintenance pages could be reactivated (the magic works, but still) Nicolas 'Ryo'

3 4

← Newer
1
...
5
6
7
8
9
10
11
...
16
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l December 2003