遅い→起動時

http://d.hatena.ne.jp/pmint/

Wiki の検索結果:

例えばWikiEngineの、自動リンクのアルゴリズムのコード

…http://ja.wikipedia.org/w/index.php?title=" + word + @""" target=""ja.wikipedia.org"">" + word + @"</a>"); _t = t; } if (buf.Last().Item1 + buf.Last().Item2.Length <= body.Length - 1) Result.Append(body.Substring(buf.Last().Item1 + buf.Last…

例えばWikiEngineの、自動リンクのアルゴリズムの説明

…かち書きされてたならWikify @ appointment.atのやり方でもいいね。テキスト解析 - Yahoo!デベロッパーネットワークのように分かち書きにしてくれるWebサービスもあるし。でも今回は分かち書きせずにひと続きの長文を対象にする方法について。 以前と同じくn-gramを作るけど、今度は「そのn-gramが長文中のどこにあるか」を示す転置インデックスを作成する。 n-gram辞書のサイズが短文リストの十何倍とかになるけどね。28.5MB(およそ135万語)の短…

例えばWikiEngineの、自動リンクのアルゴリズム

いや、はてなキーワードの自動リンクでもいいんですけど。 d:id:pmint:20120424:p1の続き。 d:id:pmint:20130204:p2に続く。

新しいWikiEngineの自動リンク機能

自動リンクの試作。Wiki内のページ数が増えても使えるかどうかの試作。 ja.wikipedia.orgにある記事名をあらかた登録してあるので、フォームにウィキペディアにありそうな単語を打ち込んで「Preview」を押すと→自動リンクになる。 かかる時間はこの「枕投げ」の過去版をコピペすると解析まで5秒、出力まで含めると15秒でちょっと遅いくらい。 枕投げ - Wikipedia 空のページを登録してあるだけなので、それにリンクしてもつまらない。今はWikipediaの記事に…

新しい切り口を見つけたい

Wikiをアイデア創出に使うなら情報を集めてつなぐだけでは不足な気がする。 田原総一朗が言ってた。 「ジャーナリストの仕事は新しい事実か新しい切り口があれば商売になる」と。 これは「新しい切り口は新事実並みに価値がある」ということか。 データは誰かの解釈を経て情報に、外部から得た情報は自身の解釈を経てアイデアになるわけで。 切り口とはなんだろう 物事の一面に注目する、とか 「アイデアは既存の要素の新しい組み合わせ」と言われるけど、切り口とは違う気がする。 切り口とは物事の捉え…

構造化テキストスタイル

… lv3-abstract<br /> lv3-abstract<br /> </div> <div class="b"> lv3<br /> lv3<br /> </div> </div> lv2<br /> </div> </div> lv1<br /> lv1<br /> lv1<br /> </div> </div> </body> </html> 手書き線でも表現できるシンプルな修飾。 これをWikiのゆるい記法で使いたい。 順序なしリストで実現したほうがいいかな?

新しいWikiEngineの検索機能

Wikiのシステム作りの途中経過。codeなにがしに投稿していたサンプルの続編。 プロトタイプ03 X03.2011-12-08.zip VS2008Proj、C# 稼働中 http://x03.pmint.name/ 発想 WikiEngineは記法別の処理を行なうために、テキストを記法別オブジェクトに変換しているけど、もっと突き詰めればシンプルに曖昧検索を実装できそう。 → 記法別にEqualメソッドのような評価方法を用意。「5cm」や「10kg」、「2011/11/11…

idea:19649…の続き

…お題化したページへ Wikipedia的な。 日時について範囲指定する代わりに、1カ月ごと/1日ごと/1時間ごとに「みんなの最新エントリー」をまとめたページを用意するのも良いのではないだろうか。 時間軸で投稿を見られるページを新設する というのはカレンダーやスケジュール帳やテレビ番組表みたいな一覧なのだろうけど、この「日付のお題化」と近いだろうか。 お題×日付という複数条件でこういう一覧を作っても良さそう。 ズームイン/ズームアウト 表示する範囲を指定する機能。 指定された範…

