履歴もしくは日誌

foaf.jp と FOAF 流通プラットフォーム

FoaF Explorer を運営しているサーバに FoaF Tools っていうページがあります．そこには FOAF Explorer などからデータを収集した New Foaf URIs っていうリストがあります．それの RSS が配信されているので，利用していました．

• FoaF Tools
  http://xml.mfd-consult.dk/foaf/

したら，foaf.jp っていうのが New Foaf URIs にリストされました．RSS が rss-jp.net なら FOAF は foaf.jp か！ってことでどんなだろうと foaf.jp にアクセスしてみました．

foaf.jp は現在のところ，まだ準備中ってことかな．New Foaf URIs にリストされていたのは RSS ベースのいわゆるアンテナであるの RNA が生成した FOAF ファイルでした．そう，RNA では FOAF 生成機能を開発中なんですね．

• rna - RSSベースのアンテナ「RNA」
  http://www.semblog.org/wiki/?rna

semblog-dev では，近々 FOAF 流通プラットフォームについて何かしらアナウンスがあると予告されていたんですが，これなのかなぁ．

@nifty の TypePad のサービスが始まる 12 月 2 日までに，公開してほしいなぁ．

TrackBack

@nifty の Weblog サービスと FOAF

11 月 21 日の発表以来，@nifty が米 Six Apart Ltd. と提携して，12 月 2 日から Weblog サービスを提供するというニュースがあちこちで取り上げられました．TypePad という Weblog サービスをカスタマイズして提供するのですが RSS とか FOAF などが TypePad の基本機能として用意されています．

TypePad が FOAF 自動生成の機能があるってのは kota さんのはてなダイアリーを見て，初めてしりました．たしかに個人のプロフィールを書くという行為自体は，一般に受け入れられそうで，FOAF の普及が進みそうで期待してしまいます．

• RSSの次はFOAFが来るのか / はてなダイアリー - in the vanguard
  http://d.hatena.ne.jp/kotastyle/20031127#p3

ところで個人が Web ページをやりたいと言うときに，典型的なコンテンツがいくつかあります．

• 日記 もしくは Weblog
• 掲示板
• 写真のアルバム
• リンク集
• 自己紹介/プロフィール

そして TypePad は Weblog と自己紹介の部分ができるそうです．写真アルバムのような機能もあるのかな．

そうなると，個人がホームページビルダーのようなツールを使って，HTML を編集したりしなくても，インターネットサービスプロバイダが提供するサービスでひととおりそろえることができるという事ですね．

参考 URI：

• 日本語市場向けWeblogサービスを展開 / @nifty
  http://www.nifty.com/corp/release/20031121_1.htm
• TypePad Feature List
  http://www.typepad.com/features.html

TypePad の機能リストの Technical Features には，いろいろすばらしい機能がリストされてます．

FOAF Generation

自己紹介(プロフィール)と友達リスト

XML Syndication

RSS の配信

XML-RPC (API) Support

TrackBack とか Update Ping 送信とか

Valid XHTML compliant pages

正しい XHTML のページ

Semantically rich search-engine-friendly markup

意味づけとしてのXHTML のタグ付け，かつサーチエンジンから検索されやすい XHTML のタグ付け

CSS-based layout

スタイルシートによるレイアウト

FOAFとか正しい XHTML なんてのは，一部のマニアしか喜ばないのかもしれませんが，あまり技術に興味がなくても，FOAF が自動生成されたり，正しい XHTML でページができたりするのは実はすばらしい事だと思います．
他のインターネットサービスプロバイダにも追従してほしいものです．

TrackBack

FOAF でグループメンバーを紹介

Cycling.jp というグループのメンバーを紹介する FOAF を記述しました．いろんな事柄の意味を記述する方法として RDF があり，RDF の応用として自己紹介や知人を紹介する FOAF があります．具体的にはタグで構造化した XML として記述しました．

Mac OS X 用の RDFAuthor という RDF のエディタを使って，グラフを表示して確認しながら作業しました．RDFAuthor の図の表示は面白いです．なんか RDF が分かった気になりました．

• RDFAuthor
  http://rdfweb.org/people/damian/RDFAuthor/

