On 10/02/10 11:20 AM, Lars Aronsson wrote:
> Does it need to be more complicated than that?
> If so, exactly what is missing in my overly
> simplistic approach?
>
It's fundamentally an ad-hoc "temporary" solution. The toolserver is
great for prototyping, but anything integrated into the actual
Daniel Kinzler wrote:
> Basically: yes, this is the idea, but detecting categorization changes isn't
> trivial. also, really keeping a copy of the flat content of each category
> would
> be redundant to the extreme. it would result in hundreds of millions of
> entries,
When something starts to l
I think this thread is more heated than it needs to be.
Perhaps we could keep the on-list discussion on-topic, and perhaps
appropriate disclaimers and more judicious phrasing could be used to
prevent people from getting the wrong idea. I also think that clarifying
misunderstandings can be done
> say. (No offense to Daniel -- if I said the same thing, my opinion
None taken, especially since these "demands" are purely a product of
David's fantasy in the first place.
My intent was to point out the convoluted situation in the commons
case. Multiple requests have been made for intersection
On Sun, Feb 7, 2010 at 11:50 AM, David Gerard wrote:
> It would be nice if you'd bothered to make it clear that Daniel's
> opinion didn't count. Else your tacit acceptance is the only message
> being sent.
*Nothing* said here is a "message being sent" to anyone other than
developers and sysadmins
On 7 February 2010 16:31, Aryeh Gregor wrote:
> On Sun, Feb 7, 2010 at 8:42 AM, David Gerard wrote:
>> *Precisely*. This is why the new (and it is new) demand to trash the
>> present category tree before *possibly* implementing a category
>> intersection feature is, in practical terms, indisting
On Sun, Feb 7, 2010 at 8:42 AM, David Gerard wrote:
> *Precisely*. This is why the new (and it is new) demand to trash the
> present category tree before *possibly* implementing a category
> intersection feature is, in practical terms, indistinguishable from
> sheer contemptuous obstructionism.
N
> In practice, the difference between this and saying "No, never" is
> telling people to do work that you know can't happen.
Wow, this is rich. We already had this conversation. A reminder:
> Demanding that all six million files be de-categorised before you'll
> even allow a category intersection
On 7 February 2010 13:27, Roan Kattouw wrote:
> There's no reason why it couldn't be the other way around: an
> intersection feature could be written and deployed *first*, *then* the
> category trees on Commons would be gradually migrated to the new
> system. Issues like nonsense results for auto
2010/2/7 David Gerard :
> The problem is that doing this before the feature that uses it is in
> place renders categorisation on Commons even more useless. What this
> will mean is that you will be requiring a direct reduction in the
> usability of the wiki content before *possibly* implementing a
On 7 February 2010 13:09, Daniel Schwen wrote:
> Ok, lets's say Neil found a way to deal with 10. I give you that this
> is implementation specific. Number 2) however is independent of any
> implementation. Here you have your "hoop" (to to stick with your
> pejorative lingo): Get rid of the crazy
>> Please make an unambiguous list of the hoops Commons will be required
>> to jump through before this feature can happen, so it's actually clear
Way to be acerbic...
> list of these hoops, only vague generic hoops that apply to any kind
[..]
> Like Aryeh said, Neil is currently working on a conc
2010/2/7 David Gerard :
> Could the developers please outline, point by point, the precise hoops
> we need to jump through to get category intersections on Commons? New
> hoops seem to have been introduced during the currently discussion.
>
> Please make an unambiguous list of the hoops Commons wil
On Sun, Feb 7, 2010 at 7:01 AM, David Gerard wrote:
> Could the developers please outline, point by point, the precise hoops
> we need to jump through to get category intersections on Commons? New
> hoops seem to have been introduced during the currently discussion.
Right now, I'd try just waitin
On 7 February 2010 08:45, Andrew Garrett wrote:
> Not at all, it's entirely reasonable to discuss the problems associated
> with the current categorisation system, and what methods we'd like to
> use to improve it.
The current categorization system is per-wiki-specific. It's done
differently in
On 6/02/10 6:44 AM, Tei wrote:
> On 5 February 2010 20:17, Aryeh Gregor wrote:
>
>> On Fri, Feb 5, 2010 at 3:57 AM, Daniel Kinzler wrote:
>>
>>> Or,
>>> to put it differently: let people use "flat tagging", but let's keep the
>>> notion
>>> of one tag implying another, i.e. math implyi
On 5 February 2010 20:17, Aryeh Gregor wrote:
> On Fri, Feb 5, 2010 at 3:57 AM, Daniel Kinzler wrote:
>> Or,
>> to put it differently: let people use "flat tagging", but let's keep the
>> notion
>> of one tag implying another, i.e. math implying science and texas implying
>> america.
>
> And as
On Fri, Feb 5, 2010 at 3:57 AM, Daniel Kinzler wrote:
> Or,
> to put it differently: let people use "flat tagging", but let's keep the
> notion
> of one tag implying another, i.e. math implying science and texas implying
> america.
And as for [[Category:People executed for heresy]] -> [[Categor
Tim Landscheidt schrieb:
> Daniel Kinzler wrote:
>
>>> In the meantime:
>>> http://toolserver.org/~magnus/catscan_rewrite.php
>
>>> (toolserver seems to have a problem ATM, though...)
>
>> Yes, lots more options than my old thingy, thanks magnus :) but still bound
>> to
>> recursive calls to t
On Thu, Feb 4, 2010 at 6:40 PM, Tim Landscheidt wrote:
> Is there any reason not to have a flatted structure some-
> where on the toolserver (or, in the long run, in MediaWiki)?
> A quick look at recentchanges for dewp shows about
> 22000 changes per month, about one every two minutes. With
> abou
Daniel Kinzler wrote:
>> In the meantime:
>> http://toolserver.org/~magnus/catscan_rewrite.php
>> (toolserver seems to have a problem ATM, though...)
> Yes, lots more options than my old thingy, thanks magnus :) but still bound to
> recursive calls to the database, which is what i really want t
Magnus Manske schrieb:
> In the meantime:
> http://toolserver.org/~magnus/catscan_rewrite.php
>
> (toolserver seems to have a problem ATM, though...)
Yes, lots more options than my old thingy, thanks magnus :) but still bound to
recursive calls to the database, which is what i really want to get
On Thu, Feb 4, 2010 at 5:02 PM, Daniel Kinzler wrote:
> Robert Stojnic schrieb:
>> Aryeh Gregor wrote:
>>> Right. Supporting category intersection and search in category with
>>> better UI (we already sort of support it if you know the right magic
>>> terms) is what we should be aiming for here.
On 4 February 2010 17:38, Daniel Schwen wrote:
>> But we need the functionality there first, so we can *then* flatten.
> Ahh, the good old chicken and egg ;-)
> I don't let that count. We have plenty of working category
> intersection tools already.
Yes, but they're not part of the interface.
> But we need the functionality there first, so we can *then* flatten.
Ahh, the good old chicken and egg ;-)
I don't let that count. We have plenty of working category
intersection tools already. Their usefulness is limited however
because the category system is so screwed up.
The ball is definite
On 4 February 2010 16:37, Daniel Schwen wrote:
> The only way to get proper intersection is manual flattening i.e.
> atomic categorization. As long as nobody is pushing commons _hard_ to
> change their categorization system _nothing_ will happen and we'll
> meet on this list again in about one ye
Robert Stojnic schrieb:
> Aryeh Gregor wrote:
>> Right. Supporting category intersection and search in category with
>> better UI (we already sort of support it if you know the right magic
>> terms) is what we should be aiming for here.
>>
>
> Last year, just around this time, we came to the e
On Thu, Feb 4, 2010 at 11:28 AM, Conrad Irwin
wrote:
> Presumably it would not be too hard to append the full category list to
> the blob that gets sent to the search engine
No, probably not, but it would be even easier to not worry about it
yet (unless someone wants to!).
On Thu, Feb 4, 2010 at
This is putting the cart in front of the ox yet again. A few mails up
Aryeh and Gregory both come to the conclusion that automatic
flattening is useless.
Yet category flattening would be a prerequisite to intersections.
The only way to get proper intersection is manual flattening i.e.
atomic catego
On 02/04/2010 04:10 PM, Aryeh Gregor wrote:
>
> Yup. Any volunteers? My understanding is that right now, the backend
> supports category searches as long as the categories are spelled out
> literally in the wikitext (not via template).
Presumably it would not be too hard to append the full ca
On 04/02/10 16:03, Robert Stojnic wrote:
> Aryeh Gregor wrote:
>
>> Right. Supporting category intersection and search in category with
>> better UI (we already sort of support it if you know the right magic
>> terms) is what we should be aiming for here.
>>
>>
> Last year, just around t
On Thu, Feb 4, 2010 at 11:03 AM, Robert Stojnic wrote:
> Last year, just around this time, we came to the exactly same
> conclusion. And similarly like then, there is no shortage of good
> opinions on how to do it, but people to actually do the programming.
Yup. Any volunteers? My understanding
Aryeh Gregor wrote:
> Right. Supporting category intersection and search in category with
> better UI (we already sort of support it if you know the right magic
> terms) is what we should be aiming for here.
>
Last year, just around this time, we came to the exactly same
conclusion. And simi
On Thu, Feb 4, 2010 at 10:02 AM, Gregory Maxwell wrote:
> But if you do atomic categories explicitly enumerated on the pages
> then you get the right properties, and fast search with intersections
> is the same problem as full text search. I.e. solved.
Right. Supporting category intersection and
On Thu, Feb 4, 2010 at 9:27 AM, Aryeh Gregor
wrote:
> 1) Our database schema is not set up to handle this efficiently for
> large result sets. At least I don't think so, off the top of my head.
I've never been able to come up with an acceptable data-structure for
flattening on the fly.
(I think
On Wed, Feb 3, 2010 at 10:10 PM, Rayson Ho wrote:
> Seems like it is no easy way to display all the media files under a
> wikimedia category -- for example if someone wants a picture of a
> library, he or she will need to go into each sub-category under
> "Libraries":
>
> http://commons.wikimedia.
> While Wikimedia is not yet the most popular stock photo source, IMO
> having this flattening functionality would be useful to those who are
> looking for stock photos.
Just I love this recurring debate sooo much I drop a two more bits:
* atomic categorization would solve this
* category interse
Seems like it is no easy way to display all the media files under a
wikimedia category -- for example if someone wants a picture of a
library, he or she will need to go into each sub-category under
"Libraries":
http://commons.wikimedia.org/wiki/Category:Libraries
While Wikimedia is not yet the mo
38 matches
Mail list logo
