2005-06 アーカイブ

http://hxxk.jp/2005/06/

典型的な言及リンクの無い無差別トラックバックの実例と、どのようなトラックバックが多くの人にメリットをもたらすかの指標

記事データ

投稿者

望月真琴

投稿日時

2005-06-30T23:44+09:00

タグ
概要

グッドタイミングで言及リンク無しで spam 的なトラックバックが来たので、その経緯を調べてみました。それにより、ただのにっき - 言及リンクのないTrackBackの何がいけないのか(2) の主張と同じような結論に至りました。

リプライ

1 件のリプライがあります。

記事本文

トラックバック話が続くけれど

ここ最近トラックバックに関する記事ばかり書いているせいかはたまたただの偶然か、題材にできるようなトラックバックをもらったので取り上げてみます。

どんなトラックバックかというと、ただのにっきに対抗して、言及リンクのない熟考されたトラックバックを考えてみるの冒頭で述べた 同じ話題を扱っているようだからと安易に送られた ( 例えば、検索などで探し当てたサイトに片っ端から送るような ) トラックバック です。

普段なら黙って削除するところですが、あまりに実例のサンプルとして適していると思ったので、詳しく取り上げさせていただくことにしました。

実例その 1: 欲しいもん!調べもん!!

保険会社の回し者じゃないけれどという記事に、欲しいもん!調べもん!!:自動車の任意保険の更新がちかい…という記事からトラックバックが送られてきました。

もげブ〜の自動車の任意保険の更新がちかい…^^;

試しにカービューで一括見積りしてみた。

いままでより、全然安くあがりそうだ!保険屋、乗り換えるぞ〜♪

どう客観的に見ても「自動車保険」ってこと以外に関連ありませんね……。 そこで、トラックバックが送られた時間の直前のログを見てみると、Google 検索: 車 任意保険 トラックバックの検索結果から辿り着いた形跡があります。

Google 検索: 車 任意保険という検索だと、保険会社や保険制度などのサイトなかり引っかかるため、更に「トラックバック」という文字列を加えて、トラックバックを受け付けているサイトを探したのでしょう。

事実、同じGoogle 検索: 車 任意保険 トラックバックの検索結果から見つけた任意保険について・・・皆さんは?? | 好き好き車(I love cars.)という記事にも、欲しいもん!調べもん!!からのトラックバックが見られました。 ( そして、「自動車保険」ということ以外には共通性を見出せませんでした。 )

実例その 2: 無料インターネットサービス日記

はてなアンケートを使ってみました - 質問編という記事に、無料インターネットサービス日記: はてなRSSにメール配信機能を追加という記事からトラックバックが送られてきました。

はてなダイアリーを提供する”はてな”は、RSSリーダー「はてなRSS」にメール配信機能を追加しました。

はてなアンテナやはてなブックマークなどのサービスには、新着のページやエントリーをメールで通知する機能は従来からありましたが、、はてなRSSにも同じ機能を追加することでユーザーが使い易いようになりました。

メール配信につては、、グループごとに設定が可能です。 メール配信のスパンですが、前日のメール配信以降に見つかったエントリーが毎朝9時ごろに配信される仕組みになっています。

”はてな”は、はてなアイデアというのを実施し、仮想的な市場の仕組を使って、ユーザーの皆さんから要望や不具合報告を効率的に頂くことを目的とした試験的サービスを行ってユーザーの立場に立ったコミュニティの改善をしています。

今後のはてなに期待しています。

んー、はてなアンケートを使ってみました - 質問編ではその title が示す通り、はてなのアンケート機能について述べたもので、はてなRSS については全く触れていません。 というかはてなRSS - hxxkのRSSリーダーを見ても分かるとおり、そもそも活用していません。

これも検索から来たクチかなーと思って調べてみると、やはり Google 検索: はてなRSS  トラックバックという検索結果がログに残っていました。 そして、これも同様に検索結果から見つけられる各記事において、同様のトラックバックが散見されます。

Proving grounds of the mad over logs: トラックバックの自動取得

はてなダイアリーの話題。 ( むしろ Trackback auto-discovery の話題が中心。 )

SkyPhoto People〜空の写真をトラックバック:風のまにまに号

トラックバックの話題。 どうも、以前この weblog 内にあった「はてなRSSに追加」という言葉を拾ったために検索結果に現れているようです。 要するに、この記事の本文中にはてな RSS およびその他はてな関連のサービスについて触れている部分はありません。

V-CLUB春日井のブログ ヴイクラblog: はてなアンテナの上手な利用法(BLOGを登録)

はてなアンテナの話題。

私が見かけたトラックバックが送られている記事のうち、はてなRSS について触れているものはありませんでした。 SkyPhoto People〜空の写真をトラックバック:風のまにまに号に至っては、本文中ではてなのことに全く触れていないのにトラックバックを送りつけられています。

で、何故か最も関連性の高そうなはてなRSS日記 - 新着エントリーのメール配信機能追加についてにはトラックバックが送られていません。

感想というか結論

ただのにっきに対抗して、言及リンクのない熟考されたトラックバックを考えてみるのようなリンク無しトラックバックは稀な例だと自分でも思っていますので、ただのにっき(2005-06-30) - 言及リンクのないTrackBackの何がいけないのか(2)にて レアなケースでは言及リンクが不必要になるという反証をあげてもあまり意味がない という答えが返ってくるのも予想の範囲内です。

重要なのは、そのTrackBackがより多くの人にとってメリットになるように頭を使おう、受信者のデメリットになるようなTrackBackを送るのはよそう、という点だ。 という部分には全くもって同意しますし、 キーワードでぐぐって、見つかったウェブログにかたっぱしからTrackBackを送るつけるような、頭の悪い利用はもうやめようよ、そういう提言なのである というのは正に今回の実例から導き出そうとした結論そのままです。 ( 実例まで書いたところでただのにっき(2005-06-30) - 言及リンクのないTrackBackの何がいけないのか(2) の記事を見ました。 決してただのにっき(2005-06-30) - 言及リンクのないTrackBackの何がいけないのか(2) に同意をするために上記の 2 つの実例を出したのではないですけれど、タイミングが良かったのでそのまま同意のための材料とさせていただきます。 )

結局、今回取り上げたようなトラックバックが横行しているから「リンクが無いトラックバックは全て spam だ」という風潮になるのであって、もし大多数に「トラックバックを送る際は受信者のメリットを考える」というリテラシが浸透していれば、リンクのある無しでなくトラックバックの内容自体で spam か否かの判断をするという意識になっていたと思うんですが、現状ではリンクが無いトラックバックは、その内容が吟味される段階に至らずに判断されてしまっているのだと思います。

もちろん、単にリンクがあるだけで受信者のメリットを考えていないトラックバックもありますし、受信者のメリットを考えたリンク無しのトラックバックもあります。 ( ←言い張る ) 今後はリンクがあること前提で、いかに内容を吟味したトラックバックを送るかということを論じる方向になっていくのかもしれません。

……たぶん、私の考えているトラックバックのあるべき姿と、ただただしさん ( ただのにっき ) の考えているトラックバックのあるべき姿は、本当は同じなのだと思います。 私が「リンク無しトラックバックにだって良いものは少数だけどあるんだよ」と楽観的に考えているのに対し、ただただしさんは「確かに少数あるかもしれないけど、大多数の悪いリンク無しトラックバックが押し寄せている現状を見ろよ」と現実的に考えている点が違うのでしょう。 もしくは考え方の違いではなくて、そういったトラックバックに手を煩わされた経験があるか無いかの違い。

ふと浮かんだ未来

q 要素ないし blockquote 要素の cite 属性にのみ URI が存在するような引用で送られるトラックバックの是非がごく狭い範囲、たとえばモヒカン族 ( システムとかプログラムに強い方面の人を表すジャーゴン ) の中での原理主義派 ( cite 属性でトラックバック元を明示しているよ派 ) と利便追求派 ( a 要素の href 属性で明示されないとシステムでトラックバックを弾く際に困るよ派 ) の間で議論が交わされそうな気がします。

ちなみに私は cite 属性で引用元を示せば充分だと個人的には思っていますが、古いブラウザの対応の現状などを鑑みて、文脈を損なわないように自然に a 要素によるリンクも併記するコウモリ派ですが。

トラックバック送信先

欲しいもん!調べもん!!:自動車の任意保険の更新がちかい…

トラックバックありがとうございました★ でも、私は任意保険がどういうものかについて触れただけで、保険の乗換えのことは全然触れていなかったので、無関係なトラックバックということで取り上げさせてもらいました。

無料インターネットサービス日記: はてなRSSにメール配信機能を追加

トラックバックありがとうございました★ でも、私は人力検索はてなについて触れただけで、はてな RSS は使っていないので、無関係なトラックバックということで取り上げさせてもらいました。 というか何ではてなRSS日記にはトラックバック送っていないんでしょう ?

……こういったトラックバックをもし自分が受け取ったら、すごくむかつくだろうなあと思いつつお返しトラックバック。 また、ただのにっき(2005-06-30) - 言及リンクのないTrackBackの何がいけないのか(2)の主張に異論は無いということで同意トラックバックも。

ただのにっき(2005-06-30) - 言及リンクのないTrackBackの何がいけないのか(2)

「レアなケースでは言及リンクが不必要になるという反証をあげてもあまり意味がない」というのは自分でも思っていたことで、トラックバックの受信者、およびトラックバックを目にする人のメリットになるようなトラックバックを送るべきという主張には全面的に同意です。

リプライ

1 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-08-04T00:20+09:00 - 「言及リンクのない TrackBack を弾くプラグイン」導入 < 闇雲

Movable Type で言及リンクのない TrackBack ping を弾...

言及リンクのないトラックバックを受け付けないようにする「選択肢」

記事データ

投稿者

望月真琴

投稿日時

2005-06-30T01:03+09:00

タグ
概要

一律に「言及リンクが無いトラックバックを弾く」という実装は賛同できかねますが、それを「設定次第で選択できる」という実装なら広まってくれると良いなと思います。

リプライ

リプライはまだありません。

記事本文

マイぷれすでリンクの有無によってトラックバックを受け付けないようにできる設定が選択可能に

ただのにっきに対抗して、言及リンクのない熟考されたトラックバックを考えてみるにトラックバックを送っていた Reiko Kato さん ( [晴]晴れの日もある ) のはてなのトラックバック・その2 という記事で出されていた

デフォルトではなく、運営者に選ばせればよいと思うのだが。 私は選びたい。 個別対応は手間もかかるし神経も消耗する。 設定で撥ねられれば楽だ。

という要望を受けての実装のようです。 はてなダイアリーは一律に、該当記事へのリンクが無いと送信できないという実装なのでちょっとどうかなあと思っていたのですが、マイぷれす デフォルトは従来の通り言及リンクがなくとも受け付ける設定 とのことで、各ユーザのニーズに合わせて設定できますので、良い実装の仕方だなと思いました。

Movable Type はどうか

実は、ただのにっき(2005-06-28) - 言及リンクのないTrackBackの何がいけないのか関連でこの記事を見かけたので、前項のマイぷれすの実装を知るよりも先にこちらを知ったのですが。

そういうリテラシーの普及を考えるよりも、とりあえず「リンクのないトラックバックは弾く」という防御システムの実装が効果的だろう。 SixApartさんよろしく

言及リンクのない熟考されたトラックバックという可能性だって考えられるんだから、 「リンクのないトラックバックは弾く」 という実装をとりあえずで行われると、また別の間違ったリテラシが広がってしまうじゃないですか ! ……と思ったのですが、マイぷれすのようにオプショナルな実装になれば問題ないのかなあと思いました。

はてなブックマーク - 「トラックバックはリンク&言及した相手にだけ送れ」と言われても…… :小林Scrap Bookによるコメントに、 cheebow 『[Blog]確か、言及リンクのないトラックバックをはじくMT用のプラグインがあったような気がする』 というコメントがあったので、もしかしたら実装済みと言っても良いのかもしれません。

ゑBLOG: トラックバックSPAM防止プラグインというものをはてなブックマーク - CHEEBOWのしおりで発見しました。 これを使えばリンク無しのトラックバックを弾くことができるようです。 ( 私はリンク無しトラックバックもアリだと思うので、導入テストをしていません。 )

トラックバック送信先

言及リンクのないTrackBackを受け付けない設定(新機能の紹介) / マイぷれす運営日記 - 言及リンク,TrackBack,トラックバック

デフォルトでは言及リンクが無くても受け付ける設定のままで、ユーザの設定次第で言及リンクが無いと受け付けないように変更できる、という実装の仕方は良いと思います。 こうした実装に他サービスも追従してくれると良い方向に進むかもしれません。

「トラックバックはリンク&言及した相手にだけ送れ」と言われても…… :小林Scrap Book

「リンクのないトラックバックは弾く」という実装は、一律に適用されるのではなく、あくまでオプショナルなもので行われて欲しいと思います。 ( そういったプラグインが既にあったかもという声もあります。 )

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Musical Baton がいかに危険でいかに迷惑かという話

記事データ

投稿者

望月真琴

投稿日時

2005-06-29T22:35+09:00

タグ
概要

Musical Baton はマーケットアナリストによる仕掛けで始まり、音楽著作権団体の私的録音・録画補償制度を正当化するための後ろ盾として広まり、そして後に残るのは食い尽くされたトラフィックの残骸ということのようです。

リプライ

12 件のリプライがあります。

記事本文

ある種のトンデモ理論

憶測で構築された記事と、それを証左として批判を行っている記事。

まとめなんてものを作って拡大に拍車をかけている張本人が何を言うか」と反論されるかもしれませんが、私自身は同種の音楽的嗜好を持つ人を探すのと、自分が受け取ったバトンのルーツを知ること、そして自分が廻したバトンの行方を知りたいがために作っただけであって、それ以外の副次的な利益や効果は得ていません。 バトンを受け取った人がまた廻すか、それとも止めるかなんてそれこそ本人の判断によるものでしょう。 ( 公にリンクされたから、またはトラックバックされたから答えなきゃいけない雰囲気になるというのは結果論であって、最終的に判断を下すのは受け取った本人です。 )

  1. 憶測その 1 - 仕掛け人はマーケットアナリスト
  2. 憶測その 2 - Musical Baton は違法コピーの証拠 ?
  3. 憶測その 3 - Musical Baton はトラフィックに荷重をかける
  4. Musical Baton を全肯定するつもりはないけれど
  5. トラックバック送信先

憶測その 1 - 仕掛け人はマーケットアナリスト

ここまで書けばおわかりだろうが、これを仕掛けたのは音楽業界のマーケットアナリストだろう。 これを流行らせれば、わざわざ調査のために聞き回る必要もなく、ググってブログページを収集すればその日の統計が取れるのだ。

Musical Baton の質問を根拠として 音楽業界のマーケットアナリストだろう と断定してありますが、アナリストである証拠はどこにあるのでしょう ? ググってブログページを収集 するなりバトンを廻した元のリンクを辿ったりするなりしてその証拠を掴めばいいのでは ?

こう書くと「じゃあ仕掛け人がマーケットアナリストじゃないという証拠を出せ」という悪魔の証明を求める人もでてきそうですが。

天漢日乗: "Musical Baton"の危険性についてはこのマーケットアナリスト論を疑うことなく前提として 彼らは、あなたの書いたblogを自分たちの商売に利用しているのだ と断定していますが、その前提が確たる証拠を得なければ、その結論には帰結しないでしょう。

憶測その 2 - Musical Baton は違法コピーの証拠 ?

匿名のブログならともかく、実名を挙げているSNSにおいて自らの著作権違反を露呈している場合は注意した方が良い。 あとで、著作権を管理する音楽団体から以下の様なメッセージが届くかもしれない。

「数十ギガバイトの音楽ファイルはどこから入手されましたか?」

自分の回答では 18.56GB になっていますけど、エンコードしていない CD ( たぶん 100 枚くらいはあります ) まで合わせてエンコードすれば、おそらく 30GB は確実に超えると思います。 私の場合はそんなに大きな HDD を使っているわけではないので、全部をエンコードするようなことはしていませんが。

もちろん、私以外の回答者が全て同じような状況かというかと、そうではないと思います。 ただ、もし違法コピーが大部分を占めているユーザが大半ならば、 Musical Baton が発生しようとしまいと、いずれ自業自得で何らかの影響が出てくるんじゃないでしょうか ? 単に音楽ファイルの容量が大きいだけで違法コピーの疑いをかけられるなら、それは熱心な音楽ファンを侮辱していることに他ならず、音楽業界自体の首を締めるだけだと思います。

憶測その 3 - Musical Baton はトラフィックに荷重をかける

"Musical Baton"とその亜種が悪辣なのはいたずらにトラフィックに荷重をかける「チェーンメール」のblogバージョンである

今回、最も私が疑問を抱いた主張がこれ。 確かにチェーンメールは無駄なトラフィックを生むでしょう。 しかし、それをそのまま weblog に当てはめて考えるのは間違っています。

チェーンメールを送った発端の人が、そもそもチェーンメールを送らなかったら、あるいはチェーンメールの伝播の途中経過にある人が、そこでチェーンメールを止めてしまえば、トラフィックの増加は起こりえません。

しかし、 Musical Baton を始めた発端の人が、そもそも Musical Baton を始めなかったら ? あるいはバトンを廻された人が回答をしない、または回答はするけど廻さないという選択を取ったら ?

そういったケースを考えてみても、それは単に Musical Baton となるはずだった weblog の内容が別の内容に置き換わるだけで、トラフィックの量は変わらないでしょう。 多くの人が自分の weblog に同じような内容の記事を書く、多くの人が自分の weblog に思い思いの記事を書く、その「記事を書く」ことで生じるトラフィックという観点においては、内容がどういったものであるかというのは関係ありません。

1 つの記事から最低 6 つのリンク ( バトンが廻ってきた元 + バトンを廻す先 *5 ) ができるから、バトンを廻すためにトラックバックを送るから、トラフィックが増大するのだという反論があるかもしれませんが、 WWW 上に HTML の形で公開する以上、リンクによるトラフィックが生じるのは自然な成り行きです。 ( トラックバックによるトラフィックの増大は確かにあると思いますが、トラックバックを使ってバトンを廻す手法は個人的に間違っていると思うので、それを肯定するつもりはありません。 )

リソースを無駄遣いする と主張する根拠は何なのでしょう ?

Musical Baton を全肯定するつもりはないけれど

今回取り上げた記事以外にも、 Musical Baton について懐疑的な意見を書いた記事や、そのあり方を問う意見を書いた記事はたくさんあります。 それらは充分に考察をされ、同意を覚える内容ばかりだったので参考記事として記録しても良かったのですが、 Musical Baton に深く関わった私がそれを行うことで論っているように見えるのを避けるため、ひとり頷きながら読むに留めていました。

しかし、今回取り上げた分は憶測によって前提が作られており、思い込みの域を出ていないんじゃ ? と思ったのでこうして取り上げてみました。 もし主張されるだけの明確な根拠があるのであれば、内容自体には納得できる点があるので、お時間があればそう考える根拠を追記なりコメントなりで示していただければと思います。

トラックバック送信先

スパムメール料理法 / Spam Mail Cooking - チェーンブログ:Musical Baton

「音楽業界のマーケットアナリストだろう」と断定できる根拠は何でしょうか。 質問から類推するだけでなく、起源を辿ってみたのでしょうか ?

スパムメール料理法 / Spam Mail Cooking - 私的録音・録画補償金制度とMusical Baton

単に音楽ファイルの容量が大きいだけで違法コピーの疑いをかけられるなら、それは熱心な音楽ファンを侮辱していることに他ならず、音楽業界自体の首を締めるだけだと思いますが、容量が大きいからといって安易に疑いをかけるような事をするでしょうか。

天漢日乗: "Musical Baton"の危険性について (その2) 著作権保護の動きと書き手が特定されるblog内での音楽ファイル公表の関係

Musical Baton が、それ以外の weblog に比べてより多くの荷重をトラフィックにかけるという根拠は ? チェーンメールなら止めてしまえば以降のトラフィック増加はありませんが、 weblog においては結局それ以外の題材でトラフィックが生じると思います。

リプライ

12 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-06-29T23:30+09:00 - e-luck

マーケットアナリスト仕掛け人説を初めてみたときに思ったことは、実際にそれがマーケティングだろうが何だろうが、自分はなんだかんだ言いながら楽しんでバトンを受け取って記事を書いた訳で、それによってマーケットアナリストだかが楽にお金を儲けたとしても正直どうでもいいやって。 廻さないと不幸になるって強迫観念に追われて、いやいや記事を書いたわけではないですしね。

2005-06-30T02:11+09:00 - 真琴

どうでもいいやという思いもありましたし、そんな上澄みだけをすくったようなマーケティングが果たして有用なマーケティングになるのかなあという思いもありました。 というか、マーケティングに乗せられたような音楽って買いませんしね、という大人ぶった高校生みたいな意見もあったり。

2005-06-30T06:09+09:00 - Musical Batonは是か否か < 雅楽多blog

◇ hxxk.jp - Musical Baton がいかに危険でいかに迷惑かという話 まぁすでに各所で言われていることでいまさらではありますが。 私自...

2005-06-30T13:24+09:00 - Insite