今回は RDF を独立したファイルにしないで，XHTML に埋め込んでみました．Media Type は aplication/xhtml+xml にしましたが，それに対応していないブラウザに対しては text/html で返します．

加えて RDFAuthor でのグラフを object 要素を使って埋め込みました．基本を SVG という画像フォーマットにして，その代替として GIF 画像ファイルも埋め込みました．画像を表示しない環境では RDF を N-Triple という形式のテキストで表示するようにしてみました．

Internet Explorer は，できが悪いからグラフの表示がおかしくなるようです．

FOAF Explorer でも FOAF として表示できました．

• メンバー紹介 (FOAF) / Cycling.jp
  http://www.cycling.jp/members.xhtml
• FOAF Explorer
  http://xml.mfd-consult.dk/foaf/explorer/

TrackBack

はてなアンテナとファイルが見つかりませんエラー(404)と正体不明のロボット(2)

10 月 24 日付けで，はてなアンテナからのリンクを間違って解釈する WWW User Agent が存在して，リンクされている側には，ファイルが見つかりませんエラー(404)が残されるという問題についてです．これと同じ事が「blog.bulknews.net: はてなアンテナのリンクURL」でも書かれていました．その記事では googlebot が失敗しているとありますが，ぼくが確認した者は googlebot ではありませんでした．少なくとも複数の WWW User Agent でうまく行かないのでしょう．

はてなの近藤さんからはちょっと考えてみますってコメントされています．単純に「http://a.hatena.ne.jp/go?http://example.com/20031211231111」となっているののgo? の後の「http://」を無しにすれば良いと思うのですが，なんか難しいのかな．

• (10 月 24 日) はてなアンテナとファイルが見つかりませんエラー(404)と正体不明のロボット
• blog.bulknews.net: はてなアンテナのリンクURL
  http://blog.bulknews.net/mt/archives/000578.html

TrackBack

adding RDF to photo gallery

「dive into mark」で，photo gallery に RDF を加えるという記事が出ていました．RDF は RSS 1.0 として書いてありました．ぼくが先日書いたように，item 要素の rdf:about 属性で，画像ファイルの URI を指して rss:link 要素で Web ページの URI を指しています．でも foaf:page はありません．

• See also: chocolate mousse [dive into mark]
  http://diveintomark.org/archives/2003/11/25/mousse

<item rdf:about="/photos/2003_11_23_birthday/images/IMG_0016.jpg">
  <title><title/>
  <link>http://diveintomark.org/photos/2003_11_23_birthday/IMG_0016.html</link>
  <foaf:thumbnail rdf:resource="/photos/2003_11_23_birthday/thumbs/IMG_0016.jpg"/>
  <rdfs:seeAlso rdf:resource="/photos/2003_11_23_birthday/IMG_0016.rdf"/>
</item>

He wrote URI of HTML pages in link element. It seems that he can add foaf:page element for HTML page URI.

<item rdf:about="http://diveintomark.org/photos/2003_11_23_birthday/images/IMG_0016.jpg">
  <title><title/>
  <link>http://diveintomark.org/photos/2003_11_23_birthday/IMG_0016.html</link>
  <foaf:page rdf:resource="http://diveintomark.org/photos/2003_11_23_birthday/thumbs/IMG_0016.html"/>
  <foaf:thumbnail rdf:resource="http://diveintomark.org/photos/2003_11_23_birthday/thumbs/IMG_0016.jpg"/>
  <rdfs:seeAlso rdf:resource="http://diveintomark.org/photos/2003_11_23_birthday/IMG_0016.rdf"/>
</item>

foaf:page も利用したほうが良いでしょうね．

関係する話題：

• RDF による画像メタデータ

TrackBack

携帯電話からの「履歴もしくは日誌」へのアクセス

「履歴もしくは日誌」へ iモードなどの携帯電話からアクセスしたときの表示を，記事ごとに別々に表示できるように工夫してみました．

でも記事が長いと全部を表示できません．

これは簡単に解決できないなぁ．

HTML/XHTML を iモードなどの携帯電話用に変換する CGI をかなり書き換えないとだめみたい．他にもいろいろ問題あるし．

TrackBack

RDF による画像メタデータ

