Copyright 2006 Tatsuhiko Miyagawa. Data collected from kantei.go.jp, analyzed using Perl with HTML::TreeBuilder, mecab and Text::MeCab.
なぜにゃらば、それはそうしないと使い物にならないからです。 Movable Type 3.3の標準のタグ機能でソートしたりリストの一部を取り出したりできないので困るという話は割とよく見かけます。 greenplastic.net: 未だにMT3.3へ移行できない理由 しかし、Compare PluginやCollate Pluginを使えば、そうした問題はごく簡単に解決できます。 Compare | Plugins for Movable Type | staggernation.com MT Extensions: MTCollate 1.1 大まかに言って、Compare Pluginはフィルター、Collate Pluginはソーター、という相補的な役割を持っています。例えば、タグやアーカイブリストのような大きなリスト構造があるとき、必要なアイテムだけを抽出するにはCompare、適
Posted by: Hirotaka Ogawa @ June 08, 2006 11:53 PM | Movable Type 3.3以降のタグに、いくつか便利機能を追加・拡張するプラグインを公開しておきます。今のところ、まだ3.3自体ベータテスト中なのでほとんどの方には恩恵はありませんけど。 TagSupplementals Plugin.ja JP - Ogawa Code TagSupplementals Plugin - Ogawa Code (English) Movable Type 3.3でタグ機能がネイティブ対応されましたが、標準で用意されているテンプレートタグだけではTagwire Pluginなどと比較して機能が不足しているため、不便を感じなくはありません。 TagSupplementals Pluginは、MT 3.3の提供するテンプレートタグに加えて「あったら
Posted by: Hirotaka Ogawa @ June 05, 2006 06:24 PM | エントリーの「キーワード」を、MT 3.3以降でネイティブにサポートされた「タグ」にコンバートするCGIスクリプトを公開します。 mt-keywords2tags.ja JP - Ogawa Code mt-keywords2tags - Ogawa Code (English) Movable Type 3.3以降では、ネイティブにTaggingをサポートするようになりましたが、それ以前のバージョン用に作られたTaggingプラグインの多く(Tags Plugin, Tagwire Plugin, Tags.Appなど)は、エントリーのキーワード欄をタグ入力欄として使用してきました。 このCGIスクリプトは、エントリーのキーワードをMT 3.3ネイティブなタグに変換することで、従来
Posted by: Hirotaka Ogawa @ March 16, 2005 02:37 AM | カテゴリーは鬱陶しい。Movable Typeや他のブログツールを使っていて一番腹が立つのはカテゴリーを設定する、まさしくその瞬間だ。そのインタフェースの悪さもあるが、文章を書くという曲がりなりにも知的な作業と、無理矢理カテゴライズするという非生産的行為とのギャップがひどく煩わしい。 「カテゴリー」に系統的に分類可能な情報というのも確かにある。が、それには対象が限定されている必要がある。ある時は映画評を書き、ある時はプラグインを公開し、そしてまたある時にはレストランの情報を書く。当然トップレベルのカテゴリーは雑駁とした羅列となる。それは果たして意味がある分類なのか、自分にとってあるいは読者にとって。 問うまでもなく意味がある分類などではない。では何なのだ? (分類することで自身を鼓舞
ウェブ検索に人間の視点を取り入れる 最近、テクノロジー関連のイベント--特にデジタルエリートの比率が高いイベントに参加した人は、そのイベントの「Flickrタグ」を告知している人の姿を見たことがあるかもしれない。 Flickrタグ--外国語のように聞こえるかもしれないが、ある意味でそれは正しい。Flickrは人気の高い写真共有サービスだ。Flickrのサイトにアクセスすると、登録ユーザーが投稿した5000万枚を超える写真のほとんどを見ることができる。ユーザーは自分が投稿した写真はもちろんのこと、他のユーザーが投稿した写真の大半にもキーワードを付けることができる。検索可能なこのキーワードは「タグ」と呼ばれ、Flickrをはじめとする急成長中のオンラインサービスに共通する大きな特徴となっている。 「Flickrタグがうまくいったのは、それが基本的に人と人とを結びつけるものだからだ」とFlick
1ヶ月間続けてみての感想・効果 2日間のファスティングを終えて、そのまま「じっくり基本プログラム」に移行して約1カ月がたちました。 この基本プログラムは、1日3食のうち1食をお嬢様酵素ドリンクに置き換えるというものなんですが、それに加えて私はさらにもう1食をお嬢様雑炊に置き換えてみました。 この雑炊が12食セット。それにプラスしておまけについてきたお嬢様パスタが3食分。というわけで、合わせて15食分ですから、このスタイルでの食生活を15日間続け、残りの半月は1食をお嬢様酵素に置き換えてあとの2食は普通食という形にしました。 ただ、時期的に忘年会、クリスマス、お正月といったイベントシーズンだったためにお酒もかなり飲んだし、食事の内容もかなりヘビーだったこともあって、残念ながら体重減はあまり結果が出ませんでした。 とはいっても、このヘビーなシーズンを、体重増加なしで乗り切れたという事自体がもう
「なまえとタイトル」の最後のほう、「対象が多すぎると、タイトル的な名前は機能しない」という項で、私は次のように書いた。 <「ファイル名はなくてもいいかもしれない」という話が出てくるのも、まさにこの状況だ。ファイルが多すぎて、どこにあるかわからなくなるような状況では、ファイル名の「説明」機能がそもそも果たせない。 そしてこれこそが、インターネットにおいてサーチやタグが浮上してきた理由なのだ。 これは重要なトピックなので、あらためて別エントリで書きたい>。 このエントリは、この話の続きだ。 ■インターネットという、「対象が多すぎる」世界 「対象が多すぎる」とは、この場合、「全部のタイトルをざっと眺める」ことすらできないくらい、対象が多い状況を指す。 インターネットが、この「対象が多すぎる」世界であることに疑問の余地はないだろう。 仮に、ネット上にある全ページのタイトルがどこかに列挙されていると
2.ビジネスリサーチの情報収集 デスクトップ調査 の基本〜アニュアルレポートなど公開情報から… デスクトップ調査 とは、主にインターネットなどを使用して、公開情報を調査して整理・分析を行うものです。「CIAも収集する情報の95%が公開情報」ということで、情報不足とい… 2021.01.28 2021.05.13 1915 view コラム〜リサーチャーの日常 人生を通じてマッチクオリティーを追求する 知識の幅が最強の武器になる という本で初めて知った「 マッチクオリティー 」という言葉は、経済学の用語で、ある仕事をする人とその仕事がどれくらい合っているか、その人の能力… 2021.05.04 2021.05.13 295 view 2.ビジネスリサーチの情報収集 日常的な情報収集・整理術(Feedly+Dropbox) 【 ビジネス 情報収集 と 情報整理 の基本 】いま目の前にあるリサー
Posted by: Hirotaka Ogawa @ June 30, 2005 10:23 PM | 0.10 (2005.03.19): AllKeywords Pluginを公開開始。 0.20 (2005.06.24): Tagwire Pluginに改名、英語ドキュメントとともに公開開始。 0.21 (2005.06.25): encode_urlplusフィルタを追加。 0.22 (2005.06.30): 目立たないバグを修正。 MT3.?の新しいプラグインインタフェースをサポート。 0.23 (2005.07.06): SQLiteを使っている場合に限り、PluginDataが重複してしまう問題を解決。 0.24 (2005.07.13): MTTagDateタグ、MTRelatedTagsコンテナタグ、MTXSearchTagsコンテナタグを追加。 PluginData
■ Folks+Taxonomy=“Folksonomy”~みんなで分類 Folksonomyという言葉をご存知でしょうか? これは「Folks(人々)」という単語と、「Taxonomy(分類学)」という言葉から造られた造語で、「みんなで分類する」ということを表している言葉だそうです。僕も今年の初めくらい聞いたばかりの言葉ですが、前々回にお話したWeb 2.0の議論の中でも、良く話題に上るテーマの1つのようです。 Folksonomy の表わす「みんなで分類する」は、単に情報の分類だけを“協力して”実現していきましょう、というように聞こえますが、実際は少々異なります。 例えば、Yahoo! JAPANには、決められたカテゴリ分けにより分類したディレクトリサービスがありますが、これは決められたカテゴリを決まった人たちで分類している、という点でFolksonomyではありません。また、「みんな
9割型のソーシャルタギング・サービスが、ユーザーインターフェースの模索をほとんどせずに、サービスの再生産をしているのは如何なものかと。 とか思ってみた前回の続き。 ソーシャルブックマークにおけるタグは、基本的にそれぞれの間に相互作用は存在しない独立関係にある。 具体例を挙げると、"Flash" タグ と "Macromedia" タグが存在した場合、"Flash"の持つ何かしらのパラメータ(例:登録数)が変化をしたり、あるいは"Flash" タグそのものが消滅をしても、"Macromedia"タグにはなんの影響もあらわれない。また、"Flash"タグも"Macromedia"タグも、自分以外のタグについての情報を持っていない。 しかし、このようなタグ構造は実装が簡単な反面、幾つかの問題点を持つ。1つは概念の内包構造が表現できない、例えばBlogというタグで検索しても、Movable Typ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く