書き込みは不用品

…のは再利用(引用)→Wikipediaなどがやってること。ゴミと違って「捨てられてる」わけでははいけど。 解体して再利用→他のブログなどを読んで言及。自分の書き込みに利用する。 分別→内容によって書き込む場所を変える。場所によって書き込まれる内容が違う。 リサイクルこれはまだ書き込みに例えられない。書き込みを集めて新しい書き込みを作るようなこと。テキストマイニング。ゴミ(資源物)を分別するのはリサイクルの方法がいろいろあるから。 「書き込みはゴミ」という例えは結構的を射ている…

Wikipediaの将来は…

Wikipediaの将来は「包摂」or「削除」にしかないのだろうか? | スラド IT というお題に反応してみた。/.Jにも投稿した記事の転載。 ほどほどに。人間が管理してるんだから。 まぁ最近はボットみたいに十把一絡げにして削除タグ貼る人間がいるけど。 残すのも消すのもどちらが良いかは言えない。だからWikipediaでは議論を必須にしてるんだろう。 でも議論が不十分なことが多いから議論に負けても(運営方針と照らし合わせて)まだ望みがあったりする。 いつまで経っても不十分な…

「パラレルWiki構想」をまた読んで

…4:parallelwikiの「パラレルWiki構想」を改めて読み返した。 以下はそのノート。 SVGや.mm(FreeMindの形式)もあるよ。 「パラレルWiki構想」を読んで(SVG) 20080311parallel.svg 「パラレルWiki構想」を読んで(FreeMind) 20080311parallel.mm 従来のWikiよりもWeb 2.0の要素にあっているように思う。というか、WikipediaがWeb 2.0の提唱に含まれているのはただ単に「なんか新し…

ハイクでソーシャルメモ

…ただ集めただけなのがWikiと違うところ。2ch的でゴミの埋め立て地的かも。 はてなハイクでは大喜利が盛んだけど、自分のページ("id:"で始まるお題のページ)はTwitter的に使えるし、id:jkondoさんだって何でも可だと言ってるし*1。 というわけで「なにかのヒント」というお題を振ってみる。 ノンジャンルかつお手軽な感じのお題。 誰でも自分のネタ帳として使ってもらえるように。 元々は「h:id:pmint」にハイクして、dのプロフィールページ*2の広いスペースに表示…

「いいソフトウェア」の作り方

pukiwikiのようなものについて質問です。 Pukiwikiを使用しておりますが、しばらく更新がとまっているようなので 新しくpukiwikiに代わる物を探しております。 似たような機能をもったものがあれば教えていただければと思います。 更新が止まっているのは欠陥が無いからです。 ありがちな誤解で「バグフィックスを繰り返しているソフトほど優れている」というのが無いだろうか。 もう少し一般的にすると「バージョンアップの頻度が高いほど優れている」なんだけど、利用者にはバグフィ…

ペイントツールのアイデア、まとめています

こんなペイントツールがあったらいいな Wiki* http://wikiwiki.jp/pmint/ 「ペイントツール」という記事はWikiに移しました。 場所は以前「ウィキエンジンX」を置いていたところ。(WIKIWIKI.JP)

visitedを強調

UI

…」や「記事の一覧」、Wikiの「新規ページ作成」などは何度もクリックするもの。 でも使わない人は全く使わない。邪魔なだけ。 だから、こういうリンク*1では、通常目立たせず、クリック後に目立たせるほうがいい。使う人は何度も使う。1度使ったら2度目、3度目もあるはず。 特に、メタファをうまく取り入れられていないアイコンはvisitedリンクを強調すべき。 例えばPukiWikiのアイコンとか。「最近の更新」と「検索」の区別が難しいとか、横一列に並んでいるのにあまり使わないものとよ…

はてなハイク…の続き