RDF による画像メタデータを作成する事を考えています．とりあえず，画像アルバムのページを作って，それの画像ファイルのメタデータなんかを試しに作ったりしてきました．今回は，また違ったやりかたを試してみました．

画像アルバムのページのメタデータを RDF で書く場合，RSS 1.0 を使うと良いです．
その時に item が指すのが，画像ファイルそのものにするか，画像ファイルを表示する Web ページにするかが悩むところ．
RSS リーダなどでそのまま使うには，rss:link 要素は Web ページを指していたほうが便利でしょう． でも画像ファイルのメタデータを記述するなら rss:item 要素の rdf:about 属性の値は画像ファイルの URI のほうが良さそうです．

神崎さんのページでも，RSS の記述で 2 通りの例を示しています．

• FOAFとRSSを用いた画像メタデータ -- Image description with FOAF and RSS
  http://www.kanzaki.com/docs/sw/image-rdf.html

通常 RSS 1.0 では rss:item 要素の rdf:about 属性の値と rss:link 要素は同じ URI を指しますが，これをあえて違う URI を指すことにして，rss:item 要素の rdf:about 属性の値は，画像ファイルのメタデータを簡潔に表現できるように画像ファイルの URI にし，rss:link 要素は，RSS リーダで使いやすいように画像を表示する Web ページの URI にしてみたらどうでしょう．
これについて，神崎さんから，rss:link 要素の中身はリテラルなので，RDF としては意味が無いから，foaf:page などで Web ページの URI を指すと良いとアドバイスをいただきました．ありがとうございました．

で，試しに以下の RSS と Web ページを作りました：

Web ページ

http://onohiroki.cycling.jp/PhotoAlbum/2003-08-31_CrusoePetite/

RSS 1.0

http://onohiroki.cycling.jp/PhotoAlbum/2003-08-31_CrusoePetite/rss.rdf

この RSS 1.0 をいくつかの RDF をレンダリングするプログラムに読み込ませてみます：

• RSS Feed Reader / The Web KANZAKI
  http://kanzaki.com/test/rssfr
• FoaF Explorer
  http://xml.mfd-consult.dk/foaf/explorer/
• Syndication Subscription Service
  http://xml.mfd-consult.dk/syn-sub/

それぞれでうまく機能している事が確認できました．このような記述の仕方をすると画像ファイルのメタデータを記述するのに簡潔で，しかも RSS リーダなどで読み込んだときも使いやすいと思います．
でも後になって考えてみると，メタデータの記述が複雑であっても，プログラムが自動生成してプログラムが解釈するのであれば，なにも問題ないのではないかと...

その他の，このトピックスに関連するページ：

• SwPhotoAlbum / 画像アルバム
• 履歴もしくは日記から RSS について
• 履歴もしくは日記から FOAF について

TrackBack

RDFAuthor

RSS 1.0 とか FOAF などの RDF を自分で記述するときに，要素と要素の関係などが良く分からなくなったりします．
特に人の書いたものをまねしてみて，うまくいかないときに，RDF のソースを見比べても原因が分からなかったりして．
RDFAuthor というエディタを使うと，RDF の構造が図で表現されてとても良いです．

• RDFAuthor
  http://rdfweb.org/people/damian/RDFAuthor/

RDFAuthor は Mac OX X 用です．Java Swing の環境で動くバージョンも配布されています．

TrackBack

「おりたたみじてんしゃ」表記方法と検索エンジン

折り畳み自転車の表記は実は「折りたたみ自転車」と，「たたみ」はひらがなというのが一番普及しているようです．少なくとも Internet の Web コンテンツでは．
いろいろと Google で検索してみました．

順位はぼくが書いたページが検索結果の 10 位以内の場合の順位で，上位 10 位に入いっていない場合は圏外としました．

コンピュータの話題とか多いですけど，かなり絞り込まないと，ぼくが書いたページなんて Google では検索されません．まぁやっぱり自転車の Web サイトって事でいいのかな．でも「折り畳み自転車」が主なコンテンツなんていうのは，Web サイト内のコンテンツの充実度からも検索結果からも言えないかもなぁ．

TrackBack

セマンティック Web について

CNET Japan に，「セマンティックWebについての誤解と真実」という記事が載りました．コメントしてみます．