「マーケットアナリスト仕掛け人説」を否定することは「悪魔の証明」ですからね。 2chの書き込みさえもソースにしてしまうのが天漢日乗さんとこの自由さでもありちょっとした怪しさでもあると思うのですが、この件に関しては偏向しすぎているような印象。

2005-06-30T20:15+09:00 - Musical Baton

Musical Baton騒ぎは収束した模様ですが、「きっかけはー、マーケットアナリスト!」「Musical Batonは違法コピーの証拠」「Musical B...

2005-07-02T01:18+09:00 - ミュージカル・バトン陰謀論説? < gekka blog

週刊!木村剛 powered by ココログ: [ゴーログ]ミュージカルバトンって何ですか? のトラックバック欄を経由して、いくつか興味深いエントリが。...

2005-07-03T16:53+09:00 - Musical Baton はチェーンメール(ブログ?)です。 < ひろの日記帳@International Cafeteria

 もう既に旧聞の部類に入るのでしょうが、私のところにも、知人から Musical Baton が回ってきました。  結論から言いますと、Musical Bat...

2005-07-05T22:17+09:00 - Musical Baton < secondo me...

先日、SA700iの件でTBさせていただいた「携帯リードメールで本当に小遣い稼ぎ...

2005-07-07T20:00+09:00 - 大きな勘違い

悪魔の証明、非存在の証明を誤解しているように思います。 例えば神がいると証明するにはその神様を証人として裁判所にでも連れて行けば済むことでとても簡単なことです。 では神がいない証明は? それこそ全知全能なる神性をもってしか証明できないことでしょう。 神様ですら持ち上げられない岩を作り出す能力と その岩を自らう持ち上げる能力という矛盾した能力とで その非存在を証明できるとばかりに喜んでいる者が居たそうですが 神でない人間に神的能力を要求することもまた矛盾していますね。 つまり端から証明不可能な証明を要求されたわけです。 これが悪魔の証明と呼ばれる所以ですね。 では今回のケースは? CIAのような捜査能力がなくても決して見つけ出すことは不可能ではないでしょう。 ただ誰もそこまで労力を払う気も時間もないというだけで。 それを悪魔の証明とは言いません。 ちなみに否定と反証、肯定と証明は違いますのでお間違いなきよう。 僕としてはマーケットがどうのというのと僕自身がどう動くかは関わっていないと思いたいです。 だけど現実にはアーティストはそのマーケットとやらに左右されざるを得ませんから "もしかしたら生まれたかもしれない"不朽の名曲がいったいいくつあるのかは数えられません。 マーケット − アーティスト − 僕たち アーティストを通じて僕たち自身も影響を受けているんですから どうでもいいとは言っていられないんではないでしょうか。

2005-07-21T20:55+09:00 - 真琴

> Insite さん 私も天漢日常の方の多様な記事はよく読ませてもらっていますが、今回は不確かなソースを元にした結論ありきで話が展開されていたように思えたので、疑問を投げてみました。 > 大きな勘違いさん 悪魔の証明についてはご指摘の通り、私が誤解していた部分がありますね。分かりやすい解説、ありがとうございました。 マーケティングについてですが、以前のコメントで「どうでもいい」と言ったのはマーケティング自体がどうでもいいという意味ではなく、今回の件で儲けを得るようなアナリストがいても ( いるとは到底思えませんが ) どうでもいいということです。 ( 要は e-luck さんの言う「どうでもいい」と同じ ) 何かしらのマーケティングが絡んでいるというのは否定しませんし、「○○はマーケティングなんか関係なくやっているアーティストなんだよ ! 」なんていう主張をするつもりもありません。単にその音楽自体よりもマーケティングに比重が傾いている音楽に興味がないというだけで。

2005-12-23T23:47+09:00 - バトンについて < 踊り字ヱブログ

ちょっと前から流行っている(気がする)バトンについてちょっと書いてみます。 ここで言うバトンとは、Musical Batonに端を発する連鎖問答で、いく...

2005-12-28T06:46+09:00 - ミュージカル・バトンはなぜ大流行になったのか < 絵文録ことのは

 2005年6月、ミュージカル・バトンの大流行現象が起こった。このブログでも初期...

ただのにっきに対抗して、言及リンクのない熟考されたトラックバックを考えてみる

記事データ

投稿者

望月真琴

投稿日時

2005-06-29T01:27+09:00

タグ
概要

言及リンクが無くとも、熟考をした上でのトラックバックの実例はあり得ますよと、自分語りを以って反証してみました。ただし、それは稀な例であり、またその熟考は主観的なものであるため、リンクが無い状態のトラックバックに固執するわけではないという考えも持っています。

リプライ

6 件のリプライがあります。

記事本文

この記事の説明

ただのにっきのこの記事を受けて、今日の記事の内容を書いています。 ただただしさん ( ただのにっき ) の主張は概ね同意なのですが、果たして全ての「言及リンクのないトラックバック」がこれにあてはまるのか、という疑問を抱いたので、あてはまらないケースを考えてみようと思います。

初めに断っておきますが、単にアクセスアップを目的としたトラックバックや、同じ話題を扱っているようだからと安易に送られた ( 例えば、検索などで探し当てたサイトに片っ端から送るような ) トラックバックを正当化するつもりで書くのではないことをご理解ください。 そういった実のないトラックバックに関しては、私は言及リンクがあろうと無かろうと spam と変わらないという認識を持っています。 ( そしてそれは無分別なトラックバックは spam と何ら変わらないや、有用なトラックバックとはといった記事で既に述べています。 )

送信元の読者の利益を考える必要がないトラックバック

TrackBackは逆リンクを生成するので、「A→B」のTrackBackは、「B→A」のリンクを生成する。 サイトAに言及リンクはないので、「A→B」のリンクはない。 結果、サイトBの「読者」はサイトAの記事を読めるが、サイトAの読者は(関連しているはずの)サイトBの記事を読めない。

この場合、アクションを起こしたのはサイトAの管理人だけなので、管理人Aの行為がどういうことか考えてみよう。 Aの行為は、サイトBの読者という「新規顧客」の呼び込みには成功しているが、「既存顧客」に対する新しいリンクの提供を怠っている。 Aの読者は怒ってしかるべき、ひどい仕打ちである。

トラックバックの送信元 (A) から、トラックバックの送信先 (B) へのリンクが必要ではない ( A の読者の利益供与は必要ない ) ケースを考えてみましょう。

A から B に対して、一方的に情報を提供するようなケースが該当すると思います。 極端に言えば、「メールで教えても差し支えないんじゃ ? 」と第三者から思われるような。

B の記事が何らかの疑問を述べている記事で、それを解決するような記事 A が既に書かれていた場合、 A の読者は A の記事を見ている時点で既に答えは得ているわけですから、答えを見た後に改めて疑問 (B) を見直す必要はありません。 もちろん、 B が A から答えを得ることによって、更に発展的な解決手段を公表することも往々にしてあり得ますから、実際は B への誘導があるに越したことはありませんが、必須ではないでしょう。 ただし、このケースに該当するトラックバックはかなり稀な部類に入ると思います。 ( 私自身、これまでにそういったトラックバックはおそらく 2 回ほどしか送っていません。 )

言及リンクのないトラックバックは全てが spam と断定されるべきか

こんな主張も見受けられる。 自分のサイトに来て記事を読んでもらいたいと思ったからTrackBackしたのだ。サイトBの記事に価値があるかどうかには興味がない。 サイトBはTrackBackを受け付けている以上、黙って受け入れればいいのである。 いやならTrackBackを受け付けなくするか、不要なTrackBackは削除すればいいではないか

ここで例示された主張はあまりに極論であり、私は受け付けなくすれば良いとか不要なら削除すれば良いといった、受け手のことを考えない主張については反対です。

サイトBの記事に価値があるかどうかには興味がない というのも自分のことしか考えていない主張で、一見前項で示した「 B に対して、 A からのリンクを必要としないケース」と類似するように見えますが、前項で示したケースはあくまで「 B の記事を見て考えたけれど、やはりリンクは必要じゃないな」という考慮の上で成り立つのであって、「価値があるかどうかには興味がない」という理由ではないという点が違います。

「じゃあリンクすればいいのかよ」とばかりに、単にサイトAにBへのリンクを追加しただけでは、この屁理屈に皮が一枚加わるだけである。 記事中できちんと「言及」し、密接に関連するかどうか吟味した上でTrackBackする。 この過程があるかどうかで、(サイトB管理人を含む)読者にとって価値のあるリンクが生まれるかどうかが決まる。 言及リンクをすることで、TrackBack先を吟味するチャンスが生まれるのだ。 TrackBackには、そういう熟考の成果が含まれて欲しいものである。

単なるアクセス数アップの手段として、独りよがりの屁理屈で送りつけられるTrackBackは、TrackBackの技術的な上っ面だけを見た、底の浅い利用例である。

確かに、申し訳程度にリンクを添えたから「トラックバックしても問題ない」と短絡的に考えるのはただの屁理屈です。 しかし、トラックバック先を吟味することと言及リンクをすることが等価で結ばれる事柄なのでしょうか ?

自分語りにシフトしてるじゃんと揶揄されるかもしれませんが、言及リンク無しのトラックバック ( ただし一定条件有り ) のススメ - リンクを含まないトラックバックを送信したにて、トラックバック先を吟味して熟考した結果、「やはり既存記事にリンクを追加する必要はなし」という結論に達して、言及リンクが無い状態でトラックバックを送信しました。 ( ただし、自分の送信履歴の備忘としてトラックバックの送信先を記録するスタンスを取っているため、現在はリンクがある状態になっています。 しかし、単なる一行リンクなので、「言及」ではないリンクですが。 )

ただし、このトラックバックを送る際に、 spam やアクセスアップ狙いのトラックバックでないことを伝えるための工夫として、その記事の既存の概要である Movable Type 2.x は各記事の編集画面からしかコメントやトラックバックを削除できないので、 Recent Reaction template ver.3 を改造して、一括管理するテンプレートを作ってみました。 という記述を、トラックバック送信時には Movable Type 2.x において、トラックバックスパムが連番でない状態で送られてきた場合は、私の拙作ですが管理用のテンプレートを使うと少し作業が楽になります。 に変更して、「こういうのを作っていますよ」ということを通知したいということをアピールしています。

以上、言及リンクが無くとも、熟考をした上でのトラックバックの実例はあり得ますよと、自分語りを以って反証してみました。 ただし、言及リンク無しのトラックバック ( ただし一定条件有り ) のススメのコメント欄のやりとりにあるように、その熟考は主観的なものであり、もし過去記事にリンクを加えることでその判断を客観的なものにできるのなら、リンクが無い状態のトラックバックに固執するわけではないという考えも持っています。

何が言いたいのかというと

ただのにっき(2005-06-28) - 言及リンクのないTrackBackの何がいけないのかは非常に論理的な説明がされており、かつ分かりやすく書いてある良記事だとは思うのですが、それゆえに「リンクが無いトラックバックは問答無用で悪」という認識が広まってしまう危険性があると思います。 私が出したようなケースは稀だと思いますが、もしかしたら他にも「リンクが無くとも熟考をされた上で送られたトラックバック」の事例があるかもしれません。

もちろん、「リンクが無くてかつ熟考なんて全然していない悪質なトラックバック」が横行している現状では、そう断言するのも有効なストッパーとなり得るのですが、そうではないケースがあるかもしれないという考えを巡らす可能性の芽を摘むことになりかねないんじゃないかなと思ったので、あら捜しみたいな反証をしてみた次第です。

まあ、門外漢だけどはてなダイアリーの仕様変更に賛成 - 今回の変更に伴うはてなダイアリーユーザの反応に反応してみる ( もしくはトラックバック送信備忘 ) のように、特定の記事へのトラックバックを一絡げにして扱った奴が何を言っているんだ、というツッコミが来そうな気もしますが。

トラックバック送信先

ただのにっき(2005-06-28) - 言及リンクのないTrackBackの何がいけないのか

言及リンクが無くとも、熟考をした上でのトラックバックの実例はあり得ますよと、自分語りを以って反証してみました。 ただし、それは稀な例であり、またその熟考は主観的なものであるため、リンクが無い状態のトラックバックに固執するわけではないという考えも持っています。

リプライ

6 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-06-29T19:57+09:00 - リンクとトラックバックはセットで < [晴]晴れの日もある

そうではないのかな、と漠然と考えていたことを懇切丁寧に説明しているページを見つけた。

2005-06-30T10:18+09:00 - takatoh

2つめのセクションにかんして,トラックバックの送信方向が > トラックバックの送信元 (A) から、トラックバックの送信先 (B) へ なら,時間的に B が A に先行しているはずです。これに対して後半の > B の記事が何らかの疑問を述べている記事で、それを解決するような記事 A が既に書かれていた場合 というのは矛盾していると思います。

2005-06-30T10:33+09:00 - トラックバック関連めも < ちはろぐ

トラックバックに言及リンクは必要か?なんて話題が局所でやり取りされている模様。 ...

2005-06-30T22:19+09:00 - TrackBack とリンク < 天衣無縫な日々

ただのにっきで「言及リンクのないTrackBackの何がいけないのか」という記事が書かれてて,それに対する反論がいくつかTrackBackされてた.そのほとんど...

2005-07-01T00:50+09:00 - 真琴

矛盾しませんよ ? トラックバックは必ずしも送信先の記事を受けて書いた記事から送るものじゃありませんので、単純に「時間的に B が A に先行している」とは限りません。本文中にも同じ例を出していますが、 http://hxxk.jp/2005/05/30/0029#sub-20050530-02 がその実例です。 実例内の weblog を、それぞれ hxxk.jp を (A) 、 Going My Way を (B) 、スピリッツオブゼロ@blog を (C) とします。 まず (C) の疑問 ( 「こういう機能がないかなあ」というもの ) を受けて、私 (A) がお節介ながら解決記事 ( 「こんなテンプレートを作ってみたけどどうですか」というもの ) を書き、トラックバックを送りました。この時は、きっかけとなった (C) に対するリンクを張って、経緯を示した上で解決記事を書いています。 ( 要するに、一般的に見られるトラックバックの形です。 ) さて、それから約 1 ヶ月後、 (C) と同じようなことを書いている (B) という記事が書かれていたので、 (A) から「以前に似たようなものを作っていましたよ」とトラックバックを送りました。この時は、 (B) の方だけが解決手段を得られれば良い ( 何故なら (A) から (B) にリンクを張らなくても、 (A) の読者は既に解決方法を得ている ) ので、リンクをしないトラックバックを送りました。 本文中の例とアルファベットを合わせたため、記事の時系列としては (C) → (A) → (B) という流れになっていて混乱するかもしれませんが、このように (A) が (B) に先行する例もあるということで。

2005-07-02T02:32+09:00 - 「clmemo@aka」の Trackback Policy < clmemo@aka

ただし、真琴さんが 主張するように、時系列が逆のトラックバック (ポスト後に書かれた記事に「既にこういう記事を書いています」という主旨で送るトラックバック) は...

はてなダイアリーの自動トラックバックについての考察

記事データ

投稿者

望月真琴

投稿日時

2005-06-27T20:52+09:00

タグ
概要

自動トラックバックと手動トラックバックが混在している状況の改善を望んでいるのであって、自動トラックバックの ON/OFF 選択が可能になったことに賛成、といった前回の記事は語弊があったかも。

リプライ

リプライはまだありません。

記事本文

門外漢だけどはてなダイアリーの仕様変更に賛成執筆時における認識不足

これは後で述べる各トラックバックへの反応でも触れますが、ブログモードでは id トラックバックという名前で、 通常のトラックバックとは別枠 に表示されるものがあるということを知りませんでした。

はてなダイアリー日記 - 表示モードの設定項目(ブログモードの追加)については目にしていましたが、はてなダイアリー日記 - ブログモード機能の試験提供についてをよく読んでいなかったたため、ブログモードは、単に Movable Type で言うところの Individual Entry Archive のような表示モードかなという認識不足に陥っていました。

よって、門外漢だけどはてなダイアリーの仕様変更に賛成で例として提示している "referred" 欄を設けるという記述は、 id トラックバック欄をブログモード以外でも設けるようにするという表現に置き換えても良いと思います。

私の提案したはてなアイデアの表現において失敗した点

これは私が門外漢だけどはてなダイアリーの仕様変更に賛成の記事を書いた後に提案したアイデアですが、前項の認識不足もあって "referred" の欄を復活 という表現は用いましたが、これは適切でなかったなと思っています。

この表現は id トラックバックの存在を知らなかったがために「復活」という単語が入ってしまい、私の提案したい主旨がぼやけてしまった感があります。 このアイデアで提案したかったことはあくまで「現状のように、自動トラックバックと手動トラックバックが混在している状況の改善」であり、自動トラックバックの名称をどうするか、自動トラックバックの存在の是非を問うものではなかったのです。

はてなダイアリー日記 - はてな社内ミーティングの公開についてで公開されている社内ミーティングの mp3 の冒頭で私のアイデア ( もしかしたら他の方が提案された類似のアイデアがあるのかもしれませんが…… ) が取り上げられたのは嬉しかったのですが、どうも「どんな名称が良いか」的な話にシフトしてしまっている感があるのが残念。

まあ、門外漢だけどはてなダイアリーの仕様変更に賛成も、改めて読み直すと ON/OFF 設定の有無ではなくて現状のトラックバックの表示について触れているので、的外れな指摘になってしまっている感があります。 ( 後述しますが、自動トラックバックにあたるものに良いネーミングがなされ、受信側での ON/OFF 設定ができるようであれば、送信側は自動であっても良いと思いますし。 )

自動トラックバックははてならしさの所以か

近藤さん ( id:jkondo ) 直々に自動トラックバックのことについて語られています。

近藤さん自身も 「あのIDを書くと飛ぶものはトラックバックではないよ」という指摘が正しい と認識されていて、かつ はてなダイアリーユーザーが他のブログユーザーと交流を図るときに障害になりかねない問題だと思います と危惧されており、自動トラックバックの名称については再考する時期が来ているという見方をされているので、本来の意味でのトラックバックとの意味の乖離を実感されているようです。

そして、

もう一点注目すべき事実としては、「はてなダイアリー内で一般的なトラックバックよりも、id記法による自動トラックバックの方がたくさん利用されている」という点です。 「id:jkondo」と書いて人の日記リンクを貼れるのは便利だ、ということは、最初にその仕組みを考えたときも、現状でも大して変わらない事実だという気がしてます。 この機能がはてなダイアリー内でこれまでに果たしてきた役割の大きさは相当なものがあると思います。

と、その機能自体が担った役割について書かれています。 私ははてなダイアリーのベータ版の頃から読み手として見ていましたが、途中で「トラックバック」という名称を冠したことに目をつぶれば、この機能が持つメリットは非常に大きかったと思います。 ( もちろん、それによるスパム行為などのデメリットも見てきましたが……。 )

この機能自体ははてなダイアリーの大きな特徴だと思っていますし、 既存のトラックバックとは線を引いた新しい機能として仕様を作成し、他のブログでも利用できるように呼びかける という考えには賛同します。 ( 引用部分の強調は私が行いました。 この「既存のトラックバックとは一線を画す」という前提で、呼びかけを行うというのなら問題は無いと思います。 )

Re: 渋谷系@シプヤ

そのとおりです。

脆弱な象徴というよりは奥ゆかしさや繊細さの象徴なんでしょうけど。

奥ゆかしさや繊細さが象徴するものが、 id 記法による自動的な ( あるいは強制的な ) リンクと等価なのかなあ……と思います。 その考えを全面否定するつもりはありませんし、私が「サイト上で名指しして指摘を行う」ことをよく行う人間だからそう捉えてしまうのかもしれませんが。

先日まで「渋谷系@はてな」だったもので! という点にマジレスすると、そういったタイトルだったことを知りませんでした、ごめんなさい……。 確かに、「はてなダイアリー - 」という名前でなくても、何らかの形ではてなダイアリーだと分かるようにしている方はよく見受けられますね。

あと、「アイデアに書いた方がいいのかな」という呟きは自分に向けたもので、そういう呟きを表に出すことで自分の背中を後押しするというか、むしろ「これはアイデアに書くよ」という宣言をわざとオブラートに包んで行っているというか、芸風みたいなものです。 ( 紛らわしいのでそういった芸風は止めたほうがいいのかもなあ←これもオブラートに包んだ宣言かもですよ ! )

はてなダイアリー - 真琴@臨時更新場に書くんじゃなくて hxxk.jp に書いている理由は、元々はてなダイアリーへの要望を行っていた頃も、まず hxxk.jp にその詳しい内容を書いて、はてなダイアリー - 真琴@臨時更新場にて「〜〜をして欲しいです。詳しくは○○に書いています」みたいな方法を取っていたためです。 そのため、今回も同様に hxxk.jp に記事を書き、それを元にアイデア提案という流れにしました。 ( その記事からアイデアに対してトラックバックを送るのを忘れてしまっていましたが……。 )

今回の変更は主にダイアリー記法

ブログ機能としてオプション化する事の是非であって

問題なのはブログ的な感覚の人は記法によって

それが処理できるのに、それを自分では見つけられないために

オプションに頼らざるを得ないということ。かな

はてなダイアリー - はてなダイアリーガイド「日記から意見を送る(自動トラックバック)」とはにある、 また、裏技ですが『http://d.hatena.ne.jp/./hatenadiary/』のようにURL中のユーザーIDの前に『./』をはさむとトラックバックしません。 のことでしょうか。