…クマークがストック型で、はてなハイクがフロー型。 あるサイトやページについて討論するのに良さそう。 「はてなダイアリー」や「はてな匿名ダイアリー」や「はてなグループ」の日記だと「1対大勢」の形になるかと思うけど、ハイクなら表示される投稿が下へ流れていくので「1対直近のいくつか」ぐらいになるんじゃないだろうか。 討論するならハイクのようなチャット感覚は大事。 ストック型でなおかつ「ログを読め」的な雰囲気だとWikipediaのように前例に縛られて前進できない討論になってしまう。

Wikipediaの管理者クラス

Wikipediaの運営はボランティア。 だからこその限界があるはず。 例えば本業にできないこと。 → リアルで時間をもてあましている。 リアルで仕事に追われていない。 …者にしか務まらないのではないか。 つまり、管理者が務まるのは大学生やニートだろう。 管理者になる条件に編集頻度の高さがあるので、時間のない人は管理者になることさえ不可能。 Wikipediaは管理にかかるコストを小さくできなければ、Web2.0的サイトのようにはなれず、規模の大きさに限界が来るだろう。 さら…

勝手にWiki化

App

…ば「あらゆるページのWiki化」。 ただ落書きをするだけのシステムじゃなくて、履歴を取って利用者同士で保守しあえるようにして。 現状でもソーシャルブックマークでどのページにもコメントすることはできる。 でも表示はソーシャルブックマークを提供するサイトで、ブックマーク一覧としてのもののみ。 利用者側からすれば、コメントを「ブックマークされた側のサイトに重ねて表示する」ソーシャルブックマークのようなもの。 コメントを表示する場所は本物の被ブクマサイトでなくても、そのサイトのコピー…

Wikipediaで学力調査

App

Wikipediaにある知識の出典はほとんどWeb上から。つまりWikipediaの実態はWebのまとめサイト。Googleと競合するかも知れないが、検索結果が多いページだけを扱う点は異なる。 Wikipediaの運営は自由参加の利用者によるので、国別で読み書き能力の比較をするのに使えるのではないだろうか。 以前、Wikipediaはブリタニカと比類できるという話があったけど、それはen.wikipedia.orgの話。 Wikipedia日本版は既存の事典と比較できるだろう…

自動リンクには手間がかかる

Wikiの自動リンクは「自動リンク」というより「半自動リンク」。何をリンクするか明示*1しなければならない。 これでは「書き散らしたことが自動的にまとまる」とはいかない。 人的資源が必要。 一人で使うとなると手間がかかってしょうがないので、検索キーワードを自動的にページ化する機能でもないとアイデアノートにはしづらい。 とは言っても他の方法と比べると格段にWikiのほうが良いわけだけど。 検索キーワードから自動的にページを作るとなると、そうやって作ったページを自動的に削除する機…

「/」は「の」

「プロジェクトの名称」というページを作るくらいなら「プロジェクト/名称」を作ったほうがいい。 なら、日本語向けのWikiではパス区切りを「の」にしたほうが良いのではないだろうか。 さらに、「プロジェクトの名前」というページを作ると プロジェクト プロジェクト/名称 という2つのページが一度にできるように。 自動リンクを発生させるためにページは多くしたい。

読解力

App

…章を活用するには読者の読み解く力が必要。 別に各人が完全な読解力を持ち合わせていなくてもいい。 Wikipediaで衆愚の集合知を作れることが分かっているので、どこのサイト/ページについても読解のための情報や意見を集めることができる。 そんなサイトは無いものか。 「ニコニコブックマーク」というサービスや、「炎ジョイ」というサービスでできる可能性があったが、コンセプトが違った。 誰かこの手のシステムで「半端な情報を補完して、ネットを充実させるためのサイト」を立ち上げないものか。

管理者は必要か?

…らない。 そうならないシステムがある。Wiki。 閲覧者数が十分にあれば個人管理からWiki的管理に切り替えられるシステムというのはどうだろうか。 管理に関する権限全てを閲覧者に与えなくても削除できるだけでいい。 表には出さない(奥に隠すだけで閲覧は可能)というWiki的な削除を。 有名人の個人運営とか、サイトが有名になってコメントが増えたら個人運営なんてとてもできないはず。 SPAMが多いということはそれを読む人も多いということ。それに対して管理者が1人というのは分が悪い。