• CNET Japan - 江島健太郎 / Kenn's Clairvoyance：セマンティックWebについての誤解と真実
  http://blog.japan.cnet.com/kenn/archives/000845.html

江島健太郎さんは，従来の HTML の Web と，セマンティック Web について，以下のようにとらえているようです．

• HTML が広まったのは，意味付けや解釈に多様性があること．表現の自由度や面白さを優先してきた事が，理由になっている．
• HTML の Web に対して，セマンティック Web は，意味付けが標準化され，解釈が一意に定まる．表現の自由度や面白さという点では死んだようなものである．セマンティクスの標準化というものは「表現の墓場」である．

HTML や Flash などのコンテンツに，コンテンツの意味を記述したメタデータを付加する事が，Web 上の表現の自由度を制限するような事はないでしょう．表現したい事はコンテンツで表現して，それの意味をメタデータで示すのです．その時に意味とは行っても例えば小説がコンテンツなら，批評とか解説にあたるものをメタデータにしろという事ではなく，作者とか出版社とかあらすじみたいな者をメタデータとして準備しようという話です．どうしてセマンティックスの標準化が「表現の墓場」という話になるのでしょうか．

またセマンティック Web でメタデータを記述する道具としての RDF では，基本的な大枠を決めて，細かい意味付けは語彙を別に定めるということになります．RDF の応用として最も普及しているのは RSS 1.0 でしょう．RSS 1.0 では，RSS 1.0 の語彙が定められている訳です．
いろいろと語彙を決めて行くことで，RDF はとても柔軟に使えると思います．

なんでもむやみやたらにセマンティクスの標準化をしてしまおうというものではなかったはずです．

• コンテンツの表現にメタデータを付加することは，コンテンツの表現を制限する事はないでしょう．
• RDF では，語彙を別に定義することになり，それはとても柔軟で自由度があると思います．

また江島健太郎さんは，Web のコンテンツを，雑多で有効期限が短い「イベントデータ」と，「熟成され洗練されたもの」の二つに分けて考えているようです．

そして，雑多で有効期限が短い「イベントデータ」は，Internet 上にどんどん蓄積するよりもむしろ，古いものから破棄することが必要なのではないかと問いかけています．

ぼくはインターネット上の古いコンテンツは，コンテンツを公開している側の事情が許す限り，永続的に公開される事を望みます．

検索エンジンでは価値のあるページが上位に表示されるように工夫されるようになって来ています．それだけでもある程度機能していると思います．

コンテンツの内容だけでなく，コンテンツのメタデータも評価して検索エンジンが重みづけをするようになれば，例えば最近公開されたコンテンツや最近更新されたコンテンツからリンクされているコンテンツはより上位に表示されるというような仕組みも実現できるでしょう．古いコンテンツがどれほど邪魔になるのでしょうか．

Google が文書間のリンクの状態を評価しているというのは，文書のリンク情報をメタデータして抽出/評価/管理しているっていうことでしょう．Google 以前のコンテンツ内でのキーワードの出現回数などで評価していた検索エンジンよりも，文書間のリンク関係というメタデータを評価した Google の方がよりよい検索エンジンとして使われるようになったのです．もっと豊かなメタデータが利用できるようになれば，検索エンジンはもっと良いものになるでしょう．

インターネット上の全てのコンテンツが，意味付けされたメタデータを持つようにはならないでしょう．新しいコンテンツの一部が意味付けされたメタデータを持つようになるでしょう．それの有用な利用方法が示されれば，利用は広まっていくでしょうし．ある時期にメタデータを有効に利用する有力な検索エンジンが登場すれば，それ以降は SEO (検索エンジン最適化) なんていう分野が，強力にセマンティック Web を推進して行くのかもしれません．

もちろんコンテンツ制作者がいちいちメタデータを記述していたら大変ですが，これからはコンテンツ制作ツール側でメタデータもある程度自動的に生成できると思います．ツール側でメタデータを自動的に生成して，利用されている例が Weblog ツールが生成する RSS 1.0 ですね．

セマンティック Web のコンセプトでは，より広がって行く Web をぼくらがうまく利用できるように，コンテンツにメタデータを用意しておこう，メタデータの記述の仕方を標準化しよう，そういう提案がされているのだと思います．