逆説的に言うと、 ./ のような裏技によってオフにすることができていたのに、オプションとして採用されると問題になるという事に疑問符が。 全くできていなかったところに、突然オプションとして採用されてしまったというのなら是非が問われるのもまだ納得できますが。

Re: コトバノツドイ - リファとトラバ

これをid記法だけでなく、はてなダイアリー内での自動トラバ全てに対応し、idトラックバック欄に送る。 またブログモードだけでなく、日記モードでもidトラックバック枠を作る。 そうすることによって、いわゆるリファトラバの棲み分けができ、現在あちこちから噴出している不満をかなり解消できるのではなかろうか。

その上で、自動リファidトラックバック)のオンオフがあってもそれは良いと思う。 リファであればトラバほど送るのに躊躇しないだろうし、どうしても送りたくない人がオフを選択するということで納得できるのではないかと思う。 リファであれば、「送るのが普通」という気風を作るのも難しいことではないだろうし。 そのためには「idトラックバック」よりも、以前にあったという「referred」とした方がその意味をよく表して良いかもしれない。

トラックバックという名前を用いずに、全モードで id トラックバックのような枠を作れば、多くの不満を解消できるだろうという見方は私の考えと同じですね。 そういった前提であれば、送る側は一律で自動的に送り、逆に「送られる側」が ON/OFF を選べるようにするというオプションの実装でも良いかもしれません。

Re: 焚書官の日常 (4.4.1)

使い勝手の変化は些細なものでしょうし、それを盾にどうこういいたいわけではない。 ただ、これまでの前提だったものが、簡単に変わってしまうと、コミュニケーションのかたちがどう変わるかわからないな、という不安を持ちました。 自分の周囲のコミュニケーションが、なるだけ楽になる(なだらかな変化ですむ)にはどうしたらいいか、と思い、アイデアを出してみました。

なるほど、確かに前提として一律に適用されていたものが変化すると、それによってコミュニケーションの形が変わるということに繋がりますね。 で、前回の指摘の際は、「トラックバックを送れた方がいいです」の方に反応してしまって、本来の主張である デフォルトオフでも、簡単にid言及で という部分を無視した指摘を行ってしまいました。 これは私の読解の至らなさに原因があります。 申し訳ありませんでした。

これからの実装によりますが、本来のトラックバックと一線を画した呼び名を持つシステムが取り入れられ、トラックバックから情報の発展を得たい人 ( ≒読み手 ) も、 id 記法で手軽に言及を行いたい人 ( ≒書き手 ) も、双方が衝突することが無いことになってくれると良いですね。 ( = ではなく≒なのに含みはありません。 単に = としてしまうときっちり分けて捉えているように見えかねないので、曖昧に≒で結びつけています。 )

id:hxxkさんは、今回の変更に反対する感想をながめてまわって、「はてなユーザにとってそんなに大事なことなのでしょうか」と、引用されたユーザに代表される「はてなユーザ」が、標準的なトラックバックへの不適応にしがみついているかのようなまとめかたをされてる、ように読みました。

これはある種意図していたご意見です。 現状のように、単に id 記法で書いて自動的に送ったといえど、それがトラックバックとして扱われていると、トラックバック欄からエサを求めている私のような人が食いついてきますよ、といった暗喩を含んでいます。

「煽る」対象がわからないです。 引用された方は皆、感想を言ってるだけだと思いますが(実際の改変提案ならはてなアイデアに出すだろうし)、それをつかまえて、並べて、共通性を誇張することの意図はなんでしょうか。

明確な対象としては書いていませんが、これは今回引用した方々全員、およびはてなダイアリーユーザ全員を指しているわけではなく、特定少数の対象に向けています。 煽られたと感じる人は反応するのかな、というくらいの意図ですね。 これを元に「はてなダイアリー - 」という文字列に関する変更についての意見を聞き出したいなという意図もありますが。

あと、「はてなユーザ」という集合に、はてなユーザであるid:hxxkさんを含めないで論じられているように読みましたが、これの意味はなんでしょう。 「はてなユーザ」というのは、id:hxxkさんが<ひとくくりにして何か言いたい>ユーザの集合を指してますか。

確かに、自分を含めずに論じています。 私の言うはてなユーザという集合は、書き手としてはてなダイアリーを使っている方を指しています。

私もはてなダイアリーを使用させていただいていますが、あくまで外出時の報告か、はてなダイアリーへの要望を書くくらいにしか使っていません。 はてなダイアリーに対しては、書き手ではなく「読み手」であるという自覚を持っています。 ( そして、これまでも読み手の視点から要望は出したことはあっても、書き手の視点から要望を出したことはありませんし、これからもおそらく無いでしょう。 )

本来的な意味での「トラックバックする」とは、「あなたの記事に興味があります、ちょっとコメントしてみました」と、いうことであり、議論の種を相手に振っているようなものだと理解している。

たとえば、1エントリから19個の記事に対して、なで切りするように一つ一つに意見をつけてトラックバックを送る、ということは、トラックバックした19人全員から様々なリプライがあった場合、その答えに応答していくはらづもりが、あるのかなーと、今思った。

応答する気満々で話を振っています。 はてなダイアリー日記へのトラックバック ( 自動・手動問わず ) をきっかけにトラックバックを送っているのに、その後それに対するリプライをもらって応答しないということは、ふだん主張しているトラックバックの理念を自ら否定することになりますし。

私がトラックバックを送る際は、大別して「あなたの記事に対して私はこう考えましたよ」「私が書いた記事があなたの疑問の解決に役立ちそうなのでお知らせしますよ」という 2 パターンにおいて行っているので、トラックバックを送りっぱなしで後の意見の応酬を拒否することはしたくありません。 ( よっぽどズレた答えが返ってこない限りは。 )

Re: 海馬日記 - トラックバックが非公開でもはてなダイアリーにトラックバック送信は可能です

はてなダイアリー外からのトラックバックを受け付けないようにしている と言ふのは恐らく、トラックバックURL送信用のURLとか、受信したトラックバックとかが公開されてゐない事を指して仰ってゐるものと思ひますが、その場合でもはてなダイアリーはトラックバックを受信します。

この点を完全に誤解していました。 「トラックバック用の URI や、受信済みのトラックバックが記述されていない」 = 「トラックバックを受け付けないようにしている」と思い込んでいたのです。

海馬日記では受信したトラックバックを非公開にしてをりますが、トラックバックの受附け自體は一切拒否してをりません(そもそも拒否する設定がありません)。 トラックバックを受信したら、はてなの内外からに關はらず全て作者に通知メールが屆くやうに設定してあります。

ただ、この点はどうなのかな、と思いました。 送ったトラックバックが記事内に表示されない、即ち製作者以外には伝えられないのなら、トラックバックを用いずにメールで済ませてしまえば良いのではないかと。 送っても表示されないのなら、乱暴に言ってしまえば拒否しているのと同じです。

もちろん、トラックバックを拒否していること自体は何ら問題はありません。 そういったポリシーで運営している方ははてなダイアリーに限らず他の weblog でも多く存在しますし、「コメントやトラックバックがなければ blog じゃねえよ」なんて狭い考えを持っているわけでもありません。 ただ、「自動トラックバックのオフ」について繋がりを持ち出して語っているのにそういった設定を施すのは如何なものかという意味で、門外漢だけどはてなダイアリーの仕様変更に賛成 - ??? を書きました。 ( もりやまひろしさん ( 海馬日記 ) は、自動トラックバックのことというよりはてな側の実装に至る経緯について言及しておられるので、トラックバック非表示でも問題ないと思いますが。 )

あと今回の件との主題とは少し外れますが、トラックバックで第三者にも見えるように意見を述べるというのは、ある種のショー的な意味がこめられる場合もあるかなと思いました。 メールのように製作者本人だけでなく、より多くの人に考えてもらうきっかけとしてトラックバックを用いるといった感じ。

Re: :: The Perfect Insider :: - ・自動 TB ON/OFF 設定についてのあれこれ

まず自動 TB を否定する立場を考えてみると、限られた範囲に対しての私見になりますが、大別して「とにかく勝手に通知されるのはイヤだ」という意見と、「自動通知は否定しないけど、単なる id + アカウント名の表記程度ですら TB になる、あるいは TB と呼ぶのはおかしい」という意見があるように見受けられます。 自動 TB 肯定(= 自動通知肯定)の立場からすれば、前者に対しては「それが はてな クオリティ」みたいなことも言えますが、後者の場合、これは全くもって正論です。

私が言いたかったことが綺麗にまとめられています。 要するに、後者の意見を私は持っていて、今回の仕様変更でそういったトラックバックを設定次第とはいえオフにできるようになったので賛成、というスタンスでした。

つまり何が言いたいかというと、「id トラックバック」という名前を変更した上で、「ブログモード」での表示仕様を「日記モード」や「日記モード・見出し別ページ」にも適用してくれれば良いんじゃないかと、そう思うわけです。加えて手動 TB による自動 TB 上書き機能も実装してもらうとして、これなら はてな らしい自動通知はそのままに、前述した自動 TB 否定サイドの後者の意見にも対応できますよね。

これもそのまま同意。 これらのような実装になれば、自動通知が一律オンの状態であっても何ら問題は無いと思います。

Re: 勝手に将棋トピックス - 自動トラックバック設定について

私にとっては自動トラックバックは手動でトラックバックを送る手間を軽減する手段にすぎず、はてなダイアリーらしさがどうだとかいう印象は特に持っていませんでした。 「ご覧になっている方には関係ない」というのはそういう意味です。

なるほど、純粋に日記を書く際における部分ということで、読み手側に関係ないという表現だったのですね。 書き手側の理論しか考えていないと誤解していました。 申し訳ありません。

今回提示された選択肢というのは、URLの記述でトラックバックを制御するか、普通のウェブログでやっているように普通にトラックバックを送るかという二者択一であったわけです。 前者の方が手間は少ないですが、後のログ管理の手間を含めると後者の方が優れているかもしれない。 総合的にどちらが良いのかは、将来の運営方針に影響を与えそうだという意味重要であると考えました。

確かに後々のログ管理という面も考えると、一概に送信する時点で手軽である方が優れているとは限らないかもしれません。 私の話になって申し訳ないのですが、 Movable Type では MTPingsSent というタグが用意されており、これによって送信したトラックバックの管理をある程度行うことができます。 しかし、これで自動的に管理できる部分は実際は ping URI だけで、サイト名や weblog の記事自体の URI は管理できません。 そういった関係から、自分から送ったトラックバックは手動で管理しているのですが、やはり自分で後から見返す場合には手間をかけた分便利になっています。 そういった意味では、確かに小さな仕様変更でも運営方針に影響を与えるという見方は正しいと思います。

Re: フランス公法学研究日誌 - トラックバック考

最近でこそ言及したら原則TBの方針で*2臆面もなくばしばしTBを送れるようになったけれども、ブログをはじめて間もない頃は、「トラックバックを送信する」のボタンを押すだけで指が震えていたので、リンク即TBという機能は心理的抵抗をだいぶ和らげてくれた。

こういうメリットを挙げられる方は多く、それは良い意味でのはてならしさだと思います。 また、有用なトラックバックとはを参考リソースとして挙げられていますが、付加価値を伴うべきといったくだりは本来の意味でのトラックバックにおいて述べたものなので、もしはてなの自動トラックバックが別の名称になればその議論の対象からは外れ、言及やリンクの通知だけで送っても良いと思います。

はてなを(そもそもブログを)はじめてまだ半年足らずなので、今回の仕様変更がはてならしさを奪うといった議論*4は(なぜ「はてな内」にそんなに拘るのかが)よくわからないけれども、単純に便利なので、過去記事を直すとき以外は自動TBはONにしておくつもりだ。 というわけで自動でTB飛んじゃった人うざかったら(*_ _)人ゴメンナサイ 。

よって、便利なのでオンにしておくという姿勢もアリだと現在は考えています。 もし自動で通知が飛んでくるのが煩わしいという人がいるのなら、受信側での ON/OFF を設定できるように働きかけるという手段もありますし。

Re: 二拍三連の足音

ひょっとすると、肯定派の方は自動トラックバック機能を切って(もしくは自動トラックバックが飛ばないようにして)言及しているのかも、と思いました。 (私自身、もう少しでそうするところでした・・・)

なるほど、そういう見方もありますね。 ただ、そういった場合ならなおさら手動トラックバックで言及してもらいたいというのも、門外漢からの希望としては持っています。

ところで、タイトルから「はてなダイアリー」が抜けたことについては、かなりの日記で言及されていたように思うのですが。トラックバックが3件だけというのはかなり不思議です。

わたしは上部にはてなのバーもあるしいいかなあ、と思いタイトルはいじっていません。

はてならしさって言葉はややこしいのかもしれないな、と思ったりしました。人それぞれ、なにを「らしさ」とするかは違うでしょうから。

でも以下の動きはかなり好きだったりします(笑)

「はてなダイアリー -」を含むキーワード・日記

もしかしたら、トラックバックからではなく「含む日記」から探せば、言及していた日記を見つけられることができたかもしれませんね。 ( まあ、「はてなダイアリー - 」の部分は本題じゃないのでそこまではしませんが。 )

あー、はてなダイアリー - 「はてなダイアリー -」を含むキーワード・日記のようにして探せば良かったのか……。 けっこうな数があるかと見るか、これだけしかないのかと見るか微妙な数ですけど、私としまけんさん ( はてなダイアリー - KLaxon - O.P. on HATENA ) だけじゃなかったと思うとちょっと嬉しいです。

Re: 香雪ジャーナル - 「hxxk.jp - 門外漢だけどはてなダイアリーの仕様変更に賛成」およびidea:3154に関して、まとめておきます(6/24昼追記)

まず、最初にお断りしておきます。 香雪さん ( 香雪ジャーナル ) は最初にはてなアイデア - "referred" の欄を復活させて、従来の自動トラックバックには一律にそちらに羅列し、手動によるトラックバックをトラックバック欄に羅列するようにして欲しい。を読んで香雪ジャーナル - 「自動トラックバックon/off設定機能」実装を歓迎するユーザには「*自動で*送る/送られるのが嫌だ」という「自動」に重点をおいて判断している方も多いようなのでを書かれていますが、私がはてなアイデアに対してトラックバックを送っていなかったため、どういった経緯でそのアイデアが出てきたかを知らない状態で書かれていました。 その後、私からトラックバックを送ってアイデアが出た経緯を知ってもらい、また香雪ジャーナル - 「hxxk.jp - 門外漢だけどはてなダイアリーの仕様変更に賛成」およびidea:3154に関して、まとめておきます(6/24昼追記)として追記して下さいました。 ( お手間を取らせてしまい、申し訳ありません。 ) よって、追記部分のご意見をもとにこちらのアンサーを書こうと思います。

自動トラックバック」(idトラックバック)が「自動」だったということ、つまり、「言及したという通知」が「自動で相手に送信される」という仕様のものに関して本質的に考慮すべき問題があるのではないか、ユーザでもon/off設定を考える際に「自動」で送信されるかされないかという点に判断のポイントをおいている人が多いのではないか(自分自身もreferredだったころから『自動で相手に送られる』ことが気になるので)、とわたしは考えその点を主題に上記日記に書きました。

そしてこの「自動送信」を拒否したいユーザ意思の解決のためには「 "referred" の欄を復活させて、従来の自動トラックバックにあたるものは一律にそちらに羅列し、能動的に送られたトラックバックトラックバック欄に羅列するようにすれば、はてなダイアリーの特色を持ったまま、情報の選別ができて良いと思います」といった主旨のidea:3154それだけでは十分ではなく、また、「自動トラックバックon/off」の解決策として考えるなら本質の部分には考慮が届いていないのではないか、と思いました。 解決すべきポイントとしてはもっとその先の、たとえば"referred"を自動送信するのかどうか・表示はどうするか・受信側に選択権を与えるか、等々の様々な検討課題があるはずです。

私は、読み手としてはてなダイアリーのベータ版の頃からはてなダイアリーに触れていましたが、自動で相手に送られるシステム自体には肯定的に見ていました。 もちろん、それによるスパム行為などもあったり、また私の知らないデメリットも多々あったのでしょう。 しかし、やはり自動送信というものははてなの特徴であるというのは、私が触れたダイアリーでも良く見られたことですし、検討課題を解決して残って欲しいと思っています。

今考えているのは、「送信側は一律に送信する ( OFF にできない ) 」、「受信側でその可否を設定する ( ON/OFF の選択が可能 ) 」という状態です。 これですと、基本的には手軽に繋がりを得られる、言及をされていることを自動で知ることができるというメリットを残したまま、本来の意味のトラックバックしかいらないという人や、自動通知が煩わしいと思う人への対応も可能だとは思います。 ( もちろん、完璧な案ではないので、もう少し考えを練りたいところですが。 )

つまり、

  • idea:3154は正論であり、それ単独で実装されるべき提案ではある。
  • しかし、少なくともそれだけでは「(書いたことを相手に知らしめる)通知」の自動送信の是非についての解決にはならず(しかし実装した上で解決のために役立てていくことができ、解決の可能性を広げる……ということはきちんと書いていませんでした。すみません)、「自動トラックバックon/off設定機能」とは両立可能の案である。
  • 考えるべきポイントは、idea:3154を実装した上でももっとその先にたくさんある。

というふうに考えています。

このように、私の考えを否定するのではなく、足りない部分を補うような指定をして下さったことに感謝しています。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

門外漢だけどはてなダイアリーの仕様変更に賛成

記事データ

投稿者

望月真琴

投稿日時

2005-06-22T21:43+09:00

タグ
概要

はてなダイアリーの自動トラックバックをオフにすることができるようになったことについて、様々な反響があるようです。自動で送るものも「トラックバック」と言っているから議論が複雑になるのであって、以前の「 referred 」という表現を使えば良いだけの気がしますが。

リプライ

14 件のリプライがあります。

記事本文

はてなダイアリーで自動トラックバックを送らないようにすることが可能になりました

はてなダイアリーではID記法利用時、あるいははてなダイアリー内の日記へのリンクが本文中に記載された場合に、自動でトラックバックを送信する機能がございます。

この自動トラックバックを送信するかしないかを設定できるようにという要望を多数いただいたため、本日設定項目を追加いたしました。

個人的に、はてなダイアリーの中で最も悪いと感じていた点に改善の兆しが見えました。 その理由はトラックバック≠リンク通知の記事タイトルに表れていますが、何ではてなダイアリー同士ではリンクするだけでトラックバック扱いになるんだろうと。

はてなダイアリー - 自動トラックバックとはからはてなダイアリー - リファとはというキーワードを辿ると、

はてなダイアリーで他ユーザーの日記から記述や個人IDが言及・参照されると、編集画面のリンク先表示として、"referred"の項目が上位に立ち、その箇所のURLが表示される。 ……仕様だったが、ブログサービスで「トラックバック」の呼び名が広まったことなどから現在では「トラックバック」表示に変更されている。

という経緯があったことを知ることができます。 確かに "referred" という表記だった時期があったことは覚えています。 それがいつごろ変更になったかは忘れましたが、 "referred" という表現の方が良かったと思います。

何故自動トラックバックが良くないのか

何故自動トラックバックが良くないのかと考える理由は至ってシンプルで、「単に紹介や自分用のクリップで取り上げたものなのか、本来の意味でのトラックバックか区別が付かないから」というものです。

たとえば、今回の変更に伴うはてなダイアリーユーザの反応を私が見てみたいと思った場合、トラックバック欄からこの変更のアナウンスにトラックバックを送っているダイアリーを辿っていく方法を採ります。 そういった場合に、単にそのアナウンスを取り上げただけのダイアリーは、表現が悪いかもしれませんが単なるノイズにしかなり得ません。

もちろん、はてなダイアリー以外の weblog サービスや weblog ツールでも、そういった何ら付加価値の無いトラックバックは存在します。 ( 有用なトラックバックとは - 中身を伴わないトラックバック ) ただ、それはそういったトラックバックを送る人がトラックバックに対する理解が不充分なだけで、あくまで能動的に送られるのに対し、はてなダイアリーではトラックバックを送る人の理解度の高さやトラックバック自体の付加価値の有無に関わらず、トラックバックが自動的に送られるようになっていました。 繰り返しますが、自動でトラックバックを送る仕様では、トラックバックを手がかりに更なる情報の広がりや、元の情報に対する意見や反応を探したい時に本来求める情報がノイズに埋もれてしまいます。

今回の変更に伴うはてなダイアリーユーザの反応を見てみる

前項では「たとえば」という前置きで書きましたが、実際にユーザの反応を見てみたいと思ったのです。 肯定派と否定派に分けて考察するとはてなダイアリーユーザの空気を読み取れるかなあと。 私もごく稀にはてなダイアリーに書いていますが、たいていははてなダイアリーへの要望を書くか、携帯電話からの臨時更新か、システムがどうなっているかの確認をするかの 3 つのパターンしかないので、はてなダイアリーという一種のコミュニティの中にいる意識は全くありませんし。

で、 http://d.hatena.ne.jp/hatenadiary/20050621/1119347555#tb からユーザの反応を見てみると……ほとんどが否定的な意見ばかりでした。 やはりこのあたりははてなダイアリーユーザにとっては重要な特徴だったのでしょうか。

