Encyclopedia > User:Hfastedge

  Article Content


  • I love progress.
  • Email me here (http://tacos.sus.mcgill.ca/~hperes/stuffBox/em.png)

Interactive list of my unique contributions to wikipedia http://tacos.sus.mcgill.ca/~hperes/uniwiki/name

BTW, if u would like to have this feature for yourself, please email me.

I believe there is no reason that wikipedia cannot grow to a size such that it is a reasonable fraction of the internet. The internet is not an encyclopedia, its a chaotic web of information.

Finally, as wikipedia grows, the search feature will become more useless as it is simply a bag of words[?] based on the oldvector space retreival[?] model.

What we need to do, as I debate below is have the ability give articles links other articles that are semantic parents. This will enable the structure of wikipedia to be shaped by everyone much more directly. Moreover, when you search for things, you will be presented with so much more information.

Improving wiki First a random topic:

/wiki/Engrish which talks about the english spoken by the chinese.

Semantically, engrish is really a sub idea of a more general idea, namely, accents. Lets define engrish to be the semantic child of ONE! of it's MANY POSSIBLE semantic parents: accents.

So u goto to the "What links here" from Engrish, and you'll indeed see that no page on accents links to it. you'll see that there is in fact no page on accents. To address this: I propose, that every page should have a semantic parent or parents. Specifically, when editing a page, you should also have the ability to denote whether some [[link to topic]] is a sub-category (or semantic child) of that page.


Educational Reform in occupied japan. "educational reform" the idea, only applies in this case to occupied japan. Its much easier to develop some notation to help you show this, instead of taken many steps to manually create this structure.


you're in a page on occupied japan, and u decide to create a new wiki page on educational reform, so use a new notation to show that the link is a sub-category of the current "page"/idea : [[>>:educational reform]] the ">>:" denotes that the wiki-link is a child of the page containing it.

Now, if you just searched for "educational reform" it will appear as:

WWII >> Occupied Japan >> Educational reform

Look at the source though, for THIS page, and u will see how its really accomplished. VERY ugly (verbose), very inneficient (can cause data to be lost and miscatagorized more easily):

[[WWII]] >> [[Occupied_Japan_Post_WWII| Occupied Japan]] >> [[Educational_reform_in_occupied_japan_post_wwII|Educational reform]]

Also, I think that every page should list it's parent(s) at the top. And that every page should list all the children that no-one has linked to at the bottom.

You'll probably want some sense of the "atomic parent" (something,according to this scheme, has no semantic parent), and this can be the set of carefully controlled main topics u have.

This approach is far closer to how human's think, and will result in a far more useful wikipedia, in my opinion.

Below is conversation about this:

  • Pardon me for saying so, but this is a horrible horrible idea. Categories of knowledge are not rigid and they are most emphatically not on a strict one parent -> many children relationship. Most of these children have multiple parents -- for instance your example can be rooted equally well in Japan and in Education, perhaps even in Reform... If you want to make rigidly hierarchical index pages, go for it, but don't pretend you can enforce it on the naming system without causing more pain. It most certainly is not "closer to how humans think", it's much farther away from it than an amorphous web of point-to-point connections. --Brion 10:45 Sep 23, 2002 (UTC)

    • Actually, A more careful reading of my page will show you that I indeed account for multiple parents per child. -hfastedge

      • Then you're creating a double nightmare -- multiple rigid hierarchical index schemes, all of which have mickel powers. What exactly are you gaining? --Brion 11:21 Sep 23, 2002 (UTC)

You gain the ability to have much less verbose links, so an improvement to the naming system. The structure of ideas that this exposes more explicitely is invaluable.

Battle of Hundred Regiments is a link that has way too much grammar in it. What happens if u want to write about the deaths at the battle? so u create a new link: deaths at Battle of Hundred Regiments[?] this is practically a sentance. And when u search for it, u'll simply get that page. Instead of something like:

[[WWII]] >> [[Battles]] >> [[Hundred Regiments]] >> [[Deaths]]

[[War Battles]] >> [[By location]] >> [[Asia]] >> [[Hundred Regiments]]

You see how much information u can get with this type of structure?? Now, a some good work needs to be done to avoid clutter...but thats what I think should be worked on.-hfastedge

  • When I look up "deaths at battle of hundred regiments" I would indeed expect to get exactly that. Maybe that's just me, though? --Brion
    • You do get exactly that, and far MORE...-hfastedge

      • And in exchange, much much more complicated linking syntax from outside the cozy land of parent and child. Unless you're not recommending the elimination of the horribly long complex names that you seem to be railing against in favor of much longer and more complex hierarchies? (And can you leave the page alone for 15 seconds? I can't save a comment without getting an edit conflict. ;) --Brion

      • It wouldnt be anything more complex than a real http style class=encyclopedia href. A new step in the editing process would be introdruced to resolve those links that don't lie in the cozy domain of parent/child ideas

        • Sorry to interject, but what your proposing with rigid nameing structures misses the point of the free flowing unstructured nature of a wiki. By introducing procedural complexities to something that attempts to illicit the spontaneous addition of new and revised information doesn't help. Besides in your example I would search for the root before the details, a good article will have links to the more detailed articles and your assimilating useful contextual information as you narrow your search field - you'll find it makes searching for stuff more efficient. -- Alex
        • hfastedge's response:
        • Sure, it misses the point of what wikipedia once was. But given how new the project is, there should be little pressure in maintaining status quo. As I described, debunked (and hence refined) the system within this thread, would not introduce a real change to the flow of wikipedia. And besides, you argue against the reduced spontenaity that my proposal brings, but I'm still for it, here's why:
          • Adding plain text to a document is still 100% as spontaneous
          • You must admit that there really is barely any learning curve.