コンテンツ作成ツールがメタデータを生成する時に，コンテンツ制作者にもある程度の手間を負担させることになりますが，HTML においての title 要素を書くとか img 要素で alt 属性の値を書くとかの手間と大差ない程度になるんぢゃないでしょうか．

TrackBack

RSS と HTML 文書のメタデータ

RSS は Rich Site Summary または RDF Site Summary などと言われているもので，サイト情報の要約を公開するものだとされています．実際はニュースサイトや個人が発信する記事の要約もしくは記事そのもの配信に利用されて，勢いづいているようです．

サイト情報の要約と考えると，静的なコンテンツの要約を表現することも範疇に入るでしょう．でも実際は，日々更新される記事の配信が主な用途のようです．でも RSS 1.0 は RDF でメタデータを記述するという意味で使いやすくて，いろいろ可能性があると思います．将来 RDF が有効利用される事を考えたら，なるべく多くのコンテンツのメタデータを RDF で用意しておきたいのですが，とりあえず RSS の利用から始めるのが良いのではないでしょうか．

RSS を利用している多くのサイトでは，日々更新されるような記事の最新のいくつか記事についてだけ RSS でメタデータを用意していて，古い記事のメタデータや，静的なコンテンツのメタデータまでは用意していないのではないでしょうか．

• RSS を動的なコンテンツのメタデータに利用する場合

  目的

  記事の要約の配信もしくは記事の配信

  HTML 文書の link 要素の書き方

  <link rel="alternate" type="application/rss+xml" title="RSS"
  href="http://onohiroki.cycling.jp/info/weblog.rdf" />

  RSS auto-discovery / dive into mark
  http://diveintomark.org/archives/2002/05/30/rss_autodiscovery

• RSS を静的なコンテンツのメタデータに利用する場合

  目的

  HTML 文書のメタデータとして

  HTML 文書の link 要素の書き方

  <link rel="meta" href="http://onohiroki.cycling.jp/info/weblog2002.rdf" />

  link要素で外部文書との関係を示す / The Web KANZAKI
  http://www.kanzaki.com/docs/sw/html-meta.html#link

というわけで，最新の情報を配信するための RSS の他に，あるコンテンツのメタデータを表す RSS を別に用意してはどうでしょう．一つの文書が，いくつかのパートによって構成されていたら，それらのパートを RSS のチャンネルとしても良いでしょうし，別に item 要素が一つしかない RSS でも良いと思います．HTML の中にコメントとして RDF を埋め込むような手法の代わりに，一つ一つの HTML 文書にメタデータを記述する RSS を用意するのです．

そうでなければ，いくつかの文書のグループに対して，一つの RSS を作成しても良いでしょう．

もし古い HTML 文書で meta 要素がしっかり書かれていれば，プログラムによって生成する事もできるかもしれませんが，とりあえず新しい文書を作るときに，同時に RSS も記述してみてはどうでしょう．

でも実際は，RSS って手書きで書くのは面倒ですね．

日々記事を更新していて，RSS は提供しているけど古い記事の RSS までは残っていないという場合は，古い記事の RSS も蓄積できる仕組みを考えてみてはどうでしょうか．

TrackBack

TrackBack と RSS について

ひとつの記事に対してコメントする時に，その記事を示す恒久的な URIと，TrackBack Ping 送信先 URI の二つを管理するのはちょっと嫌だなって思います．記事の恒久的な URI から TrackBack Ping 送信先 URI が自動的に導きだされるなら良いのですが，あまりうまい方法は無いようですね．TrackBack Ping 送信先 URI の情報を RDF で記述して，それを HTML のコメントとして XHTML に埋め込むなんてのは，かっこいいやり方だと思えないですし．

RSS 1.0 に自分の書いた記事へ TrackBack Ping を送信してもらうための URI をトラックバックモジュールの ping 要素で記述しておくのは良いと思います．HTML のコメントとして HTML に埋め込むよりずっと良いです．

でも，トラックバックモジュールの about 要素として，自分が TrackBack Ping を送った URI を記述するのは，有用なのかどうか疑問です．TrackBack Ping を送った URI を RSS 1.0 の中で記述するよりも，TrackBack した記事そのものの恒久的な URI を記述したほうが有用でしょう．