今回の変更に伴うはてなダイアリーユーザの反応に反応してみる ( もしくはトラックバック送信備忘 )

裏紙草子 - トバラックル大好きっ子さん

単なる言及なのか? トラックバックする価値があるか? を考えると正しいのだろうけど、今までオマケで貰えていたTBがなくなってしまう! 持たざる者からさらに奪おうというのか? トラックバックから始まる恋は存在しないのか? じゃあ「キーワードがウザいから除けて下さい」って要望が沢山出たら止めるんですか? あと悪口の防止になってたと思う。

あー。 でもクリップとかでトラックバック飛ばしたくない。 だとかの人が多いのかもしれなくて、それで要望が多いのかな? 何にせよ、はてなアイデア。 賛成数は程度計れても、それに対する反対表・意見は全くといっていいくらい計れないのは問題なのでは……

あと良く考えたら、トラックバックとは別に、記載されたダイアラーにだけは、その事が伝わる仕組みがあればいいような気がしてきた。

トラックバックってオマケで貰うようなものじゃないと思うのですが……。 後に述べていますが、以前の "referred" 欄を復活させれば、恋も始まれば悪口の防止もできると思います。 けんたろたん風に言うと「リファから始まるモテダイアリー」略して「モテリファ」って感じで ! ( けんたろたん、勝手に引き合いに出してごめん ! )

おれはおまえのパパじゃない - IDトラックバック仕様変更

これははてなダイアリーを支えるものすごく重要な、恐ろしく重要な仕様(というより思想)だと俺は認識していたのでどうなるかドキドキだったのですけども、結局実装されたのでちょっとひるんだ。 およそ2歩くらいへなへなと後退しました。 俺が。 出来れば「これははてなの思想そのものです」と言って突っぱねてほしかった。

確かに、リンクをすることで自動的にトラックバックとして処理され、相手が容易にそのことを知ることができるというのは、はてならしい仕様だと思います。 ただ、それを「トラックバック」と表現することではてなダイアリー以外でのトラックバックとの意味に齟齬が生じてしまっている現状はどうかと思います。 "referred" という表現ではだめでしょうか ?

渋谷系@シプヤ - また一つ

らしさの象徴が消えて行く

消えたのですか ? デフォルトでオフになったわけではなく、ユーザが能動的にオフにしない限りはそのまま残っていると思うのですが。 敢えて非ユーザの立場から煽りとも言える言い方をすると、 「オフにすることができるという選択肢ひとつで吹き飛ぶ、そんな脆弱な象徴だったのですか ? 」 と。

勝手に将棋トピックス - 自動トラックバック設定について

ご覧になっている方には関係ないのですが、書いている側にとってはかなり大きな変更です。どうするか考えたいと思います。

見ている側にとっても関係はあると思います。 オフにする方が多くを占めた場合は「そのダイアリーに対する反応をトラックバックから探したい」という私のような閲覧者には歓迎されると思いますし、逆に「そのダイアリーにリンクしている、取り上げているダイアリーを探したい」という閲覧者は戸惑いを覚えるかもしれません。

gobbledygook - 火曜日だというのに核クラスの変更が……。

つか、あっちゃー、やっちゃったーって感じ。 気軽にトラバを投げる事が出来るし、記事じゃなくて、無条件に「人」に対して言及通知*1をする事が、はてなダイアリーのコミュニティーを形成しているとは思わなかったのか?

つか、はてな内にも、今回の各種バトンが廻ったけど、こんなに広がった理由とか少しは考えなかったのか? かなりその辺りが疑問。 つか、もうちょい考えてよ。

少なくとも、id記法は無条件に飛ぶべき。 http〜は構わないけど。

無条件に「人」に対して言及通知をする事が、はてなダイアリーのコミュニティーを形成している のなら、この変更がそれに及ぼす影響は無いと言っても良いのではないでしょうか。 デフォルトでオフになったのではありませんし、能動的にオフに変更する方がどれくらいの人数になるかは今後の動向次第ですが、それがコミュニティの形成を崩壊させるほどの人数になるとは予想できません。

少し本題と逸れますが、はてなダイアリー内での各種バトンは逆に自動トラックバックが弊害となっていたと思います。 元々トラックバックでバトンを廻すという発想自体がおかしいと私は思っていますし、それによって強制された印象を抱いたり、不幸の手紙と大差無いという評価をした方が少なからずおられました。 はてなダイアリーでは、むしろ「こんなに広がった」ではなく「過剰に広がってしまった」という印象を広がりの一部を辿った者として抱きました。

はてなダイアリー - KLaxon - O.P. on HATENA

…デフォルトがオンでよかった…と思いましたよ。コレ、オフにしちゃったらはてなダイアリーの価値がなくなっちゃうと思うんですけどねぇ。

私はむしろデフォルトでオフにしてもらいたいくらいの気持ちを持っています。 もしくは、後述するように "referred" の欄を復活させて区別するようにするか。

:: The Perfect Insider :: - ・備忘録 - 自動トラックバック設定

この自動トラックバックって、はてなの象徴みたいなものの1つだと思ってます。 はてならしさ。 そういう部分をあえて切るのはって言うか、オフにする設定があること自体、大げさに言えば自己矛盾的でもったいないと感じてしまいます。

確かに象徴かもしれませんが、オフにする設定が加えられたくらいでは自己矛盾と呼ぶほどの変更ではないと思います。

コトバノツドイ - グミジャムデキタ - 自動トラックバックのON/OFF設定について

自動トラバはてなの一つの文化だったとも言えるのではなかろうか。 それがはてな内で閉塞してしまうような雰囲気を作っていたり、何でもかんでもトラバしてしまってトラバ嫌いな人を困らせたり、などというデメリットはあったかもしれないが、それも含めてはてなだったのだと思う。 この自動トラバ機能のおかげで繋がった人がいたということもまた事実だろう。 そういうはてな独特の「クセ」みたいなものが他ブログへの擦り寄りで薄められていっているような気がして。

デメリットはあったかもしれないが、それも含めてはてなだったのだと思う と、デメリットを自覚した上でそう考えるというのは良い考え方だと思います。 ただ、はてなダイアリー外から見ると、やはりそういったクセはなかなか見えて来ず、デメリットばかり目立ってしまっていた感があると思います。

Cablog Annex - 自動トラックバックのON/OFF設定について

従来は、「それほど意識してなかったら勝手にTBしちゃうし、それがはてなだし」ということでよかったんだが、今後は「ええ、意図的にTBしましたが何か?」ということだよな。 それが普通のBlogじゃんといえばその通りなのだが。

確かに、オフにする設定があるということは、完全な自動トラックバックではなく意図的なものが介在するものになると思います。 ただ、それをトラックバックとしてではなく "referred" という表現にするのであればどうでしょう ?

Reactor - 自動トラックバック機能

まだまだ普通の文中(自動トラックバック)と

「あなたの記事に関連した記事を書きましたよ!ってお知らせ」という

本当の意味でのトラックバック*1を使い分けない人がはてなユーザーに多いのがちょっぴり困ったところなんですけどねw

同意見です。 "referred" の意味でのものと、本来のトラックバックが混同されている現状があるために、使い分けない人がはてなユーザに多くなっているのだと思います。

nopikoメモ。 - はてな複数ID可

自動TBまで選択可になってほんとにショックだ。 のすたるじーなのはわかってるけれどショックだ。 私の求めるはてなじゃない! 私の愛したはてなじゃない! はてなに戻って! とはいちおう叫んでおかないと僕じゃない気がするから叫ぶけれど、でもそれにしてもショックだ。 ショックで寝込みそうだ。 世は無常ですね。 諸行無常。 人もはてなも変わるってこと。

自動トラックバックを一律適用することがはてなダイアリーのあるべき姿なのでしょうか。 ( いちおう叫んでおかないと僕じゃない気がするから叫ぶ と書いてあるので、多少誇張しているのでしょうけど。 ) ユーザの要望を集め、それを反映してくれるのがはてなの良い特色だと思うのです。

私の意見に返事が来ました。 朝に下駄箱に入れたラブレターが昼休みに体育館裏に呼び出されるくらいの迅速さ。 いやそんな経験はありませんしそれは果たして迅速って言うのか。

多少っていうか相当っていうか・・文脈読め的な自己満足的修飾なんでw 個人的な感慨であってべつにはてな意見したかったわけじゃないってことですよね。 こうあるべきとはいってなくて、というかそれを模索するのをさぼって、昔あったはてなを懐かしんで「昔はよかった」とかいってるだけで、こーゆーのが一番性質悪いんですよね、ほんと。 消費者の位置にあぐらかいてるの。

昔はよかったと呟くだけでも、それもひとつの消費者の意見になるのではないでしょうか。 直接的に意見をくれるユーザも大事だけど、それ以外にも「自分はこう思う」とだけ意思表示するユーザの意見って実は重要だったりしますし。

RERO!! - 強制自動トラックバックが強制じゃなくなった日

これで、はてなにはなかった手動トラックバックを送信する何か新しい文化が根付くのかもしれない(の前にトラックバック表示欄をもっと見やすくしろっていうのはあるケド)。 読んで欲しい記事とはてな汁との区別が付きやすくなるのかもしれない。 自動トラバ派と手動派のつまらん洗脳合戦も出てくるのかもしれない。 取引先相手のバリエーションがナらされて「はてな内完結」を忌み嫌う人が減るのかもしれない。

そうした流れが出てくれると、非はてなダイアリーユーザとしては歓迎。 もしくは自動トラックバックと手動トラックバックとの明確な区別をトラックバック表示欄にて付けるようにするとか。 しかし、はてな汁 ( 自動トラックバックによって送られたトラックバックのことだと思われます ) という表現は秀逸だなと思いました。

海馬日記 - 自動トラックバックの「ON・OFF設定」追加は最も安易な方法ではないか――idea:1855の實裝方法について

自動トラックバックによって新しい「繋がり」が生じ得るのがはてなダイアリーの魅力の一つだ、と考へてゐる人が存在するであらう事は或程度豫想してゐたし、はてなの中の人も其の邊は承知の事で、なほ且つ自動トラックバックははてなダイアリーの機能的な「目玉」であると自認してゐるものとばかり思ってゐたので、今囘の仕樣變更には正直驚いてゐます。 自動トラックバックを殘しつつ、手動トラックバックとの重複やタイトルの問題を解決するのは、技術的にはさう難しくないのではありませんか。

新しい繋がりを得るのに「トラックバック」である必要はあるのでしょうか。 自動トラックバックを何か別の扱いにして、手動トラックバックと明確な区別を行えば、転じて重複やタイトルの問題も解決しそうな気がします。

焚書官の日常 (4.4.1) - 自動トラックバックがオフにできるようになった

自動トラックバックをオフにするのは自由だし、それほど強いtbの意志のない相手に対してtbしてしまうことが避けられることは利点ですが、

  • オフの人とオンの人の間での、「自動tbウザい」「うっさい」という対立の可能性
  • id言及という気軽なやりとりの芽を摘む可能性

などがあると思います(ほとんど言いがかりであり合理性はありません)

別に全てがオフになればいいと思っているわけではないので、デフォルトオフでも、簡単にid言及でトラックバックを送れたほうがいいです。

確かに、 id 記法で言及をできるという手法は残しておいて良いと思います。 ただ、それを「トラックバック」という表現でひとくくりに扱っているがために、自動トラックバックの是非が問われて問題がややこしくなっていると思います。 別に必ずしも「トラックバック」という表現でないと気軽なやり取りができないわけではないでしょう ? あくまで id 記法による言及の「手法」が重要なのであって、その名称を本来のトラックバックと区別することは問題ないはずです。

おすましエプロン - はてな・自動トラックバックのON/OFF設定

選択制になっちゃったら、「私はそんなつもりはなかったんですけどー」的な自己防衛機能がブチ壊しじゃないですか!「そんなつもりはなかったなんて、自分で選んだんだろ…?」って鋭い目と低い声で囁かれて、団地妻の光子も泣きながら崩れ落ちてセールスマン斎藤との官能の日々に溺れていくわけですよ何の話ですか。

本来の議論点とは全く関係ないけど、斎藤と光子のくだりに爆笑。

いやでもそれはともかく、はてなの仕様だからということにして自己防衛できるというのがはてなの良さだというのはちょっと違うなと思います。 気軽に繋がれるというメリットはまだ理解できますけど、言及とするには弱いアピールをごまかすというのはメリットじゃないなと。

二拍三連の足音 - リンク=トラックバックのON/OFF

リンクするとトラックバックになる、というのがはてなダイアリーらしさだと思っていたのに。

それをあっさりなくしてしまうなんて。

リンクすると、それがトラックバックになるというより、リンク先の相手 ( および閲覧者 ) に明示的に分かるようになっているというのがはてなダイアリーらしさということでしょうか。 リンクイコール「トラックバック」というのには賛同しかねますが、その表現を使わずに、何らかのリンク通知機能がはてなダイアリーらしさだというなら、同意見です。

夜盗虫の朝寝坊 - 自動トラックバックをOFFにすべきか

む。 自動トラックバックをOFFにする設定が選べるようになってしまったぞ。 いままでわたしは明確な意志をもって相手にトラックバックしたことはない。 はてな内でリンクしたら自動でなってしまっていたのだ。 それがOFFに可能に。 となれば、トラックバックを送るということは、わたしがその選択をあえてやっている、ということになりはすまいか。 送るぜ、いぇー!と。

そんな。 押しつけがましい。 こそこそとやるのが信条なのに。 しかし、「あえて」設定を変えるのもどうか。 それはわたしが明確な意志をもってトラックバックを送らない、と決めたことになりはすまいか。

選択できるようになったということは、確かにオンにしている人は進んでそうしているという見方もあるでしょう。 しかし、デフォルトでオンという状態なので、そこまで気にしなくても良いのではないでしょうか。

SHIRI MAN

編集画面に誰かの id を記すということは相当に勇気の要る行為であって、でもそれを乗り越えてリファを飛ばした結果はじまった交流は数え切れない。 また、はてなのことをよく理解しないうちに何の気なしにリファを飛ばした結果、はじまった交流も数え切れない。

それは、確かにこのシステムの大きなメリットだと思います。 引用元でも リファ と表現していますが、別にトラックバックという名前でなくとも、リファという名前でもそのメリットは変わりませんよね ?

はてなの思想とかはてならしさとか言っている人に疑問

何ではてなダイアリー日記 - head内のtitleの表記についてについて反応している人がほとんどいないんでしょう ? title 要素からはてなダイアリーの文字が消えることの方が、よっぽどはてなダイアリーらしさが失われていると思うのですが。

メインで使っていないとはいえ、はてなダイアリーという名称に愛着を持っていたので、自分のはてなダイアリーにははてなダイアリー - 真琴@臨時更新場と、意図的に「はてなダイアリー - 」という名前を先頭に付けています。 今回の仕様変更について反応しているダイアリーで、この title 要素の仕様変更の時にダイアリー上で反応しているのははてなダイアリー - KLaxon - O.P. on HATENAのしまけんさんだけでした。 ( はてなダイアリー - KLaxon - O.P. on HATENA - はてなダイアリーじゃなかったらココの価値なんざないので… )

なお、その変更がなされた時点で、しまけんさんも同様に「はてなダイアリー - 」という名前を意図的に付けていますが、それ以外の方は、 title 要素という HTML の中で最もその内容を如実に表す部分において、はてなダイアリーの文字が入らなくなったという大きな変更について何ら疑問を抱かずにいたのでしょうか ?

煽りを承知で言わせてもらうと、 title 要素の変更の時にスルーしておいて今回だけやれ思想だやれらしさだ、と騒がれても全然説得力無いですよ、と。 極端な話かもしれませんが。

ここまで書いて考えがまとまった

はてならしさだとか id 記法による手軽な繋がりだとかといった面と、それによって送られるトラックバックの是非がごちゃまぜに語られるから色々とややこしくなっている気がします。 というか自動トラックバックも能動的なトラックバックも同列に扱ってしまうから、トラックバックに対する間違った理解がはてなダイアリーユーザに広まるし、またはてなダイアリーユーザ以外からは変なシステムに見えてしまうしということになっているのではと思いました。

たとえば、自動トラックバックを以前のように "referred" という欄に表示するようにし、本来の意味でのトラックバックをトラックバック欄に表示するように分ければ、

  • 記事じゃなくて人に言及したい
  • 自動トラックバックか能動的なトラックバックか区別しづらい
  • トラックバックとは関連のある記事に送るもので、リンクしたから送るものじゃない

といった意見や要望は解消できるのではないのでしょうか。

ということで、現状に即した解決案

今回の自動トラックバックのオン / オフの選択肢を設けるのではなく、 "referred" の欄を復活させて、従来の自動トラックバックにあたるものは一律にそちらに羅列し、能動的に送られたトラックバックをトラックバック欄に羅列するようにすれば、はてなダイアリーの特色を持ったまま、情報の選別ができて良いと思います。 現在ははてなダイアリーへの要望ではなくてはてなアイデアに書いた方が良いんでしたっけ ?

はてなアイデア - "referred" の欄を復活させて、従来の自動トラックバックには一律にそちらに羅列し、手動によるトラックバックをトラックバック欄に羅列するようにして欲しい。 というアイデアを登録しました。 id:3154 です !

???

自動トラックバックのオン / オフの選択肢追加について意見を述べているダイアリーを選んで反応してみたのに、はてなダイアリー外からのトラックバックを受け付けないようにしているところが散見されるなあ。

繋がりとか交流とか言っているのに、何故はてなダイアリー以外からの繋がりや交流の可能性を否定するのだろう。 この内容を自分のはてなダイアリーに転載して、現在オフにしている自動トラックバックをオンにして id 記法でも使えばトラックバックを送れるのだろうけど、そこまでして意見を伝えたいわけでもないし、繋がりたいわけじゃないのでそのままにしておく。 ( ここだけ文体が常体なのは、自分の呟きを表した文章だからということで。 )

自分のアイデアにトラックバック送るのを忘れていた

この場合は、この記事から私のアイデアにもトラックバックを送っておくべきでしたね。 ( どういった経緯でこのアイデアが出たかを明確にするため。 ) というわけで後付けでトラックバック。 また、このアイデアについて香雪ジャーナル - 「自動トラックバックon/off設定機能」実装を歓迎するユーザには「*自動で*送る/送られるのが嫌だ」という「自動」に重点をおいて判断している方も多いようなのでにて意見を書かれていたので、もしかしたらアイデアを出すに至った経緯のこの記事を見ていない可能性があるかもということで同じく後付けトラックバック。 ( 改めて香雪さんに対するアンサー記事を書きます )

さて、この記事に関して多くのコメントやトラックバックをいただいたので、それに対するアンサー記事に取りかかろうと思います。 ( コメントについては返答済 ) 明日は帰宅が遅くなると思うので土曜日から日曜日くらいになってしまうかもしれませんが、話を振った以上は応答するつもりです。 もしくは、一つの記事にまとめるのではなく、それぞれのアンサーに対して随時公開していくか。

リプライ

14 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-06-22T22:42+09:00 - CC