And now, here comes the kicker (which I have been able to see all this time, but most of you havent, i assume. So first, remember how in my system, a search will give results that look like this:

[[WWII]] >> [[Battles]] >> [[Hundred Regiments]] >> [[Deaths]]

[[War Battles]] >> [[By location]] >> [[Asia]] >> [[Hundred Regiments]]

These two different results represent the search result ("Hundred Regiments"), but you get two results. These 2 results show the chain of parents all the way back to the root idea (i havent defined this search technique too well, but I/we will do that only when this gets the go ahed (which could be in 10 years, but it WILL happen somewhere/somehow)). Anyway, suppose u wanted to show the chain of parents within the current wiki system. Well, you have 2 options: you hire every university AI professor to work on the worlds best text extraction system thats highly complex and highly groundbreaking, OR, you use the "what links here" section to generate the results. Obviously, the 2nd choice is the option. But, immediataley, the chain of links will grow huge and unrelated and unmanageable.

So what I propose gives people the chance to affect these chains. Wikify will gain another meaning, which will be to refine the structure of the wikipeida. As i have been saying, this is very powerful. -hfastedge

      • New step in the editing process? No more complex than an http class=encyclopedia href?? Okay, this idea is officially bonkers. --Brion

And its not bonkers. Why do u think this? because its different? what do u think can be done to more efficiently resolve links that lie outside the cozy domain of parent/child.

  • repetitive, or ambigious arguments do not hold in this domain of logic.

  • Well, the second question ("what do u think can be done to more efficiently resolve links that lie outside the cozy domain of parent/child.") can be answered quite easily: by leaving the page titles as they are. But then the question of what is won by this proposal becomes even more pregnant. The only advantage that I have seen you state, is that on the search page you see the parent-child list instead of the page name. As a way of finding information, I see no real advantage in that (when I want information on the Battle of Hundred Regiments, I go to that page, I don't need to see it in the search page). As a writer, it is even a minus - I cannot see from the search page what the title of the page is, in case I want to link to it.
Furthermore, if you do not change the page names, the syntax already gets more complicated: Rather than [[>>:educational reform]], the link should be [[Educational reform in occupied japan post wwII|>>:educational reform]] (or maybe nowiki>[[Educational reform in *|>>:educational reform]]</nowiki> or something like that). If you do not want to do that, you'll have to accept that links in the future should go to [[wwii>>occupied Japan>>educational reform]], which is at least as complicated as what you are trying to avoid, and in fact more complicated (we have already renamed your page to educational reform in occupied Japan).Andre Engels 12:52 Sep 23, 2002 (UTC)

if wikipedia is ever going to scale, its going to need a way to deal with conflicts like these better, your plans?

  • CVS-like automatic merging with manual confirmation/correction has been suggested from time to time, and is doable whenever someone decides to code it. --Brion

My idea for wikipedia is far more outlandish: Change mozilla such that whenever an edit is registered with the server, the following happens:

  • take advantage of p2p to share the load of sending out the changes realtime.
  • have the changes reflected as colored text that fade with time

Pretty snazzy huh?

  • And do you turn away everyone who isn't using Mozilla? The Wiki markup is, by design, relatively simple and not browser-dependent. For better or worse, Mozilla-users are a minority. Vicki Rosenzweig

(I move this comment from my own Talk: page Andre Engels)

User:hfastedge obviously you are going to have to change names...simply let the users do this, the migration should happen over time. the focus is two fold:

  • simplify the linking process (which affects probably 30% on average of all links per page, but results in far more comprehensive linking eliminating the possibility and need to link back and forth.
  • provide a vast amount of new structured data that becomes N^N^^N times more usefull for searching and learning from wikipedia.

My reactions:
The linking process would in my opinion not get simpler, but more complicated - now you have to specify the page to link to, under your proposal either you have to specify the page and all its parents (if you move the page to some place depending on its parent), or for the parent you have to specify the page and the name under which it is a child.
Searching goes quite well as it is at the moment, the pages have names that quite well represent what they are about. If I want more extensive information, I go to the page itself, it's not what the search function is for, IMO. As for learning - if the information is on the page, then one can learn it from there. If it is not, I don't think people will give it to the scheme either.Andre Engels 07:13 Sep 24, 2002 (UTC)

you say "Searching goes quite well as it is at the moment"...and im going to repeat myself from above: ""You do get exactly that, and far MORE...""

Andre, you say that the linking scheme will be difficult, here's another refinement i just thought up. Simply assume that there is another stage to the editing procees (as i have been hinting at throughout this thread),then look at my newest revision to this idea for the syntax of a link:

[[clue | name]]

(remeber, linking to a child requires no effort).

Here's the breakdown of the syntax: first u give a textual clue for the semantic parents of the document,then u specify what u think is the actual name of the document.

then, in the link resolving stage, u choose from a list of possible matches to your idea (first the top ranking ones with a clue-match on the semantic parents clue, then the top ranking ones with a clue-match on their text.

Im not going to provide examples just to keep the idea-space a bit more open. Proceed with the debunking... -hfastedge

Re the plug for your software: you were right, I was wrong. I misunderstood how the general non-ad policy here applies, or doesn't, to personal pages. Sorry. Vicki Rosenzweig

As I am not on the list, please reply to me directly. Also, please dont waste your brainpower if your reply is solely to tell me that my idea is not for wikipedia.

Sure ;-))) Well, I see Wikipédia as a brain, and brains don't work the way you propose.

Brains work in a fractured and non-deterministic fashion. They are chaotic and of small knowledge. Wikipedia is not a brain. It has no cerebrum or hypothalamus and hence emotions, nor will it ever I can safely say.

My proposal is a VERY simple policy that will enforce a new style of structure. There are currently NO algorithms governing wikipedia's structure. My proposal is a very simple and clean beginning to semantically involving pages that have clear relationships. Languages have adjectives and nouns and adverbs and A WHOLE diversity of them, in my scheme, a semantic child is an adjective to its parent (noun). As wikipedia grows, I DO FUCKING NOT!! want to continue rely on a stupid vector-space-retrieval search model that barely has the ability to search for semantics. With SIMPLE initial conditions and policies about logistically handling semantic relationships in a way that increases productivity, wikipedia will be able to foster searchability at a very high semantic level.

BTW, did my message make it through to the list? or are you the list administrator that chose to reject it? Was there any talk of my message on the list? -Hunter

I'll read once again all this as soon as I have time, 'cause it made me thought of one thing. But your last question deserved a quick answer Hunter.
Yes, your message made it through the list. I am absolutely not the list admin (though I am the french list admin, but I - personally - don't reject any message from wikipedians, only spam and huge attachments :-). As far as I know, main list admins do just the same. I don't see any reason why it would be rejected.
No, there was not any talk about the message. The last few days have been very quiet, probably because the previous ones have been rather chaotic and ended up with people pretty nervous. It is also possible all interested people have already answered above, though I am not sure of that. May I suggest - perhaps - that you sent it to the wikitech list, as it seems to me more of a subject related for that list. Be aware though that I believe they have been rather busy this week end with vandalism issue. Choose your time wisely. And, yes, do consider joining wikitech list, it is not a very high traffic one, and that's the best way to discuss some issues.


All Wikipedia text is available under the terms of the GNU Free Documentation License

  Search Encyclopedia

Search over one million articles, find something about almost anything!
  Featured Article
Digital Rights Management

... the ability to copy and distribute documents can be used by the criminal as a means of preventing enforcement of laws against fraud and other wrongdoing. Since DRM is ...

This page was created in 24.6 ms