semblog の in とか out とかは，そういう意味で自然な考えた方だと思いました．

神崎さんが解説している、Dublin Coreの 精密化要素 で定義されている references，isReferencedByを使うのも良いと思いました．

• semblog-dev: RSS拡張の試み
  http://www.semblog.org/i2k/archives/000210.html
• semblog-dev: RSS拡張の試み（その2）
  http://www.semblog.org/i2k/archives/000216.html
• semblog-dev: RSS拡張の試み（その3）
  http://www.semblog.org/i2k/archives/000217.html
• Dublin Coreによる参照、被参照関係の記述 / RSS とトラックバック
  http://www.kanzaki.com/docs/sw/rss-trackback.html#dcterms

本当は TrackBack Ping の送信先は，あるサイトとか Blog につき 1 つの URI で，TrackBack Ping の中に，個別の記事の URI を含めるのが良かったのではないかと思います．そうすれば，RSS Autodiscovery の様に HTML の link 要素で Ping 送信先を示しておけばすっきりすると思うのです．

また今後は様々なメタデータを RDF などで用意することを考えたら，XML-RPC のような仕組みで，パレメータを与えてリクエストすれば，求めるメタデータの URI が返ってくるような仕組みが標準化されると良いのではないかと思います．

そして，Track Back Ping を送りつける本来の対象とは別に，Update Ping のように，どこかのサーバに TrackBack Ping を送信すると，そのサーバで，記事と記事との言及の関連を蓄積/管理できるようにするとか．

つまり TrackBack するときに，相手のサイトだけでなく，ping.bloggers.jp のようなところにも同時に Ping を送信しておくと，ping.bloggers.jp のようなところで，記事と記事の関連の情報を蓄積すると．そういうことをしないと RSS の TrackBack モジュールってあまり意味無いのかな．

現状のように，TrackBack Ping 送信先 URI で管理していくと，その TrackBack Ping 送信先 URI から，TrackBack された記事そのものの恒久的 URI を追跡するのが面倒ですよね．

現状でなら，ping.bloggers.jp のような RSS を扱うサイトが，Update Ping を受け取ったら，Update Ping 送信先のサイトの RSS にアクセスして，そのなかから，各記事の言及先 URI とか TrackBack Ping 送信先などを解析して蓄積するのがいいんでしょう．

その時に，解析するのは RSS の TrackBack モジュール，dcterms:references 要素，rss:description 要素の内容，content:encoded 要素の内容にすればいいのかな．rss:description 要素の内容，content:encoded 要素の内容から URI の文字列を抽出する理由は，そうしないと一般に使われている RSS を解析しても十分に機能しないかもしれないと思うからです．

• RSS (RDF Site Summary) について，見出し一覧

TrackBack

Web ページと RSS の関係 (3)

kota さんが「はてなダイアリー - in the vanguard」に，ここ数週間に話題にしていた RSS と HTML の関係についてまとめています．ぼくもそれに応えてまとめてみます．

• とりあえずここ数週間のまとめ / はてなダイアリー - in the vanguard
  http://d.hatena.ne.jp/kotastyle/20031112#p3

RSS が HTML 文書の代替であるとするのには違和感があるというのが話の発端だったと思います．kota さんは，RSS は元文書の代替とは考えられないという結論ですが，ぼくは RSS が元文書の代替としても機能していると考えています．まぁ RSS が元文書の代替としても間違いではないんぢゃないかと思うのです．

ただ，ぼくもはじめに違和感を持ったんです．

RSS が元文書の代替とは言えないとは思いませんが，もっと意味的に明確で，より良い方法があるのではないかと思います．

だから，「考える」ということは大切だと思いますし，もっと良い方法の提案が出てきて，それが広まれば良い事だと思います．

• RSS (RDF Site Summary) について，見出し一覧

TrackBack

2003 年 10 月のアクセス統計発表

先月 1 ヶ月間のおのひろきおんらいんのアクセス統計です．cycling.jp が一時停止した 15 日から 16 日にかけて，極端にアクセスが減りました．当然ですね．それでも 9 月よりも 10 月のほうがアクセスが増えました．