ご紹介ありがとうございます。ReactorのCCです。「現状に即した解決案」を拝見しましたが、これはまさに現在はてなダイアリーで日記の選択肢として採用されているシステム「ブログモード」(http://d.hatena.ne.jp/carina_canopus/20050513#1115951117)に相当するものですね。はてな側はこうしてブログ慣れしたユーザの要望にも応えてきてますし、先述したようにトラックバックの機能も整えてきてるんですけど、いかんせんそれを使うユーザのほうが機能を知らなすぎるんですよねぇ…。自分もできるだけ日記のなかではてなの仕様変更には触れるようにしてますが。 ともあれ、はてなの仕様、現状に共感してくださる方にトラバを頂いてうれしい限りです。今後もはてなの外から見た意見をお願い申し上げます。ではでは。

2005-06-22T22:55+09:00 - 門外漢だけどはてなダイアリーの仕様変更に賛成 < 渋谷系@シプヤ

http://hxxk.jp/2005/06/22/2143 消えたのですか ? デフォルトでオフになったわけではなく、ユーザが能動的にオフにしない限りはその...

2005-06-22T23:31+09:00 - [はてな]リファとトラバ < コトバノツドイ

はてなの自動トラバのオンオフ機能について、けっこう議論が紛糾しているもよう。私のところにもいくつかトラバを頂いている。こうやってトラバを頂くと、言及されているこ...

2005-06-23T00:09+09:00 - 自動tbへの感想に関して、引用していただきました

tbと言及がワヤになってるという主張には大筋同意。ただどうしてこういう書き方をされるか、よくわからないです。

2005-06-23T00:15+09:00 - uragami

どうも、「トバラックル大好きっ子さん」の裏紙です。 チラっとは書いてたのですけど、これまでの設定、言葉の定義で考えると不自然なんですよね。 ただ、言及された事がすぐ判るのは便利だったのです。なので「甘え」のような感情があったんですね。日記には、その辺りを誇張して、「はてな」らしさよりも、自分にとって便利かどうかを書いたつもりです。 あと日記タイトルの「はてなダイアリー -」がなくなった日は、その他にも色々な機能が実装されてたので自分も何か書いたと思うし、送られたトラックバックが、たった3件というのは…… ちょっと不思議な事になってます。

2005-06-23T00:47+09:00 - トラックバックが非公開でもはてなダイアリーにトラックバック送信は可能です < 海馬日記

自動トラックバックのオン / オフの選択肢追加について意見を述べているダイアリーを選んで反応してみたのに、はてなダイアリー外からのトラックバックを受け付け...

2005-06-23T03:07+09:00 - [Web]・自動 TB ON/OFF 設定についてのあれこれ < :: The Perfect Insider ::

昨日書いたテキストについての補足とか続きとか、もう少し思うところを書いてみます。もう少しと言いつつ、かなり長文です。 繰り返しになりますが、発端となった話題はこ...

2005-06-23T03:58+09:00 - [雑記] 自動トラックバック設定について < 勝手に将棋トピックス

自動トラックバックのON/OFF設定について ご覧になっている方には関係ないのですが、書いている側にとってはかなり大きな変更です。どうするか考えたいと思いま...

2005-06-23T05:29+09:00 - [ネット]トラックバック考 < フランス公法学研究日誌

はてな内のほかの日記にリンクしたときに発動される自動トラックバック機能がON/OFF切り替え可能になったらしい((http://d.hatena.ne.jp/h...

2005-06-23T19:25+09:00 - 自動トラックバックについて < 二拍三連の足音

トラックバックを頂いたhxxkさんの記事への返答です。 で、 http://d.hatena.ne.jp/hatenadiary/20050621/111...

2005-06-23T22:28+09:00 - 真琴

> CC さん ブログモードはそういった形式だったのですか ! 記事別表示になったときは http://hxxk.jp/2005/02/11/2333 で取り上げて自分で調べましたが、ブログモード実装の際はそれを行っていませんでした。ありがとうございます。 ブログモードでこういう実装がされているのなら、今後また改善されるかもしれませんね。 http://i.hatena.ne.jp/idea/3154 の展開も合わせて期待。

2005-06-23T22:29+09:00 - 真琴

>裏紙さん こんばんは。裏紙さんのダイアリーからははてならしさをアピールしているというより、そういった利便性を語っているように読めました。 名称はともかく、手軽にリンクされたことを知ることができるというのは大きな利点だと思いますので、そのシステム自体を否定するつもりはありません。よく考えたら、「オマケでもらうものではない」という私の意見も、それが「トラックバック」という名前だったからそう考えてしまった感があります。 ( 「リファをもらう」だったら、多分そこには触れなかったでしょう。 ) あと、タイトル絡みでは http://d.hatena.ne.jp/uragami/20041228/1104253363 も拝見していたのですが、「はてなダイアリー - 」が消えることに肯定的だったので、記事中では触れませんでした。 ( あの変更に対するトラックバックが少ない、というのは確かに感じました。常に目に見える部分なので反響が大きくなりそうなのになあ。 )

2005-06-24T14:50+09:00 - [hatena] 「hxxk.jp - 門外漢だけどはてなダイアリーの仕様変更に賛成」およびidea:3154に関して、まとめておきます(6/24昼追記) < 香雪ジャーナル

この項、6/24昼追記。 念のため上記に書いてきたことを簡単に再整理しつつ書いておきます。 idea:3154…[http://i.hatena.ne.jp/...

2005-06-25T00:26+09:00 - 自動トラックバックとはてならしさの所以 < 渋谷系@シプヤ

http://d.hatena.ne.jp/jkondo/20050624/1119567895   http://hxxk.jp/2005/06/22/214...

Musical Baton の真琴なりの総括

記事データ

投稿者

望月真琴

投稿日時

2005-06-20T19:21+09:00

タグ
概要

Musical Baton の感想やトラックバックからのピックアップ、およびちょっとした小言。

リプライ

リプライはまだありません。

記事本文

Musical Baton を終えて ( いや細々とまとめは更新しているけど )

何だか予想の範疇を超えて、多くのサイトからのリンクをいただいて驚いています。 ( 今までに、大きなアクセスを持つところから単発でリンクされてから広がるということはありましたが、多数のサイトからリンクされて、その状態がしばらく続くというのは初めてのことだと思います。 ) まとめをするにあたって Musical Baton について触れているところを廻るうちに、何件かは苦言を呈しているところも見受けましたが、多くの方は楽しんで回答しているようでした。 もちろん苦言を呈している方の意見も筋が通ったものが多く、次に似たようなものに触れる際には思い出そうと思いました。

また、 BLOG界の出来事:◆広まるバトン 広がるバトンにまとめられていますが、亜流バトンも多く発生しているようです。 私自身はこういった遊びは最初の 1 つをとことん遊び尽くしてしまうタイプなので、 Musical Baton 以外のバトンについては触れませんが。

あ、それと「泥臭い」という表現をまとめ記事のタイトルに使ったせいか、 Musical Baton 自体が泥臭いものだと感じてしまった方も若干おられるようです。 ( 私の勘違いだったらすみません。 ) 「泥臭い」はあくまで手作業で行った私のまとめ手法に係る形容詞ですので、そこだけははっきりと書いておこうと思います。

トラックバックに返答またはトラックバックからピックアップ

今回、多数のトラックバックをいただき、その中で他のまとめ記事の紹介や、私に対する意見などが見られたのでそれに対してのレス。 トラックバックをいただいたことをきっかけに話を膨らませたり、また読者に対してプラスアルファの情報を効率よく伝えるというのがトラックバックという機能の本懐ではないでしょうか ! と力説したいのですがまあそれは他の機会に譲るとして。

スローストロー - Musical Baton変遷記(真面目版)

キーワードやバトン廻し元を使って経路を辿るという方法の考察。 私が作った Musical Baton の泥臭いまとめは、バトン廻し元を辿って上流に上り、そこからバトン廻し先を辿って下流に下るという方法でしたので、着眼点は同じでした。

こわいものしらずのこわいものみたさ: みゅじかるばとんの元祖はMuziekstokkieなのだろうか。

2004 年 12 月 17 日分まで、上流に向かって辿っています。 私みたいに起点をあらかじめ定めたまとめよりも、経緯を知るには良いのではないでしょうか。

今日の覚え書き: Musical Baton を逆流してみた

どうやら途中で管理人さんが面倒見切れなくなったらしく(このスピードじゃ当たり前)、私が回した5サイトさんへのリンク掲載までで止まってしまった様子でした。 残念。 もっと辿っていきたかったのに…。

現在は自分が廻したサイト、および直接の知り合いのサイトの部分だけを続けている状態ですので、ある程度のところでまとめは止まっています。 辿りたいところがあれば、ご自身で辿ってそれをネタにすると良いのではないでしょうか。 ( 「自分が流した Musical Baton の行方を追ってみた」といった感じで )

杉の木工房 - 雑記(05/06) Musical Baton (2005年06月18日)

自分のバトンの源流を辿っておられます。 私のバトンから 9 世代後の方なので、 Musical Baton の泥臭いまとめには入っていませんが、そのうちまとめにも繋げたいと思います。

界隈って何

自分のバトン記事でも いわゆるブロガー系 (?) に廻っているよう と書きましたが、自分で書いていて「何この曖昧な定義」と思いました。 もう少し詳しく書くと、 weblog ツールないし weblog サービスを使用してサイトを運営している人を中心に廻っている印象があったのでこう表したのですが……。

まとめをしている時に、 誰々に廻そうと思うけど、 blog じゃないから気が引けるなあ といった表現が散見されました。 blog じゃないと廻してはいけないっていうルールってありましたっけ ? そもそもこの場合の blog の定義って何 ?

昨日の風はどんなのだっけ? - 「Musical Baton」を拒否する人たちに、

ただBlogだけでなく、普通にタグ打ちでやってるサイトとかにもバトンが回っているのは日本らしいのかな?

という表現がありますが、私みたいに Movable Type を使いつつ本文はタグ打ち ( この表現も微妙だなあ ) な人はどっちに入るんだろう。 Movable Type を使っているからと言って、自分のことを blogger だなんて絶対に表現したくありませんが。 ( 私は blog および blogger という単語を激しく嫌います。 )

結局は、界隈だからとか blog だからといったどうでもいい部分で判断するんじゃなく、自分がその回答を見てみたい、この人に廻してみたいという基準が大事だと思うのです。

ちょっと本筋とは関係ない話

今回のまとめに際して、個別記事のページの title 要素にサイト名を含んでいない所や、サイト名の短縮表記を使っている所がいくつか見られました。 私は Movable Type の機能を利用して、コメントやトラックバックがなされた場合は携帯電話のメールアドレスに通知を行うようにしているのですが……。 サイト名が title 要素に含まれていない、またはサイト名の短縮表記しか無い所からのトラックバックの通知で困りました。

自宅でパソコンに向かっている時はそうでもありませんが、出先などで携帯電話しか無い時に、どこのサイトからのトラックバックなのかさっぱり分かりません。 また、まとめツリーの中でもそういった所はどうしても印象が薄くなります。 引き合いに出して申し訳ないのですが、 [N] [た] [を] [晴] [結] っていう表記は全くもってインパクトがありません。 また、サイト名が無くて単に「 Musical Baton 」とだけ書かれていると、尚更記憶に残り辛いです。

もちろん、 title 要素にサイト名を入れなければならないという決まりはありません。 ( 文脈を踏まえたタイトルを提供する必要があるということなので、記事タイトルだけでも問題はありません。 ) ただ、今回のように記事タイトルが他のサイトと重複しがちな場合は、やはりサイト名が併記されていた方が分かりやすいと思います。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

ページ内の特定の範囲へのリンクをするための tips

記事データ

投稿者

望月真琴

投稿日時

2005-06-17T01:16+09:00

タグ
概要

a 要素や name 属性にこだわらず、任意のブロックレベル要素に対して id 属性を指定すれば、サイトコンテンツの特定の範囲を指定する指標になるのではないでしょうか。

リプライ

2 件のリプライがあります。

記事本文

Musical Baton の泥臭いまとめ作業のペースを落とす

hxxk.jp - Musical Baton の泥臭いまとめはそろそろ広がりすぎたので、自分から振った人とか、ふだんやり取りをしている人の周りとかを中心にペースダウンして続けるように変更します。 またいつものように web 語りとか Movable Type 話とかに戻りますよ。

a 要素はインラインレベル要素

これはほんとにそのままアンカーであり、それでくくった場所にしるしを付けるタグです。 例えば、 <a name="aaa">ああああ</a> とHTML内でくくっておけば、

これを使って「http:www.example.org/index.html#aaa」とすると、index.html内のaaaの指定した位置にジャンプできます。

これを使って固定リンクを実現する方法もよく使われ、よく1つの日記に複数記事が掲載されたWeb日記サイト&ツールでは、このアンカーリンクを活用してPermalinkを実現しています。

で、これに足りないなあ〜と最近とみに思うのが、これ文章内の始めの位置を指定するだけなんすね。 ですから、これを使って場所指定でリンクすると、その部分にフォーカスされるわけですが、「範囲」は指定できない。

もし終端を指定することができたなら、ここから〜ここという指定がリンクでできるのにーと思った。

もしくはリンクタグのほうを拡張して、<a href="index.html#aaa-#bbb">リンク</a>とできたらいいのになあと思った。

a 要素や name 属性にこだわらなければ良いんじゃないでしょうか ? a 要素はインラインレベル要素である以上、通常書かれるであろう形態の文章全体をマークアップすることはできません。 よって、 a 要素の name 属性をアンカーの終点としてマークアップする場合は、文章内の任意のインライン部分がアンカーの終点となります。

また、 XHTML 1.0: The Extensible HyperText Markup Language (Second Edition) - 4.10. The elements with 'id' and 'name' attributes には、

Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will be removed in a subsequent version of XHTML.

と、廃止予定であることが明言されています。 XHTML のほとんどの要素において、汎用属性として id 属性が使えるため、それを任意のブロックレベル要素に適宜割り振れば良いのではないでしょうか。

ブロックレベル要素に id 属性を割り当てる

<h2>中見出し</h2>
  <div class="section" id="id001">
    <h3>小見出し 001</h3>
      <p>
      文書 001
      </p>
  </div>
  <div class="section" id="id002">
    <h3>小見出し 002</h3>
      <p>
      文書 002
      </p>
  </div>

これは実際に hxxk.jp で用いている形式を簡単に表したものですが、このように見出し毎ではなくセクション毎に id を割り振ることで、各セクションに識別子を割り当てています。

<h2>中見出し</h2>
  <h3 id="id001">小見出し 001</h3>
    <p>
    文書 001
    </p>
  <h3 id="id002">小見出し 002</h3>
    <p>
    文書 002
    </p>

このように、 見出しに id 属性を割り振るケースも考えられますが、これは「リンク = ジャンプ」という誤解が根幹にあると思います。 例えば、上記の 2 つの例のような HTML に対し、 <a href="http:www.example.org/hoge.html#id001">id001</a> というリンクが向けられたとします。 現行の主なブラウザでは、どちらの例においても http:www.example.org/hoge.html の全体をレンダリングした後、 id001 部分が画面上に現れるように自動的に調節して表示します。

しかし、もし「フラグメント参照がなされたリンクをレンダリングする場合は、その参照がなされた部分 ( この場合、 id001 が割り振られた部分 ) しかレンダリングしない」というブラウザが登場すれば、前者の例では小見出し 001 および文書 001 の部分をレンダリングできますが、後者は小見出し 001 しかレンダリングせず、文書 001 の部分はレンダリングしてくれないでしょう。

「そんなブラウザなんて無いよ」と言われるかもしれませんが、フラグメント参照 - Personnel のような例も考えられていますので、そのうち登場する可能性は充分に考えられます。

よって、任意のブロックレベル要素に対して id 属性を指定すれば、 サイトコンテンツの位置等を指定する指標 となり得るのではないかと思います。

トラックバック送信先

アンカータグに先頭しかないのは欠陥説 : highbiscus -北国tv

a 要素や name 属性にこだわらず、任意のブロックレベル要素に対して id 属性を指定すれば、サイトコンテンツの特定の範囲を指定する指標になるのではないでしょうか。

リプライ

2 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-06-18T10:25+09:00 - highbiscus

なるほど。別に普通にidとか使って範囲指定すりゃいいすよね。 ただ、「http:www.example.org/index.html#aaa」みたいな形で URLとして範囲指定できるといいなと思うわけなんです。 そのへんはまだこのあたりの機能の必要性の周知が広まって ブラウザとかが対応しなきゃいけないのでまだ遠そうですが そうなれば「範囲へのURL指定」というのができていろいろ活用法考えれていいなと思いました。 あと現状のnameみたいな先頭へのフォーカスと、ブロックレベル要素を使った範囲へのフォーカスは 別個に使い分けれたほうが便利な気がするので(あとは範囲末端へフォーカスもあってもいいか)、 そのへんも使い分けれるかたちで実装が進めばベストっすね。

2005-06-23T22:23+09:00 - 真琴

私の示した「ブロックレベルに id を割り当てて、特定の範囲全体を示す」という手法だと、その範囲の始点や終点を限定して示すことはできませんね。ちょっとスマートな方法を思いつきませんが、一定の範囲と、その始点・終点を効率的に示すマークアップができるようになると良いですね。たとえば、この範囲だけを読み飛ばしたい場合に「この範囲の終点」もしくは「次の範囲の始点」へのアンカーがあると便利かも。 ( 読み上げ系ブラウザはもちろん、視覚系ブラウザにおいてもそれが枷となることは恐らく無いでしょう。 )

Musical Baton の泥臭いまとめ

記事データ

投稿者

望月真琴

投稿日時

2005-06-14T22:10+09:00

タグ
概要

ガッツで手作業で作成。やる気の続く限り随時書き換えていきます。逆に言うと、やる気が無くなった時点で辿るのを止めます。

リプライ

64 件のリプライがあります。

記事本文

Musical Baton を辿ってみる

私に廻ってきた Musical Baton がどこから来たのか、どこへ派生しているのか、どこへ派生していくのか、その系譜を辿ってみたくなったのでできる範囲でやってみようと思います。 あとまとめ側の役得として、普段の巡回ではなかなか見る機会の無かったサイトに触れて、自分用ブックマークを増やすとか。

……と上記の書き出し部分まで書いて辿り作業に入っていったのですが、よく考えたら 1 人から 5 人にバトンを廻すということは、廻っている回数が n 回だとすると、 5n 人がそれに参加していることになるのですよね。 1 人から 5 人、 5 人から 25 人、 25 人から 125 人……。

ええと、とりあえず Boy Comes To Town: The Musical Baton を起点にして頑張れるところまでということで。 ここを起点とする理由は、ここから日本の weblog に廻り出したようだからということで。 ( もしかしたらもっと早い段階で廻っていたかもしれませんが、私に廻ってきた流れを遡っただけなのでそこまではカバーしません。 )

Musical Baton Tree

例の如く (?) ガッツで手作業で作成。 作成時に廻していなかったところも、私が気付いた時点で書き換えます。 また、やる気が無くなった時点で辿るのを止めるつもりです。

よく考えたら、 MySQL を使って Movable Type を運用している場合、記事本文部分にあたる entry_text フィールドは、 text 型なので 65535 バイトという上限がありますね。 外部ファイルに記述して entry_text フィールドからはそれを import するだけにすればその制約は無くなりますが……。 いちおう 65535 バイトを一つの目安にしようかな。

あと、分かっていたことですがツリーが膨れあがりすぎたので、子に枝を持った部分には折り畳みボタンを付けました。 ( JavaScript が有効になっていないと、ボタンをクリックしても畳むことはできません。 ) 実はこの手の折り畳みボタンは好きじゃないのですけど、この場合は妥協。

そろそろ無理が出始めたので手を引こうかなと思っています。 あとは自分から振った人とか、よくやり取りをしている人の周りだけ細々と続けていこうかな。 なお、停止段階で階層が深かったり浅かったりするのは、単に思いつきで掘り下げていっていたからです。 私の気まぐれで掲載されなかった方は申し訳ありません。

Wiki を立てて他の人にも任せるという手もありますが、そうなると自分じゃ読まなくなるので、ブックマーク増やしという目的が達成されなくなるので Wiki などへの移行はしません。 なお、どなたかが Wiki を立てられた場合は、このツリーの情報を加工・転載されていただいて構いません。

*n の印が付いているものは 2 つ以上の所から廻されたところです。 ツリーを書く際に無限ループになってしまうので 1 つにまとめています。

トラックバック送信先

まとめサイトの情報を欲しがっている所にだけ送っています。

2xUP:Musical Baton(ミュージカル・バトン)

世界中は無理ですが、自分の手が届く範囲でマップ化してみました。

Milano::Monolog: Musical Baton

楽しいかどうかは自分では分かりませんが、自分中心にまとめてみました。

seraphita.blog:夢 だけ 見て 痛い なら。それ 以上 こちら→に 踏み 込んで は いけ ない

http://kotonoha.main.jp/2005/06/14musical-baton.html#m_p2 が「Musical Batonといえばここっ」って感じでしょうか。 あと拙記事が無機質な系譜図を描いていたり。

bricklife.weblog.*: Musical Baton

トラックバックセンターでツリー構造できたら楽ですね。 一応手動でツリーを作ってみました。

リプライ

64 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-06-15T08:48+09:00 - Musical Baton ミュージカル・バトン!(歴史+回答つき) < 絵文録ことのは

どこまで追い切れるかな? というかこの流れとラインナップ見てるだけで楽しいなあ。

2005-06-15T11:33+09:00 - Musical Baton < greenplastic.net

 detlog.orgのNaoさんからMusical Batonなるものがまわってきました。  Musical Batonとは『いくつか音楽に関する質問あるんで...

2005-06-16T00:07+09:00 - Musical Batonを追え < える日和

前のエントリーで書いたMusical Baton。 私から遡って数人目で日本に回...

2005-06-16T00:30+09:00 - Musical Baton < bricklife.*

一番はじめに言葉を見たとき「音が鳴るバトンタイプのおもちゃかな? パチカみたいなもん? 楽しそ〜♪」と0.5秒くらい妄想してしまった「Musical Baton...

2005-06-16T02:43+09:00 - Musical Baton < QuadraFaceLounge

いや、おれの所に回ってきたってわけじゃないんですけど。 ここ数日、巡回先の日記やblogで突然目にするようになった、Musical Baton。「音楽について...

2005-06-16T07:15+09:00 - y-Aki

Graphviz http://www.graphviz.org/ とかで図にしてみるといいかも。

2005-06-16T09:52+09:00 - Musical Baton(ミュージカル・バトン)

いつか世界中のMusical Batonを集めたサイトとかできないかしら。Baton Mapみたいなの!とか思っていたら真琴さんが鬼のようにまとめてはった。鬼ツ...

2005-06-16T18:37+09:00 - Musical Baton < the meager

先週あたりからフィード上にMusical Batonという単語が頻繁に登場するようになったのですが、

2005-06-16T19:30+09:00 - Re: Musical Baton の泥臭いまとめ < rewind2remind

私に廻ってきた Musical Baton がどこから来たのか、どこへ派生しているのか、どこへ派生していくのか、その系譜を辿ってみたくなったのでできる範囲でやっ...

2005-06-16T21:35+09:00 - 真琴

http://la.ma.la/blog/diary_200506161713.htm にて、「ミュージカルバトンに答えたエントリのURLを入れていくだけで自動でgraphvizみたいにリンク関係を視覚化して、ついでにちゃっかりアソシエイト IDを書き換えてボロ儲けするウェブサービスを作ってみましたとか書きたいのはやまやまなのだけれども、まだ出来てません。」という流れが生まれそうです、と外野からプレッシャー。

2005-06-16T22:20+09:00 - Musical Baton あれこれ < [晴]晴れの日もある

昨日の記事を書いたあとで、yomoyomoさんからもバトンを渡されたことに気付く。・Musical Baton(YAMDAS現更新履歴、2005/06/16)。yomoyomoさんに声をかけていただくなんて光栄の至りだが、既に書いたばかりなので、このバトンは謹んで辞退したい。このMusical Baton、初...

2005-06-17T00:06+09:00 - [WEB]Musical Baton変遷記(真面目版) < スローストロー

で、真面目に書くとこの企画がどこから流れてきたのか、というのが気になります。というわけでひたすら大元を辿ってみるテスト。 検証1:はてなキーワードから辿ってみる...

2005-06-17T02:55+09:00 - ミュージカルバトン(Musical Baton)を受け取りました、繋げます。

アオさんから回ってきたバトン、うちのサイトらしく試聴リンク満載で回答いたします。

2005-06-17T02:55+09:00 - ミュージカルバトン(Musical Baton)を受け取りました、繋げます。

アオさんから回ってきたバトン、うちのサイトらしく試聴リンク満載で回答いたします。

2005-06-17T02:57+09:00 - ミュージカルバトン(Musical Baton)を受け取りました、繋げます。 < wonderful music life!

irie!my music lifeさんよりバトン受け取りました。 (アオさんどうもありがとう!) で、その記事見たら大体どういうものかは分かったけど、一応...

2005-06-17T07:09+09:00 - [WWW]バトンの受け渡し < bewaad institute@kasumigaseki

上記のMusical Baton、最近になって巡回先で頻繁に出てきてます。リンクをたどって巡回先を増やすというwebmasterのビヘイビアからすれば容易に予想...

2005-06-17T07:11+09:00 - [WWW]バトンの受け渡し < bewaad institute@kasumigaseki

上記のMusical Baton、最近になって巡回先で頻繁に出てきてます。リンクをたどって巡回先を増やすというwebmasterのビヘイビアからすれば容易に予想...

2005-06-17T15:10+09:00 - [音楽][コンピューター]Musical Baton Tree < 日々の雑感 (tach雑記帳はてな版)

うわ、ミュージカルバトンの受け渡しの流れの中に自分のサイトが…! ↓何だかちょっと感動的… Musical Baton の泥臭いまとめ

2005-06-17T18:40+09:00 - みゅじかるばとんの元祖はMuziekstokkieなのだろうか。 < こわいものしらずのこわいものみたさ

なんとか2004年12月17日まではさかのぼれた。あとは知らん(*^_^*)ドイツ語読めないし。 さてこのoohさんから回ってきたミュージックバトンなるもの。音...

2005-06-17T18:45+09:00 - Musical Baton を逆流してみた < 今日の覚え書き

おととい受け取ったMusical Batonですが、細菌が増殖するかのごとく、すごい勢いでいろんなサイトさんが参加されているようですねぇ。 ...

2005-06-17T19:16+09:00 - [音楽][コンピューター]Musical Baton Tree < 日々の雑感 (tach雑記帳はてな版)

うわ、ミュージカルバトンの受け渡しの流れの中に自分のブログが載ってる…! ↓何だかちょっと感動的… Musical Baton の泥臭いまとめ

2005-06-17T20:02+09:00 - Musical Baton その後 < 自知之明

エキブロのメンテ長かったな〓(^_^;)絵文録ことのはさんから託されたMusical Batonですが、「中華ポップス系ニ回セ」という言外の指示を読みとった(....

2005-06-17T22:04+09:00 - Musical Baton < 音極道茶室

ネット界隈を震撼?させている『Musical Baton』。だいたいのルールはこ...

2005-06-17T22:11+09:00 - Musical Baton < 音極道茶室

ネット界隈を震撼?させている『Musical Baton』。だいたいのルールはこ...

2005-06-17T22:26+09:00 - キタコレ、MUSIC BATON < SPHERICALMUSIC

先週までの更新お留守の巻き返しを図るが如く、今日一日で3つくらいエントリ書きそうな勢いの私まこーです。 さて早速。不幸の手紙よろしくネット上のブログという...

2005-06-17T22:29+09:00 - Musical Baton(日文) < 五彩華

 jingさんのブログ「自知之明」から、「Musical Baton」なるお誘いを頂きました。  内容としては別に無理難題な訳ではないのです。「音楽に関す...

2005-06-18T01:34+09:00 - Musical Baton < 観測気球

なるぱらの人から、Music Baton が回ってきました。さくさく答えて、次に回します。

2005-06-18T04:08+09:00 - Musical Baton(ミュージカルバトン) < LaLaLa

ANOTHER-PLACE.JPさんより、Musical Batonのタスキを頂きました、ありがとう★(直ぐに気付かずスイマセン、なんせ就職活動中でございます。...

2005-06-18T12:08+09:00 - バトンの系譜 < (遊) あそびや(asobiya)??★

「Musical Baton:パンパでガウチョ」経由で、「hxxk.jp - Musical Baton の泥臭いまとめ」。 m(_ _;)m すごいです。これ...

2005-06-18T14:34+09:00 - [web][music]樹形図

Musical baton 受け渡しの樹形図、手作業で作ると異様に大変そうだ。自動的に樹形図を生成するプログラム、誰か書かないかな。兄弟姉妹、甥姪ラインを辿って...

2005-06-18T17:27+09:00 - MusicalBaton(音楽に関する質問) < 他人の不幸は蜜の味

・えっけんさんからお鉢が回ってきましたので、やってみます。 ■質問1:今、パソコンに入っている音楽ファイルの容量 ・6GBもありました。ファイル数で1000...

2005-06-18T22:01+09:00 - Musical Baton矇� < blog@Junkie Surfer Notes

腱��矗��矍��Musical Baton矍��矍c�矍��矍��矇�

2005-06-19T12:31+09:00 - The Musical Baton < 人生迷い箸

「なかよしこよし」のこだるまさんから Musical Baton を受け取りまし...

2005-06-19T14:52+09:00 - Musical Baton < 杉の木工房

I've been passed the baton by AmanoMuts...

2005-06-19T14:54+09:00 - Musical Baton < 杉の木工房

I've been passed the baton by AmanoMuts...

2005-06-19T15:39+09:00 - 2005-06-18 < ややろぐ

ミュージックバトン? unfakeさんより。 以下はてなキーワードより。 ☆MusicBatton概要 海外のブログに端を発する、音楽に関する企画。 音楽...

2005-06-19T21:01+09:00 - [た] Musical Baton(ミュージカル・バトン)がまわってきました。 < [た] takeratta(tm)::Blog+

takerattaのところにもこないかしらぁって思って待ち遠しくしておりましたと...

2005-06-19T21:49+09:00 - Musical Baton(ミュージカル・バトン) < ばーたろの日日愚労

海の向こう側からやって来た、各人の音楽の趣味を披露するリレー。bricklifeのoobaさん、それからミクシィ経由でにゃーさんから廻って来ました。いざ書くとな...

2005-06-20T00:36+09:00 - つぶやきLettus

* hxxk.jp - Musical Baton の泥臭いまとめ 昨日うちでもやったMusic buttonですが、こうしてまとめられてる方も居るんで...

2005-06-20T01:20+09:00 - [た] Musical Baton(ミュージカル・バトン)がまわってきました。 < [た] takeratta(tm)::Blog+

takerattaのところにもこないかしらぁって思って待ち遠しくしておりましたと...

2005-06-20T02:45+09:00 - Musical Baton < La vita quotidiana

えー、某SNSのマイミク、ゆみ姐さん&水うさぎさんから Musical Baton回ってきました。同時に(笑 つか、結構な人がすでに巻き込まれてたのは知...

2005-06-20T05:26+09:00 - ミュージカルバトンは音楽著作権管理団体の陰謀? < 二匹狼の遠吠え

ミュージカルバトン(Musical Baton)は実は音楽著作権管理団体による壮...

2005-06-20T08:53+09:00 - Musical Baton < メモログ

Musical Batonとは音楽に関する4つの質問に応えて次の5人にBatonを渡す、という最近流行っている風習です。

2005-06-20T16:29+09:00 - [細胞具][影踏み] Musical Baton < 花魁発狂

 【id:junction】さんから、Musical Batonなるwebねずみ講、或いはエントロピーの法則を踏襲しているのか一本が五本になる不思議なバトンが渡...

2005-06-20T22:45+09:00 - http://bless.babyblue.jp/wp/?p=152 < Taste of Wind

 最近あちこちのBlogで見かける「Musical Baton」という記事。まさにミームの如く、凄まじいまでの勢いで増殖中ですね。 系譜を作ってみたり、↑の...

2005-06-21T00:42+09:00 - Musical Baton と6次の隔たりと文化の壁 < だるくぶろぐ

hxxk.jp - Musical Baton の泥臭いまとめ私に Musical Baton を回してくれたくでんさんのサイトがツリーにありますね。数えてみる...

2005-06-21T00:44+09:00 - Musical Baton と6次の隔たりと文化の壁 < だるくぶろぐ

hxxk.jp - Musical Baton の泥臭いまとめ私に Musical Baton を回してくれたくでんさんのサイトがツリーにありますね。数えてみる...

2005-06-22T00:55+09:00 - [Misc]Musical Baton の泥臭いまとめ < 超兄記。(w

http://hxxk.jp/2005/06/14/2210 上記にて、このチェーン一覧がツリーで閲覧(!)できるようになっているようです。 どうやら、発端は海...

2005-06-22T03:18+09:00 - 公募 < Satty's Diary

これ書いたら寝ます   ミッチーさんトコから、こんなのが回ってきた 「Musical Baton」 あぁ、そう〜 流行ってるのかな? ...

2005-06-22T03:20+09:00 - 公募 < Satty's Diary

これ書いたら寝ます   ミッチーさんトコから、こんなのが回ってきた 「Musical Baton」 あぁ、そう〜 流行ってるのかな? ...

2005-06-22T16:36+09:00 - Musical Batonはどこからやってきたのか < 遊葉見覚帳

 Musical Baton の泥臭いまとめ(hxxk.jp) Musical Baton ミュージカル・バトン!(歴史+回答つき)(絵文録ことのは) むらさき...

2005-06-22T16:39+09:00 - Musical Batonはどこからやってきたのか < 遊葉見覚帳

 Musical Baton の泥臭いまとめ(hxxk.jp) Musical Baton ミュージカル・バトン!(歴史+回答つき)(絵文録ことのは) むらさき...

2005-06-22T23:51+09:00 - Musical Batonとカルト < とりあえず月配列とかのブログ

1つ前の記事で、Musical Batonを辿ってみた話を書いたんだけど、その後、気になって、ちゃんと途中の分岐も調べてみたw。ご先祖様の中で、2人からバトンを...

2005-06-23T00:45+09:00 - [はてな]バトン騒動総括(早くも) < 深夜の馬鹿話

ようやく収束しましたよ、バトン関連が。 もうしばらくは回ってこなくても良いかなー? 自分の趣味嗜好を人に説明するのって難しいね。 やっぱり適当にダラダラと思い...

2005-06-23T02:17+09:00 - バトンについて < log for logs

最近ブログ界では様々なバトンなるものが回っているらしい。このバトンについて直接知ったのは6/18のビデオゲームバトンは馬鹿だ。@真性引き篭もりだが、正確にはここ...

2005-06-23T04:17+09:00 - Musical Baton < もえもえちゃんねる

巷で噂のMusical Batonをルパニズムの泥棒の三世さんからいただきました。わーい!

2005-06-24T03:55+09:00 - みゅーじかるばとん < 440hz

さてさてヒノリさんのところから振られてきたみゅーじかるばとんですが、流行りまくりみたいですね。 中には同時に2人から振られてしまっている人もいたりして。 アンテ...

2005-06-25T00:54+09:00 - Musical Baton < kobblog@livedoor

せっかくまわってきたので答えてみましょう。 コンピュータに入ってる音楽ファイルの容量 23.05GB …ってこんな質問iTunesユーザーでないと答えら...

2005-06-26T20:23+09:00 - 音楽駅伝は箱根の山を越えるか?(Musical Baton) < 欧風

なんか最近あちこちのBLOGでMusical baton(ミュージカル・バトン、あるいはミュージック・バトン)なるものが廻ってますね??。なんか良く意味が分から...

2005-06-29T04:29+09:00 - 本日の処方箋:ミュージカルバトン < 本日休診

まわったり、まわしたり、まわされたり。 流行っているようです。 どうせなら、まわったり、まわしたり、まわされたり。 しておこうではないですか。くふ。

2005-07-05T03:45+09:00 - 我、指揮者也 < ブログさきがけ

時代の波に乗り遅れているらすぃ・・・。ミュージカルバトンて何だ(・_・o)ン? (o・_・)ン? (o・_・o)ン 調べてみました。まぁ取り敢えず、蓮ちの望み通...

2005-07-06T11:00+09:00 - 今、Blogerの間で流行っている!?もの < 未来ネット Information Center

昨日、なんとデジハリの杉山校長からコメントが届きました。いつもしつこいくらいTBしているから多少ご覧になっていただいていたのかな^^。 デジハリは私が考えてい...

2005-07-07T16:15+09:00 - Musical Baton - ネット探索 - < BloG Mame

昨夜、ネット探索・バトン巡りをすると書いたけど、マジでしてます。キリイごっこは楽しい(笑) でも疲れた(・∀・)  さてさてこのバトンさんたち。 派生として「...

2005-07-11T00:38+09:00 - Musical Baton(ミュージカルバトン)とやらに遅ればせながら答えてみるみる < Sky's The Limit

ホント、激しく出遅れなんですが。 Musical Baton(ミュージカルバトン)というのが以下のおふたりから回ってきました。ありがとうございます。 実は、ずい...

Chain weblog

記事データ

投稿者

望月真琴

投稿日時

2005-06-14T21:16+09:00

タグ
概要

Musical Baton という Chain weblog ともいうべき企画を振られたので、回答してまた別の人に廻します。

リプライ

7 件のリプライがあります。

記事本文

Musical Baton が廻ってきました

hxxk.jp 内で音楽の話ってそう頻繁にはしていなかった気もしますが。 iPod mini の話をよくしているので音楽を全く聴かないわけじゃないと思われていたのでしょうか。 いやまあ単に weblog 内で音楽の話をしないだけで、自宅では常に何かしらの音楽を聴いているわけですが。

最初に 2xUP:Musical Baton(ミュージカル・バトン)でこの企画を見かけていたので、突然話を振られてビックリというわけではありませんでした。 要するに音楽にまつわるお題について話を振られ、それに答えたのちに更に 5 人に振るという chain weblog とでも言うようなものです。

The answer of Musical Batton

アルバムへのリンクは Amazon.co.jp の商品紹介を利用していますが、アフィリエイトめんどくさい派なのでアフィリエイトリンクは付いていません。 ( あれ、この場合ってアソシエイトって言うんですっけ ? ) 2005 年 9 月 18 日に方針を変更し、アソシエイト ID を取得しましたので、アソシエイトリンクをつけてみました。

Total volume of music files on my computer is ( 今パソコンに入ってる音楽ファイルの容量 )

異なるドライブに分散させているので正確な値は計算していませんが、 18.56GB くらいですね。 ほとんどが mp3 形式で、 KWS [Kimama-ni-WebStop] mini 4GB活用法:ワタシの場合を参考にしてこのうちの 4GB 弱を iPod mini に入れて持ち歩いています。

Song playing right now ( 今聴いている曲 )

本題とは関係ないんですけど、この曲の 6:43 あたりで 6 連スネア→ 6 連シンバルのフレーズがあるんですけど、このシンバルの名前なんて言いましたっけ ? 6" くらいのスプラッシュを重ねたようなシンバルで、何かしらの呼び名があったと思うのですが……。 ちなみに HOME ( Metropolis Part 2: Scenes from a Memory ) の 6:27 にも同じような音のシンバル連打があります。 どなたかご存知でしたら教えてください。

The last CD I bought was ( 最後に買った CD )

本当は Octavarium を買いに行ったのですが、伝説 (?) の名曲「デス市長」の文字を見かけて思わず綿いっぱいの愛を ! も合わせて購入。 ( デス市長とは何ぞやという方は東方千年帝国協会 - 伍月壱拾参日を参照。 )

Five songs(tunes) I listen to a lot, or that mean a lot to me ( よく聞く、または特別な思い入れのある 5 曲 )
Metropolis, Pt. 1: The Miracle and the Sleeper ( Images & Words / DREAM THEATER )

DREAM THEATER は Awake を最初に聴いたのですが、その時はまだしっくりきませんでした。 その後 Images & Words を聴き、 Metropolis に衝撃を受けてどっぷりと嵌っていったのです。

One ( S & M / METALLICA )

オリジナルバージョンに加え、多くのライブバージョンが発表されていますが、思い入れがあるといえばこの DVD に収録されているバージョンです。 これを 5.1ch モードにして、 James Hetfield が "No, No, No, No, No!!" と叫ぶところを聴くのが大好き。 また、 2 of One の映画のシーンを背景に、効果音と共に流れるバージョンも同じくらい思い入れがあります。

Like @ Angel ( DRUG TREATMENT / 黒夢 )

これはファンだったわけではありませんが、当時仲間内でやっていたコピーバンドで最も多くプレイした曲という思い入れ。 たぶんこの曲は今演奏しろって言われてもちゃんとできる自信があります。 ( まあ、シンプルな曲ではあるのですが。 )

Junk Story ( hide SINGLES ~ Junk Story / hide )

没後に発売された未発表曲ということで賛否両論ありましたが、 KING OF PSYBORG ROCK STAR の DVD に収録されている PV を見ると何度でも涙が出てきます。 思い入れという点では最も強い曲かもしれません。

Cry for the moon ( 冷たい太陽 / ROUAGE )

これはどちらかというとバンド自体に思い入れがあるパターン。 最も多くコピーしたバンドは黒夢だったのですが、最初にコピーしたバンドはこの ROUAGE でした。 この曲も毎回と言っていいほどプレイしていましたし、最後のときは対バンのメンバーにボーカルを任せてみたりと、非常に楽しい思い出が残る曲です。

また、初の武道館となったプロトカルチャーの映像もすごく印象に残っています。 NK AUG.26.2000 で演奏されなかったのが残念ですが……。

……とまあ、こんなところでしょうか。 5 曲だとまだまだ語り足りない気もしますが、今回挙げなかった曲についてはまあおいおい。

Five people to whom I'm passing the baton

私自身チェーンメールの類は嫌いですが、こうした実害の無い面白い試みは別です。 ということでルールに則り 5 人に廻そうと思います。 私以前の流れをみると、いわゆるブロガー系 (?) に廻っているようだったのですが、そこは外して「私が回答を見てみたい」という方に廻します。 勿論無視されても構いません。

あと、この誘いに乗って記事を書いていただいたら是非トラックバックをお願いします。 ( こういう時こそトラックバックという仕組みの利点を生かすべき ! )

トラックバック送信先

Ogawa::Memoranda: Musical Baton

(o) さんから渡されたバトンを次に渡したので報告トラックバック。 こうすることで (o) さんの手間をかけずに該当エントリへのリンクを作成、これこそがトラックバックの有効的活用法ではないでしょうか ! ( 大げさ )

リプライ

7 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-06-15T10:08+09:00 - Musical Baton

Musical Baton 祭。

2005-06-15T10:16+09:00 - Musical Baton が廻ってきた < Lucky bag::blog

まさか自分とこに来るとは思っていなかった Musical Baton ですが、ありがたくも真琴さんからご指名頂いたんで、とりあえず書いてみます。

2005-06-16T00:34+09:00 - ってことで Musical Baton < Namamono ? Diary

hxxk.jp の真琴さんから Musical Baton が回ってきました ( 2005-06-14 : Chain weblog ) 。まさかこっちへ回って...

2005-06-16T00:35+09:00 - ooba

ツリーまとめお疲れさまでした! あげられている曲を見てみましたが、一時期の僕と非常に趣向が似ていて共感を覚えました(^^ こういう発見があるのも、この企画の面白いところですね。

2005-06-16T21:25+09:00 - 真琴

ありがとうございます ! まあ、趣向が似た人を探してこっそり自分の bloglines に登録するのが真の目的なのです。まとめはその副産物。自己中 !

2005-06-19T16:54+09:00 - Re: Musical Baton < Junkline

Re: Musical Baton from しまけんさん & 真琴さん 1. Total volume of music files on my co...

2005-06-20T04:27+09:00 - Musical Baton < ねこめしにっき

Musical baton なるものが真琴たんからまわされてきたので、答えてみる

Feed に全文を入れるとか入れないとかより、結局はより多くの人に行き渡る形態の選択と、記事自体の質の向上が大事だと思う

記事データ

投稿者

望月真琴

投稿日時

2005-06-14T00:35+09:00

タグ
概要

あれこれ議論するより、概要も記事全文も提供してしまえば良いのです。そして結局は記事自体の質が勝負だと思うのですが。

リプライ

リプライはまだありません。

記事本文

はてなダイアリーに限って言えば全文掲載を推奨

というわけで、みなさんRSSフィードにたくさん文章を入れましょう。 たとえば、はてなダイアリーを使っている方は、 自分の日記が「RSSフィードに全文を掲載する」オプションになっているか再チェック!(はてなダイアリーは全文をRSSに入れるかどうかを選べる)

「Webの世界は、公開したもん勝ち」というのが基本ですね。

はてなダイアリーなんて「全文を掲載しない」か「全文を掲載する」のどちらかしか選べないのだから、全文を入れることが手放しで賛成されているわけではないことに目を瞑って、結城浩さん ( [結] ) の主観 ( リンク先を読めば分かりますが、 というわけで の根拠になっている部分は、結城浩さんの印象によって語られています。 ) で「全文を掲載すること」を推奨されてしまうと概要派の自分は困る ( これだって私の主観ですが ) なあ……と最初は思いました。

しかし、よくよく調べてみると、はてなダイアリーにおいて「 RSS フィードに全文を掲載する」設定にしている場合、 RSS 内に description 要素と content:encoded 要素の両方が記述されます。 要するに概要も記事全文も両方配信するという形式です。 例えば Bloglines の場合ですと、そういった Feed を取り扱う場合に

  1. Feed を選択
  2. 「登録項目を編集する」をクリック
  3. 「更新された項目」のプルダウンメニューから「要約があればそれを表示」を選択
  4. 「変更」をクリック

とう手順で概要派の私も安心。 全文派の方は、「記事全体を表示」を選択すれば安心。 ( もちろん、最初から概要のみしか配信していない Feed だと「記事全体を表示」の設定は無効になりますが。 )

ということではてなダイアリーに限って言えば、全文を入れるようにしてもらった方がユーザの選択肢は増えるので良いということになります。 ( 全ての RSS リーダが Bloglines のように表示設定ができるかは分かりませんが。 )

なお、はてなダイアリー市民に質問します。ダイアリーの設定での『RSSフィードの設定』をどのようにしていますか?この設定の存在をすでに知っていた方は項目1~4のいずれかに答えてください。知らなかった方は、項目5~8のいずれかに答えてください。という興味深い質問が行われています。 昨日私が行った質問では Feed 講読者に概要か全文かのこだわりは少ないという結果が出ましたが、 Feed 配信者にもこだわりが少ないという結果が浮き彫りになったようです。

Movable Type に限って言えば ATOM を推奨

同じような論点で述べるなら、 Movable Type の場合は ATOM 0.3 形式を推奨します。 現時点での最新バージョンである Movable Type 3.17 では、デフォルトで RSS 1.0 と RSS 2.0 と ATOM 0.3 を出力するようになっていますが、それらのデフォルトのテンプレートで概要と記事全文の両方を出力するのは ATOM 0.3 しかありません。 各 Feed における概要と記事全文の出力状況は次の通りです。

RSS 1.0

<description><$MTEntryBody encode_xml="1"$></description> というように、 description 要素内に記事全文が配置……って、何で全文 ? Lucky bag::blog: MT3.15のRSS の私のコメントでも触れていますが、 Movable Type 3.1x 以前は MTEntryExcerpt だったものが改悪されているようです。

RSS 2.0

<description><$MTEntryBody encode_xml="1"$></description> というように、 description 要素内に記事全文が配置されています。 RSS 2.0 なのでまあ記事全文が記述されることは問題ないかもしれませんが、 description 要素内に配置されるべき内容かどうかは疑問符。

ATOM 0.3

<summary type="text/plain"><$MTEntryExcerpt remove_html="1" encode_xml="1"$></summary> というように、 summary 要素内に概要が配置され、

<content type="text/html" mode="escaped" xml:lang="<$MTBlogLanguage ietf="1"$>" xml:base="<$MTBlogURL encode_xml="1"$>">
<$MTEntryBody encode_xml="1"$>
<$MTEntryMore encode_xml="1"$>
</content>

というように、 content 要素内に記事全文および追記部分が配置されています。

まあ、 RSS 1.0 や RSS 2.0 でも、テンプレートをちょっとカスタマイズして description 要素内に MTEntryExcerpt を配置、 content:encoded 要素内に MTEntryBody を配置するようにすればユーザに選択肢を与えることができますが……。

まあ RSS 1.0 と RSS 2.0 と ATOM 0.3 を配信している時点で選択肢となっているという見方でも良いかもしれません。 RSS 1.0 の description 要素に記事全文を突っ込んでいるのはどうかと思いますが。

まあ、はてなダイアリーとか Movable Type とかに限らず

Feed では概要だけを提供すべきだとかいやいや全文を提供すべきだとかの議論は、 Feed を講読する側からはどうでも良い話かもしれません。 もしより多くの人に読んでもらいたいのならば、同一 Feed 内に概要と記事全文の両方を記述して配信する、または概要のみの Feed と記事全文の Feed の複数を配信するといった形態を取り、好きな方を取得してもらえばよいのです。 そうすれば両方のニーズに応えられて読者の取りこぼしもありません。

結局はどういった形態で配信するかよりも、いかに読者を掴む文章を書くか、あるいはいかに読者を引き込むような的確な概要を書くかということに尽きるのかもしれません。 Feed の配信形態をあれこれ工夫して講読者を獲得しても、肝心の内容が薄っぺらであれば意味がありませんし。 なお、 Feed における概要の重要性については、概要 ( excerpt ) は有効活用されていない ? で触れていますので、合わせてお読みいただくと幸いです。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

試すだけなら 350ml*2 でもいいじゃないかとか言うなよ ?

記事データ

投稿者

望月真琴

投稿日時

2005-06-13T22:58+09:00

タグ
概要

家飲みのときは平均 1 リットル !

リプライ

2 件のリプライがあります。

記事本文

打ち上げが無くなったわけで

金色と黒色のヱビス 決して心が折れたわけではなく !

事前に自転車を全力で 60 分ばかり漕いでビール分のカロリーは消費済みですし ! ( そういう問題ではない )

ブラックトップ

ブラックトップ ヱビス ( 黒 ) からヱビスの順番。

……ちとヱビス ( 黒 ) が多かったかも。

ホワイトトップ

ブラックトップ ヱビスからヱビス ( 黒 ) の順番。

今度は泡が小さくなってしまった。

そういえば

ヱビスに限った話ではないけど、黒ビール党って世間一般ではどういう割合なんでしょうねえ ? 黒ビールが好き、黒ビールもやぶさかではない、むしろ黒くなきゃビールじゃねえって人はコメント欄で挙手を !

リプライ

2 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-06-17T12:23+09:00 - asiamoth

自分は黒ビール党です。 ヱビスは自分の中では特別なビールで、「今日はがんばったなー」というときに、自分のご褒美に買ったりします。黒ヱビスは置いてあるところが少なくて、余計に特別なビールに感じます。 ──困るのが、「今日はがんばったなー」な日に寄ったコンビニなり酒店なりに、「(白)ヱビスと他社の黒ビール」があったときにどちらを選ぶか。うーむ。 ──まぁ、味覚オンチな自分はどちらでも満足しますが。

2005-06-23T22:20+09:00 - 真琴

おお、黒ビール党かつヱビス党の仲間が ! 私は歩いて 1 分のコンビニに黒ヱビスが置かれているので、 asiamoth さんより幸せなのかもしれません。 ……そのぶん、毎日買いたくなるのを自制する必要もでてくるのですが。 ちなみに、黒しか飲まないわけではないので、白ヱビスと他社の黒ビールという選択になった時は白ヱビスを取りますね、私は。

Feed を提供することと、その内容についての考察

記事データ

投稿者

望月真琴

投稿日時

2005-06-12T21:27+09:00

タグ
概要

Feed を提供すると本サイトのアクセスが減るのか ? はたまた増えるのか ? また、その提供する内容は概要だけが良いのか ? 全文が良いのか ? ( はてなアンケート結果付き ! )

リプライ

リプライはまだありません。

記事本文

抜粋 vs 記事全文に対する私の個人的意見

広告やアフィリエイトの類を全く使っていないのと、個人的には Feed だけで完結して本サイトのアクセスが減るというのはどうでも良いという考えを持っているので、議論のレイヤーが違ってしまうかもしれないことを最初に断っておきます。

ニュースフィードや商用ブログのRSSフィードはどうだろうか。 RSSフィードで配信する大きな狙いは,Webサイトへの集客効果を高めることである。 記事全文をRSSフィードで送るなんて,とんでもないことなのだ。 RSSリーダーで記事全文を読まれてしまい,そこで完結されては困ってしまう。 Webサイトのページビューが減るだけに終わってしまう。 要約にとどめたRSSフィードを配信するだけでも,ページビューが減るのではと心配しているメディアサイトも存在するくらいだから。

さて、ニュースサイトでもなく商用 weblog でもない私の weblog ですが、 「文章を読んでもらえればそれで良い」 という考えなので、全文配信の Feed ( RSS 2.0ATOM 0.3 ) をどーんと配信しています。 ただ、全文配信は逆に読みづらいというユーザもいるだろうということで、概要のみの Feed ( RSS 1.0 ) も配信しています。 本サイトのページビューが増えて欲しいのは正直なところですが、それと Feed の配信は別にして考えています。 また、個人的な意見ですが、 Bloglines を情報チェックに愛用しているため、 ( 概要、全文の区別は関係なく ) Feed を配信していないサイトはチェック対象から外します。 統計を取ってみたわけではありませんが、 「 RSS リーダでチェックできないサイトは巡回対象から外す」という私と同じ考えのユーザはそう少なくないと思います。

短絡的な感情で「不便」にするのは逆効果になる場合が多い。

RSSに記事文が入っていないと、そもそも本サイトどころかRSSですらそのサイトを読みに行かなくなってしまうのでは無いだろうか。

「わざと普通の人とは逆の発想でメリット・デメリットを考える」というのがアイデア勝負のイロハのイだから、あえて揚げ足をとってみたり詭弁をついてみたりすることにして「RSSに記事全文が入っていないとサイトへのアクセスが減る」と断言してみようと思う。

これは「 Feed の提供を行わないこと」に対するカウンターなのだと思いますが、概要のみの Feed に対しても言っているのだと思います。 果たして、概要のみの Feed を読まされるユーザは不便を感じるのでしょうか ?

私の場合は概要のみの Feed と全文配信の Feed の両方が提供されていれば、概要のみの Feed を積極的に講読しています。 タイトルと概要のみの方が素早く情報をチェックできますし、本サイトに行けば全文は用意されているのですから、 Feed に全文を入れられると逆に効率が削がれると感じてしまうのです。 もちろん、 「 Feed を提供する側は概要のみの Feed を配信するか全文の Feed を配信するか、どちらか一方しか選べない」 というわけではありませんから、両方用意してユーザに選ばせるというのが現時点での解だと思うのです。

まあ、 void GraphicWizardsLair( void ); // RSSフィードに全文を入れるのは、ブラウザをタダで配ったり無料会員でも使えるようにするようなもんだと思う。だからお客を呼びたいのならRSSに記事を入れてしまえの記事は、 「俺は全文配信の Feed しか支持しない ! 」 という意見ではなくて 「 Feed での全文配信によって広告収入が減ることを気にしているサイト」 に対するアンチテーゼのように読めるので、私の主張も想定内なのかもしれませんが。

アンケートをとってみた

300 ポイントを上限にしていたら、 90 分ほどで回答が集まってしまいました。 はてなユーザのうち、先着 300 人を対象としたアンケートであるため、この結果を以って一般ユーザの考えだとするには調査母体が小さすぎるでしょう。

ただ、この結果のみに限定して言えば、 「概要のみか全文かは気にしない」 というユーザが大半だったいうことです。 それ以外だと、個人的には半々くらいかなあと予想していたのですが、概要のみ派が多かったですね。

トラックバック送信先

メディア・パブ: RSSフィード論争,“抜粋 vs 記事全文”

個人的な意見ですが、 ( 概要、全文の区別は関係なく ) Feed を配信していないサイトはチェック対象から外します。統計を取ってみたわけではありませんが、「 RSS リーダでチェックできないサイトは巡回対象から外す」という私と同じ考えのユーザはそう少なくないと思います。

void GraphicWizardsLair( void ); // RSSフィードに全文を入れるのは、ブラウザをタダで配ったり無料会員でも使えるようにするようなもんだと思う。だからお客を呼びたいのならRSSに記事を入れてしまえ

Feed に記事全文を入れられることを望まないユーザもいます。 概要のみと記事本文の両方の Feed を提供して、ユーザに選ばせるともっと集客効果があるのではないでしょうか。

weblog の流行に伴い、 RSS や ATOM などの Feed を配信しているサイトが増えました。それに概要だけを掲載する場合もあれば、本文全部が掲載されることもあります。どちらが良いという議論はさておいて、貴方が RSS リーダで読む場合はどちらが「好き」ですか ?

このアンケート結果を考察に使わせていただきました。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

デフォルトの個別エントリーアーカイブから URI を変更する場合の注意点

記事データ

投稿者

望月真琴

投稿日時

2005-06-12T15:09+09:00

タグ
概要

Movable Type 3.1x では entry_basename を元に個別エントリーアーカイブの URI を決定しますが、これがなかなか曲者なのです。

リプライ

3 件のリプライがあります。

記事本文

Movable Type 3.1x の個別記事の URI の命名規則

Movable Type 3.x ……としてこの記事を書いても良いのですが、一口にバージョン 3.x と言っても、 3.01D-ja と 3.11 以降では今回触れる件については少々事情が異なるため、バージョン 3.1x についての話とさせていただきます。

Movable Type 3.1x において、個別エントリーアーカイブの出力ファイル名は

  1. 管理画面
  2. ウェブログの設定
  3. アーカイブの設定
  4. アーカイブ・ファイルのテンプレート

の順番で設定画面をたどり、そこでテンプレートタグを用いて命名規則を決定します。

アーカイブ・ファイルのテンプレートの欄はデフォルトでは空白となっています デフォルトでは空白になっており、またそれによって作成された weblog を一見しただけではどのような規則に基づいているのか推測しづらくなっています。 例えば、 Movable Type Publishing Platform はこの状態で構築されており、 2005 年 6 月の記事の URI を羅列すると次のようになっています。

  1. Movable Type 3.17日本語版を6月9日に提供開始 ( http://www.movabletype.jp/archives/2005/06/movable_type_31_7.html )
  2. Movable Type 3.17の提供を開始 ( http://www.movabletype.jp/archives/2005/06/movable_type_31_8.html )
  3. Movable Type技術情報を更新しました ( http://www.movabletype.jp/archives/2005/06/post_10.html )

一見すると「記事のタイトルから日本語を省いた上で、空白は _ に変換して最初の 15 文字を取り出して、それでも重複していたら _1 や _2 のように接尾語を付けて重複を回避して」命名されているようにも見えますが、 Movable Type技術情報を更新しましたの http://www.movabletype.jp/archives/2005/06/post_10.html のように、そうとも限らない URI になっているものもあります。

実際はデータベース上の entry_basename フィールドを用いて URI が決定されるのですが、それ自体はどのような規則に基づいて決定されているのでしょうか。

entry_basename フィールドの命名規則

Ogawa::Memoranda: Movable Type 3.0のIndividual Entry Archiveの命名方式の問題点に詳しく書かれているので、そちらを読んでいただくと幸いです。 この記事の内容を参考にしたり、自分で試してみたことを簡単にまとめると、

  • 下書きとか公開といった状態に関わらず、最初に記事を保存した時点で決定される
    • 記事のタイトルが入力されていればそれから決定
    • 記事のタイトルが入力されていなけれ本文から決定
  • 一度決定された entry_basename は、以後タイトルや本文を修正しても変更されない
    • phpMyAdmin を使って直接 entry_basename の値を修正しても、再度記事を保存すると元の entry_basename が使われる
  • 日本語は dirify されるため、日本語のみのタイトルや、タイトル未設定時の本文の先頭が日本語のみであった場合は、 post_1, post_2... のように命名される

ということのようです。 おそらく、 Movable Type技術情報を更新しましたの http://www.movabletype.jp/archives/2005/06/post_10.html という URI は、最初は日本語のみのタイトルで下書きをしたといった状況が推測されます。

entry_basename は使わない方が良い

entry_basename による命名規則だと、 http://www.movabletype.jp/archives/2005/06/movable_type_31_7.html のように、 URI 自体に記事の内容が反映されるため、分かりやすくて良いと考えられるかもしれません。 しかし、 entry_basename を一度設定したら容易に変更できない ( Ogawa::Memoranda: mt-resave-entries.cgi: basenameがNULLのエントリを再保存するCGI で変更はできる ) のでは、メリットよりもデメリットの方が大きいと言えます。

また、記事のタイトルを途中で変更していた場合に、記事のエクスポートやインポートを行うと、 entry_basename が変わってしまう可能性も充分に考えられます。 Movable Type 2.x から引き継いで使用している場合は、 entry_id を基に個別記事の URI が命名されていますが、 Junkline - ダサい URI はコロコロ変わるなどのように、これもエクスポート / インポートで変わってしまいます。

お勧めは記事の作成日時で命名すること

私が実際に行っている命名規則ですが、記事の作成日時を基に URI を命名すれば、作成日時を変更しない限りはエクスポート / インポートを行っても URI は変わりません。

hxxk.jp では、個別エントリーアーカイブのアーカイブ・ファイルのテンプレートは <$MTArchiveDate format="%Y/%m/%d/%H%M"$>.php という指定にしていますが、そこまで細かくディレクトリを分けなくて良い ( 年別や日別のディレクトリはいらない ) というのであれば、 <$MTArchiveDate format="%Y%m/%d%H%M"$>.html といった形に適宜変更すると良いでしょう。

Re: エントリーの URL 変更のお知らせ - Focus Pocus.blog

さて、ここからが本題。 エントリーの URL 変更のお知らせ - Focus Pocus.blog を拝見して、

ディレクトリとファイルの名前を同時に変更したので、Google 等のサーチエンジンからの来客が大幅に減。 .htaccess 使えよって話なんですがエントリーの量がそこそこ多いのでOTL

という記述があったので、インデックステンプレートでどうにかならないかなあと思ったので、 entry_basename 周りを調べてみたのです。

で、色々と調査してみた結果、私の環境では .htaccess を自動生成することができました。 次項に手順を示します。

entry_basename による URI からのリダイレクトを行う .htaccess の記述

URI などの環境は Focus Pocus.blog に合わせていますので、参考にされる場合は適宜ご自分の環境に読み替えてください。

  1. 「新しいインデックス・テンプレートを作る」をクリック「新しいインデックス・テンプレートを作る」をクリックします。
  2. 「新しいインデックス・テンプレートを作る」をクリックテンプレートの名前を適当な名前にし、出力ファイル名を .htaccess にします。テンプレートの中身に次のようなコードを記述します。
    <MTEntries lastn="1000">Redirect permanent <$MTBlogRelativeURL$>archives/<$MTEntryDate format="%Y/%m/"$><$MTEntryBasename$>.html <$MTBlogArchiveURL$><$MTEntryDate format="%Y/%m/%d%H%M"$>.html
    </MTEntries>
  3. テンプレートを保存し、「このテンプレートを再構築する」をクリックテンプレートを保存し、「このテンプレートを再構築する」をクリックします。

要するに、一度アーカイブ・ファイルのテンプレートの記述を空白にすることで entry_basename による命名に一時的に戻し、それを利用して .htaccess を自動で作成するという手法です。 ( 一部ローカルでの作業が必要になりますが。 ) entry_basename フィールドの値をテンプレートタグで扱えるともう少し楽にできそうなのですが……プラグインの練習で作ってみようかなあ。

<$MTEntryBasename$> というテンプレートタグを用いて、デフォルトで生成される URI を新しい URI にリダイレクトさせるという手法です。

トラックバック送信先

エントリーの URL 変更のお知らせ - Focus Pocus.blog

一度アーカイブ・ファイルのテンプレートの記述を空白にすることで entry_basename による命名に一時的に戻し、それを利用して .htaccess を自動で作成するという手法はいかがでしょう。

リプライ

3 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-06-12T20:15+09:00 - Linear

はじめまして。 .htaccess をテンプレートから作るっていうのは盲点でした。確かにこれならいくらエントリーがあっても一発でリダイレクトできるようになりますね。 早速そのようにやってみると上手くいきました。感謝です。

2005-06-13T01:10+09:00 - 真琴

解決したようで何よりです。 ……が、どうも <$MTEntryBasename$> を使えそうな感触です。 ( 今さら ) ちょっとこの辺を試してみて追記しますー。

2005-06-13T01:30+09:00 - 真琴

やはり <$MTEntryBasename$> というテンプレートタグが存在しました。もっと早く気付いていれば Linear さんに余計な手間をかけさせずに済んだのですが……面倒な方法を紹介して申し訳ありません。

順序を楽しむ

記事データ

投稿者

望月真琴

投稿日時

2005-06-12T12:10+09:00

タグ
概要

「グラスに注ぐ順序で泡の色が変わる」とのことなので、是非とも両方試さねば……。

リプライ

リプライはまだありません。

記事本文

clippingグループ - ::memo:: type-R - エビス&エビス経由でメモ。 普段自宅びーりんぐする時はギネスのエクストラスタウトキリンラガービールのハーフ & ハーフで飲んでいるのですが、たまにヱビスの黒だけ、超長期熟成だけという飲み方もします。

しかし、ヱビス同士でのハーフ & ハーフはやってみたことがなかったのです。 グラスに注ぐ順序で泡の色が変わる とのことなので、是非とも両方試さねば……。 ああしかし昨日は家族・親戚と飲みに出かけたし今週は仕事の打ち上げもあるので自宅飲みは控えないと。 ( 毎日飲めばいいジャマイカとか言うなよ ! 言うなよ ! 休肝日 ! )

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

コメント欄常連不要論

記事データ

投稿者

望月真琴

投稿日時

2005-06-11T11:20+09:00

タグ
概要

コメント欄において「常連には冷たく当たる」という言い方をすると何だかマイナスの印象がありますが、裏を返してコメント欄以外の場で常連とのやりとりをするという工夫をすれば良いのかもしれません。 ( 最初から常連なんていらないというのであれば、冷たく当たるという工夫でも良いかもしれませんが。 )

リプライ

リプライはまだありません。

記事本文

冷たくするというかコメント欄以外で交流するというか

ブログのコメント欄というのは、縁の薄い人が、気軽にコメントしてくれて、それが実は興味深い情報だったりするというのが理想的なんだけど、そういう方向に水を差すのが常連の存在。 そういう意味では、常連を作らない工夫として「常連には冷たく当たる」というのがいいのかもしれない。

私の場合は日常雑記的なことをほとんど書かないという weblog 自体の性質に起因しているのかもしれませんが、常連と呼べるほど頻繁にコメントをされる方はいません。 まあ、日常的なことの報告や何度もやりとりを繰り返すようなことをする人とは、コメント欄ではなくて IRC でやりとりをしているというのが要因かもしれませんが。

コメント欄において 常連には冷たく当たる という言い方をすると何だかマイナスの印象がありますが、裏を返してコメント欄以外の場で常連とのやりとりをするという工夫をすれば良いのかもしれません。 ( 最初から常連なんていらないというのであれば、冷たく当たるという工夫でも良いかもしれませんが。 )

例えば IRC などのチャット。 例えば特定の記事に付随するコメント欄ではなくて全体に関わるゲストブック。 例えば SNS などの内輪向けなテンションが許容されるコミュニティ。

当 hxxk.jp ではトップページにゲストブックを用意していますし、小規模ながら IRC チャンネル #hxxk も立てています。 我こそは常連と思われる方 (?) は是非。

ふっと思いついた

コメントの常連じゃなくてトラックバックの常連だったらまた違った意見になるのでしょうか。 もちろんスパムトラックバックや無意味なトラックバックの常連じゃなく、一定の関連を保ったトラックバックしてくれる常連さん。 どなたか「トラックバック常連論」を書きませんか。

トラックバック送信先

ARTIFACT@ハテナ系 - [個人サイト]ブログのコメント欄に常連はいらない

「冷たく当たる」というのは印象が良くないので、「コメント欄じゃないところに常連を誘導」という工夫はいかがでしょう。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

RSS リーダと 301 Moved Permanently

記事データ

投稿者

望月真琴

投稿日時

2005-06-10T23:06+09:00

タグ
概要

自動での変更がなされていなくてもリダイレクトによって最新の Feed を講読することができますので、いますぐ変更をしていただく必要はありません。以前の URI のままで登録することが気になる場合は新しい URI に変更してください。

リプライ

3 件のリプライがあります。

記事本文

リニューアルのお知らせのコメント欄でも少し触れていますが、これまで各コンテンツエリアの appendix ディレクトリ内に配置していた Feed 関連も、 http://hxxk.jp/appendix/ 内に一本化して配置しなおしています。

これまで Feed を講読していただいていた方にもご不便をおかけしないよう、旧 Feed へのリクエストは 301 Moved Permanently を返すようにしていますが、それによる登録の変更をツール側が自動で行ってくれるかユーザ自身が行わなければならないかは、ツールによって異なるようです。

RSS の移転: blog.bulknews.net によると、 Bloglines は 301 Moved Permanently を返された場合は自動で Feed の登録情報を変更してくれるようです。 私も Bloglines を使っていたので実際に確認してみたところ、確かにリダイレクトされた後の URI に自動で変更されています。 ( bulkfeeds も同様に自動で変更されるようです。 )

しかし、 void GraphicWizardsLair( void ); // 古いRSSへのアクセスに301を返しているのだけど、自動的に移転処理をしてくれないRSSリーダーが結構あるによると、自動で変更しないものも数多くあるようです。 羅列されているもので全てではありませんが、少なくとも羅列されているものを使用している場合は、自動での変更はなされていないと捉えて良いでしょう。

私の都合で Feed の URI を変更しているのですし、自動での変更がなされていなくてもリダイレクトによって最新の Feed を講読することができますので、いますぐ変更をしていただく必要はありません。 以前の URI のままで登録することが気になる場合は新しい URI に変更してください。 現在提供している Feed は以下の 3 つです。

RSS 1.0
RSS 2.0
ATOM 0.3

リプライ

3 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-06-11T12:22+09:00 - 哀

/appendix/rss.rdf という URI を一見すると「hxxk.jp の付録扱いの『RSS』(RDF 形式)」を得ることが期待されますが、実体を見つめた際に真琴さんが本当に提供したいのは「hxxk.jp に投稿される記事の『要約または最新記事の情報』」であると思われます。RSS だとか RDF だとか Atom だとかはあくまでファイルの形式に過ぎず、クールな URI の観点において省かれるべき情報です。 .../index ( .rss10 | .rss20 | .atom )、または .../summary ( .rss10 | .rss20 | .atom )、または .../recent ( .rss10 | .rss20 | .atom ) などをお勧めしますが、どうでしょう。私は "appendix/" にも少々きな臭さを感じます。 クールな URI ムツカシイ。

2005-06-12T12:28+09:00 - 真琴

うむむ、確かにそうですねえ。今は atom.xml という「 Feed の名称に沿った」名前になっていますが、 ATOM 自体の名称に変更があった場合に変更を余儀なくされてしまいます。 また、 appendix/ は feed だけではなく、色々と内部で処理するためのファイルを置いているという事情もあります。 ( それに対する appendix というディレクトリ名がふさわしいかというと、多分違います。 ) やはり一番最初に明確なビジョンを持たないといけませんね ( 自戒 )

2007-07-07T14:49+09:00 - RSSリーダー < 大金を稼ぐにはスキルアップから by ebook house

RSSリーダーというものがある。 これはブログに標準装備? いや、オプションで装備するものもあるので・・・ 標準装備だとかオプションといえば、モ...

SHINE

記事データ

投稿者

望月真琴

投稿日時

2005-06-08T23:53+09:00

タグ
概要

エアロバイクを漕ぎながらサッカー観戦をしていたら、試合終了までの 120 分間漕ぎっぱなしといううっかりっぷり。

リプライ

リプライはまだありません。

記事本文

ふだんはテレビを見ませんし、スポーツ自体にも関心が低い方なのですが、ちょうど試合開催時間にジムに居たのでエアロバイクを漕ぎながら日本対北朝鮮戦を見ていました。 ……と言っても、いつものように耳には iPod mini のイヤフォンを装着して、音楽を聴きながらの観戦だったので、画面でしか追っていないわけですが。

というか、サッカーをまるまる 1 試合観戦すること自体が生まれて初めてなのですが、あんな行為をしても許されるの ? というのが感想でした。 ユニフォームを引っ張る、手で相手の体を押す、体当たりをする、挙句はボールを取るために揉みあった際に足が当たったからといって、スパイクを履いた足で倒れた相手を踏みつけようとしてレッドカード……。 ふだん観戦しないため、サッカー自体がこういう競技なのか、北朝鮮チームだけがこういった行為が目立つのかは私には分かりませんが。 サッカーに詳しい方にコメント等をいただきたいのですが、その辺どうなんでしょう ?

試合自体の感想としては、日本が 2 点目を入れるまさにその瞬間は B'z の SHINE という曲を聴いていて、ゴールとほぼ同じタイミングで 2:43 付近のビリー・シーンのベースソロの部分に差し掛かり、「オーレ ! オーレ ! 」というバックヴォーカルが流れたので、何だかゴールの感動が倍増しました。

エアロバイクの運動は試合終了と同時に終えたのですが、試合開始数分前からエアロバイクを漕ぎ出していたので、気付けば 120 分間ずっと漕ぎっぱなしで、走行距離が 64km なんて数字に……。 日本が勝って嬉しかったのは確かなんですけど、熱中していたとはいえオーバーワーク気味になってしまった自分に反省。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

text/html と XHTML 1.1

記事データ

投稿者

望月真琴

投稿日時

2005-06-04T01:39+09:00

タグ
概要

ミツエーリンクスの Web標準Blog にて XHTML 1.1 では text/html は使えないと書かれていますが、一概に使えないというわけではありません。 ( 現在はこの表現は修正されています。 )

リプライ

リプライはまだありません。

記事本文

ちょっと待った

W3Cの定める文書型から選定を行う段階では、まずHTMLかXHTMLか?という点を決めなければなりません。 次に、仕様のバージョン。 最近の傾向としては、HTMLの場合は4.01、XHTMLの場合は1.0が主流です。

より古いバージョンのHTMLを使用することもできますが、4.01はHTMLの最新にして最終のバージョンであり、前方互換性の確保という観点では4.01が良いでしょう。 また1.0よりも新しいバージョン(現状では1.1)のXHTMLを使用することもできますが、その場合メディアタイプにtext/htmlを採用できない点に注意する必要があります。 つまり、現状ではHTML 4.01とXHTML1.0のいずれかを選択するのが現実的です(詳しくはXHTMLのバージョンとメディアタイプを参照)。

メディアタイプにtext/htmlを採用できない点に注意する必要があります って書いてありますが、採用できないわけではありません。 で、引用元から辿れる XHTMLのバージョンとメディアタイプを読んでみると……。

XHTMLは1.0と1.1というバージョンが勧告済みですが、1.1ではメディアタイプに従来HTMLで使用してきたtext/htmlを使用することができません。 application/xhtml+xml、application/xml、text/xmlのいずれかを使用することになります。

ところが、ブラウザシェアのトップを誇るWindows版Internet Explorer(以下WinIE)は、これらのメディアタイプに対応していません。 一方、XHTML 1.0では、推奨こそされてはいないものの、text/htmlを指定することが可能です。 詳細は、W3C NoteのXHTML Media Typesをご覧ください。

XHTML Media Types を参考に例示しておいて何故 1.1ではメディアタイプに従来HTMLで使用してきたtext/htmlを使用することができません という結論になるのでしょうか……。

Should not? Must not? ( 再掲 )

Another HTML-lint と text/html と XHTML 1.1 - Should not? Must not? で触れましたが、改めてここに書きます。 XHTMLのバージョンとメディアタイプにて、 XHTML 1.1 に text/html を使用できない根拠として XHTML Media Types を提示していますが、そこには次のように書かれています。

The 'text/html' media type [RFC2854] is primarily for HTML, not for XHTML. In general, this media type is NOT suitable for XHTML.

text/html [RFC2854] は元来 HTML のためのメディア型であり、XHTML のためのメディア型ではない。 一般に、このメディア型を XHTML に対して使用するのは適切でない

適切ではないと否定されているので使用できないという解釈に至ったのかもしれませんが、 既存の HTML UA でのレンダリングを目的とする場合 であれば text/html を使用することも可能ではあります。

XHTML Media Types - 3.5. Summary の表を見れば分かりますが、 MUST NOT とされているのは HTML 4 に対して application/xhtml+xmlapplication/xmltext/xml を使用することだけです。

どのような表現であれば良かったのか

文書型宣言 | Web標準Blog | ミツエーリンクスでの表現を、 「また 1.0 よりも新しいバージョン ( 現状では 1.1 ) の XHTML を使用することもできますが、 XML として処理されることを期待する場合は、メディアタイプに text/html を採用できない点に注意する必要があります。」 のようにすれば、メディアタイプに text/html を採用できないとしても良かったのではないかと思います。

トラックバック送信先

文書型宣言 | Web標準Blog | ミツエーリンクス

XML として処理されることを期待する場合は、という断りを付けた上で「 XHTML 1.1 メディアタイプに text/html を採用できない」とするなら正しいのですが、一概に採用できないというのは違うと思います。

修正していただきました

また1.0よりも新しいバージョン(現状では1.1)のXHTMLを使用することもできますが、その場合メディアタイプにtext/htmlを採用すべきではない点に注意する必要があります。 XHTMLデータをXMLデータとしてではなくHTMLデータとして扱うことが一般的な現状においては、HTML 4.01とXHTML 1.0のいずれかを選択するのが現実的です

XHTMLデータをXMLデータとしてではなくHTMLデータとして扱うことが一般的な現状においては というのは、私の提案した「 XML として処理されることを期待する」よりも上手い言い回しだと思います。 指摘を受け止めて素早い対応をしていただき、どうもありがとうございました。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

リニューアルで古くなった URI を新しい URI にリダイレクト

記事データ

投稿者

望月真琴

投稿日時

2005-06-03T23:29+09:00

タグ
概要

昨日お伝えした URI 変更の件に伴い、旧 URI から新 URI にリダイレクトするようにしました。できる限り「リニューアルによる 404 Not Found 」の発生が無くなるように .htaccess を設定しましたが、もしかしたら漏れがあるかもしれません。その場合は遠慮なくご指摘をお願いします。

リプライ

1 件のリプライがあります。

記事本文

301 Moved Permanently

昨日お伝えした URI 変更の件に伴い、旧 URI から新 URI にリダイレクトするようにしました。

今回のケースはリソース自体の移動に伴うものなので、 301 Moved Permanently という HTTP ステータスをブラウザに渡す必要があります。

ディレクトリを丸ごとリダイレクトする場合

例えば、 http://hxxk.jp/mt/ 以下のリソースを、ディレクトリ構造を維持したまま http://hxxk.jp/ にリダイレクトしたい場合、 .htaccess の記述は次のようになります。

Redirect permanent /mt/ http://hxxk.jp/

こう記述していれば、 http://hxxk.jp/mt/ 以下の各記事は次のようにリダイレクトされます。

  • http://hxxk.jp/mt/2005/05/30/0149 → http://hxxk.jp/2005/05/30/0149
  • http://hxxk.jp/mt/2005/05/30/ → http://hxxk.jp/2005/05/30/
  • http://hxxk.jp/mt/2005/05/ → http://hxxk.jp/2005/05/
  • http://hxxk.jp/mt/2005/ → http://hxxk.jp/2005/
  • http://hxxk.jp/mt/ → http://hxxk.jp/

ディレクトリ構造が全く変わらない場合、例えばドメインを新たに取得してそちらに移行するような場合はこの 1 行の記述だけで充分でしょう。

一部のリソースにおいて規則性によらない URI 変更が行われる場合

これは、今回の私のようなケースです。 カテゴリを撤廃してキーワードによる分類を行っていますが、それによって行われる URI の変更に規則性はありません。 例えば、 http://hxxk.jp/mt/information/ というカテゴリアーカイブがあったのですが、これに当たる新しいリソースは http://hxxk.jp/keyword/%A4%AA%C3%CE%A4%E9%A4%BB という URI になります。

これを前項の記述でリダイレクトしてしまうと、 http://hxxk.jp/mt/information/ が http://hxxk.jp/information/ にリダイレクトされ、そして既にカテゴリアーカイブは撤廃されているため 404 Not Found となってしまいます。 そこで、基本的には規則性による URI の移動だけれど一部その規則性から外れるようなケースでは、次のように .htaccess を記述する必要があります。

Redirect permanent /mt/information/ http://hxxk.jp/keyword/%A4%AA%C3%CE%A4%E9%A4%BB
Redirect permanent /mt/ http://hxxk.jp/

規則的なリダイレクトより先に、こうした個別のリダイレクトの記述を配置することで、規則的な URI な変更の適用を免れることができます。 ( 順番を逆にしてしまうと、規則性に従って http://hxxk.jp/information/ にリダイレクトされ、 404 Not Found になります。 )

実際のリダイレクト結果

これらを踏まえ、できる限り「リニューアルによる 404 Not Found 」の発生が無くなるように .htaccess を設定しました。 しかし、もしかしたら漏れがあるかもしれません。 その場合は遠慮なくご指摘をお願いします。 なお、次のようなリダイレクトを行っています。

個別記事および時系列アーカイブ

記事の作成日時を基に URI を割り当てていますので、基本的な部分は変わりません。 ドメインの直下にリダイレクトするようにしています。

カテゴリアーカイブ

元のカテゴリを基本に、それぞれのキーワード一覧にリダイレクトしています。 なお、適切なキーワードが無い漠然としたカテゴリは、キーワードページのトップにリダイレクトしています。

テンプレートのサンプル

Template hxxks -standard- のように、 Movable Type のテンプレート配布のサンプルページは、 http://hxxk.jp/mt/ 以下にあったため、こちらも htp://hxxk.jp/ 以下に配置されるようにリダイレクトしています。

リプライ

1 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2007-01-14T14:16+09:00 - サイト引越し・移転 (301 リダイレクトの方法) < web2.0的ラボ

私の運営しているレビューサイト「わかったブログ」のサイト名のつづりが間違えている...

リニューアルのお知らせ

記事データ

投稿者

望月真琴

投稿日時

2005-06-02T22:29+09:00

タグ
概要

ここ数日、水面下で作業を進めていましたが、作業の目処がついたので実際の weblog に反映させました。これまでのデザインや構造と大きく変わっていますので、各項目ごとに解説します。

リプライ

2 件のリプライがあります。

記事本文

大きく運営方針を変えました

ここ数日、水面下で作業を進めていましたが、作業の目処がついたので実際の weblog に反映させました。 これまでのデザインや構造と大きく変わっていますので、各項目ごとに解説します。

  1. URI が変わりました
  2. カテゴリを撤廃しました
  3. 2 カラムデザインにしてみました
  4. 記事の加筆修正をしています
  5. その他

URI が変わりました

これが閲覧者にとって最もクリティカルな変更かもしれません。 例えば、 Weblog hxxks だったら http://hxxk.jp/weblog/YYYY/mm/dd/HHMM だった個別記事の URI が、 http://hxxk.jp/YYYY/mm/dd/HHMM のように、 http://hxxk.jp/ 直下に配置されるように変更しました。

記事の内容には変化がありませんので、以前の URI に対するリクエストでも不便をおかけしないよう、 Redirect による対策を講じるつもりではありますが、見通しの甘さが私にあったことは否めません。

カテゴリを撤廃しました

AllKeywords Plugin とキーワードによるテンプレート - カテゴリによる分類を捨てたいでも述べていましたが、 Ogawa::Memoranda: 四畳半フォークソノミーの実現に向けての考えに賛同し、それに合わせた構成に変更しました。

各記事の URI が変わることは、記事自体の内容は等価であることに比べ、カテゴリによる分類とキーワードによる分類は内容が大きく異なります。 よって、旧カテゴリアーカイブの取り扱いについてはまだ決めかねています。

2 カラムデザインにしてみました

いかにも「ブログでござい」といった ( 偏見 ) 2 ( あるいは 3 ) カラムデザインには抵抗があったのですが、関連する記事やキーワードインデックスを配置するにはこちらの方が良いだろうと思い、 2 カラムデザインにしてみました。 なお、まだスタイルシートは調整中です。

関連記事やキーワード以外にも、最近のコメントや最近のトラックバックを並べるようにしていますので、コメントやトラックバックがあった記事以外からでも、その記事に辿り着きやすくなっています。

記事の加筆修正をしています

今回の形式に移す際に、キーワードによる分類を手作業でやり直す必要がありました。 ( カテゴリによる形式では、無理矢理勝カテゴライズしていたものもあったため。 ) そのため、分類をし直すのと同時に記事の内容の加筆修正も行っています。

なお、記事のエクスポート/インポートによる移行ではなくガッツで手作業で移行したため、 entry_id が全て変わっています。 ( まあ、これは閲覧者にはあまり関係ありませんが……。 ) 既に寄せられていたコメントおよびトラックバックは MySQL を直接いじって移行していますので、そちらの id には変更はありません。

その他

私の気付かないところで思わぬ影響が出てしまっているかもしれません。 もし気付かれた方がおられましたら、この記事のコメント欄などでお知らせください。

リプライ

2 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2005-06-03T21:38+09:00 - e-luck

おー、良い感じですねー:-) 個人的には、前のより好きなデザインかも。 ちなみに、Feed 関連は変更なしですよね? Bloglines の方では、更新通知されていなくて、たまたま覗いたら変わっててビックリしますた。 ここ最近、どうも Bloglines の挙動がおかしいんですよね。

2005-06-05T01:27+09:00 - 真琴

お褒めの言葉、ありがとうございますー。ちなみに、更新通知がされていなかったのは、単純に移行作業中は feed の自動リビルドをオフにしていて、それをオンにするのを忘れていたからという私のミスです:p なお、 hxxk.jp/appendix/ 以下の rss.rdf などはそのままですが、 hxxk.jp/mt/appendix/ 以下などの、「旧分類の feed 」は hxxk.jp/appendix/ 以下にリダイレクトするようにしています。

補足情報

著作、講演、制作実績など