活用法品評会

App

…とをボタン1つで半端に実現する手のものが散見される。 世の中でソフトウェアが活用されていない証拠。 用途 使用するアプリ 手間(アプリを普通に使うだけ、マニュアルにない使い方をする、マニュアルにない設定が必要、プログラミングを要する、など) …などで分類して。 システムはWikiが適しているだろうか。投稿には… 文章 リンク スクリーンショット 動画 …などを貼れればいい。表記の正確さはWiki的なシステムで校正していける。 d:id:pmint:20071021に関連記事。

URIを付けるべき

ページにURLを付けるよりもモデルにURIを付けるべき。 そして、モデルは関わってるページ上で名乗ること。 ページのURLはページ内で主役になっているモデルにちなんだものに。 というか、URIを渡されるとそのモデルが中心になっているページを生成するという発想で。 URI→URL対応表をフレームワークが保持するような設計に。 SiteConfigWikiのPixiv部分を編集していて思った。

メモの書式…の続き

…。 あとで自分の記憶が薄れても分かるように、一般的な表現や自分の中で薄れないであろう表現に。 検索しやすくするため、用語や表記の揺れの統一もする。 統一すると意味合いが変わってしまう場合は、括弧書きで別の表現を付け足す。 メモ1枚ずつにSEO対策を施す。 …といったことを負担にならない程度に行う。 決して他のメモを調べてまで統一/校正したりはしない。校正した結果が最良という訳でもないし、もっといい表現を思いつかない訳もない。 そういった深い校正は追々やっていく。Wiki的に。

情報に尾ひれを付けて流す

App

…ど、改変・再配布にはWiki的な利点もある。 日本語の曖昧な言い方と察する聞き方。 同じソースでも人によって違った解釈になるかも知れない。 違った解釈→都合のいい解釈、偏見の入った解釈。 都合のいい解釈は悪い意味に取られがちだが、良いこともある。 都合良く解釈→良い方向に。 そもそもそうでなければ個人が情報発信することなんてできない。 そうでなければ個人に大衆が踊らされることに。例えば「Web屋のネタ帳」。 都合のいい解釈ではなく、偏見が入ると困る。 誤解、それも悪い誤解、わ…

Wikipediaって全ページに引用で作らなきゃいけないと規定しているくせに

Wikipediaって全ページが引用で作らなきゃいけないと規定しているくせに、引用だけで作ったページは削除してるんだよな…。 だって「要出典」でしょ? 建前は「すべての記事に出典を明記すること。転載は禁止」だけど、言葉の意味を調べればそういうことだ。 Wikipediaユーザーって頭悪いのかな? それとも国語力が無いのかな?おかしな文章が散見されるし。 きっと国語力のほうだろうな。おかしな文章が散見されるし。 ああ、そうか。 1つのサイトからの引用だけで記事を作るのはダメって…

target属性

UI

Wikiやブログなどで参考文献などのリンクを列挙するとき、新しいウィンドウで開くようにしているケースが多い。外のサイトはすべて新しいウィンドウで開くようにしているようだ。 前後関係のあるページを列挙するなら、同じウィンドウで開いて「戻る」と「進む」が使えた方が便利なのではないだろうか。 ファイル名に付いている番号以降を除いて、それをtarget属性にすればいい。 ただ、履歴では開いた順とは逆の順番になってしまうけど。 http://x.pmint.name/prototype…

「Wikiの文法なんて覚えるものじゃない」

「Wikiは特殊な文法が分かりにくい。あれは良くない」と言う人がいる。 GUIを持つWikiEngineを過大評価。 曰く「ボタンを押すだけで文字装飾を変えられる」。 もともと行頭に*を打つだけでリストになるようなUIなのに、わざわざマウスでボタンを押すような真似がどうして「押すだけで」などという表現になるのか。*1 「章には『§』を付けるとか、引用は「」で括るとか、文末には『。』を付けるとか、そんなルールはいちいち覚えていられない」と言っているのと同じ。君はアホなのか? […