• おのひろきおんらいん全体で 183,891 ページビューで 9 月の 172,149 より増加
• welcome ページは 28,553 ヒットで 9 月の 26,786 ヒットより増加
• 1 日あたりの訪問者数は平均 1,972 で，これに関しては，9 月の 1,948 より増加

今月も RSS ファイルの利用を見てみます．"履歴もしくは日誌" としてつらつら書いているものの，RSS を http://onohiroki.cycling.jp/info/weblog.rdf として公開していますが，これのアクセスは 9 月から急激に増えました．

9 月に 8 月の 2.5 倍ほどに増えたのと比べると 10 月の伸びは，たいした事ないですね．でも増えています．10 月の 2867 ヒットという数値は，他のページと比較しても，11 番目に多いアクセスでした．

TrackBack

コミュニティの運営

Internet 上でのコミュニティ，つまりメーリングリストや Web 掲示板などの仕組みを介してやりとりを行う集団もしくは社会といったものとメーリングリストについて．

semblog-dev にメーリングリスト (ML) のコミュニティについての考察がありました．ここでは，メーリングリストは，コミュニティを運営する仕組みとしては全く向いていないのではないかという意見が述べられています：

• semblog-dev: MLでコミュニティ，の問題点
  http://www.semblog.org/i2k/archives/000222.html

要するに，後入りにとってはいついかなる場合においても後入りであることを自覚させられてしまう．一方で生え抜きの人にはそんな屈託はなくて，自分の場として自由に振る舞うことができる．その差は大きいし埋まりようがない．

引用終わり．

確かに，コミュニティを運営する上で，後から入ってくる人に配慮することはとても重要だと思います．もし，ある程度の規模のコミュニティを運営することを考えたら，常にある一定の割合で，新しい人が入ってくるのが必須です．健全な状態は，常連で活発だった人が静かになるのと，新しく入って来た人が積極的に参加してくるのとが，適当なバランスをとった状態だと思います．

あと，コミュニティを考えるときに，少人数で気楽にやりとりをする比較的閉鎖的なものと，より大人数でやりとりを行い，その分だけ気楽さにかけるけど，より開放的なものの 2 つがあると思います．どちらが良い悪いではなく別のものだと思うのです．

後から入って来た人のために配慮が重要なのは，後者のより大人数で開放的なものを目指す場合でしょう．

後から入ってきた人のための配慮というと，まずは話題や言葉使いが内輪受けにならないように配慮することだと思います．

ぼくはメーリングリストを運営していますが，気楽で楽しげな雰囲気を少し犠牲にしても，より大人数で，開放的なものを目指そうと思って運営しています．だから伏せ字や隠語を使う事を禁止して，略字を使うのを極力避けるというルールを作っています．

伏せ字や隠語を使うのは楽しくても，中に入れない人には閉鎖的な印象を与えますし，略字も一部の人にはわかってもわからない人にはわからないからです．そういう分からない事を，コミュニティの過去のやり取りの記録をひもとく事で解決しなければならないなら，かなりの障壁になるはずです．

もちろんコミュニケーションで使うツールによって，そのような障壁をより感じさせない工夫もできるのかもしれません．でも伏せ字や隠語の使用を避ける事や，略字の使用の制限，誰にでも分かるような文章を書く事をなどに配慮するほうが，本質的だと思います．

先日ぼくが運営しているメーリングリスト「リカンベント サイクリングクラブ メーリングリスト」のメンバーで，東京国際自転車展で，リカンベントという自転車の試乗会を行いました．そこに集まったメンバーは，比較的新しいメンバーが多く，メーリングリストができた当時から参加している人はあまりいませんでした．比較的新しいメンバーの人は，とくに後入りだという事を意識していないのだろうと思います．もしくはあまり後入りというのを意識しない人が積極的に活動に加わっているのか．

コミュニティの運営で後入りの人への配慮はとても重要であるのは確かですが，後入りへの配慮はコミュニケーションを行うツールの機能が支配的なのではなく，むしろどのような文章を書くか，その指針やルールをどのように設定するかの方が大切なのではないかと思います．そして後入りの人への配慮とは，そのコミュニティで積極的に発言をせず，静かに読むだけの人の存在を大切にする事と一緒のことなのではないかと思います．

TrackBack