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
>>>>> "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
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
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
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)
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
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
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
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
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'