- taizooo: http://d.hatena.ne.jp/taizooo/20080523/1211535403
- otsune: hAtomにrequiredなAuthorが無いな
- snj14: authorはhAtom0.2でoptionalになるらしいよ．個人的にはmicroformatsにrequireは不要だと思う．組み合わせれば良いんだし．
- forestk: 同意しつつも最低限を決めておかないと、活用しにくいかもとは思う。hAtom に rel="bookmark" ないとどうかなぁ、とか
- ↑from: [http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/taizooo/20080523/1211535403]
- :
- snj14: オレ，rel-bookmarkも嫌いなんだわー． [http://twitter.com/snj14/statuses/820148977]
- snj14: 例えば http://tinyurl.com/5kqdxo はtwitter検索内のパーマリンクなんだけど，twitterのパーマリンクは http://twitter.com/fuba/statuses/815883523 [http://twitter.com/snj14/statuses/820149407]
- snj14: 両方のリンクをHTML内に入れるとして，どっちがrel="bookmark"なの？「どっちをブックマークするか」ってユーザが決めることなんじゃないの？なんでサイト側が指定すんの？…同じ問題がふぁぼったーとかパーマリンクのあるSBMとかでもあるよねぇ． [http://twitter.com/snj14/statuses/820151794]
- snj14: SBMの例だと，これとか→ http://tinyurl.com/6z7a3c [http://twitter.com/snj14/statuses/820153088]
- snj14: ミスった．これね． http://tinyurl.com/6aruno はてなスターの状況を見たいときはこっちだけど， [http://twitter.com/snj14/statuses/820154602]
- snj14: 本文読みたいときってこっちじゃん． http://d.hatena.ne.jp/taizooo/20080523/1211535403 ユーザが選べるようにしたほうが良いはずだよね．rel-bookmarkっていう用途を限定したmicroformatsにしたからこうなる． [http://twitter.com/snj14/statuses/820155560]
- snj14: そうじゃなくて，rel="EntryExternalURI"とかrel="EntryInternalURI"とかみたいに純粋に構造だけを記述すれば(なんか長くてキモイけど)， [http://twitter.com/snj14/statuses/820157695]
- snj14: キカイが「ああ，なんか二つある．でもオレっちは本文読む用のプログラムだからexternalの方を開こうっとー」とか，出来るわけで． [http://twitter.com/snj14/statuses/820157952]
- snj14: と，そんなことを http://tinyurl.com/6qyqk9 のforestkさんのコメントを見て思った． [http://twitter.com/snj14/statuses/820159545]
- snj14: hAtomは(残念なことに)，「Atomに変換する用」になっちゃってるから，Atomに変換するんだったら「パーマリンクが要る」って思うのではないかと． [http://twitter.com/snj14/statuses/820160534]
- snj14: 用途と構造を別にすれば，Atomに変換するプログラムは「ブログのエントリ用のmicroformatsが使われていて，かつ，パーマリンクもあったらAtomに変換できるよ．でなきゃinvalidだからオレっちを使ってAtomに変換したいなら両方定義してね」って宣言しちゃえば良い． [http://twitter.com/snj14/statuses/820162477]
- snj14: パーマリンクはいらないけどブログの構造は欲しいっていう他のプログラムまで「パーマリンクのmicroformatsがなければinvalid！」とか無駄じゃん． [http://twitter.com/snj14/statuses/820163964]
- otsune: あるblog entryのURIとそれのブックマークコメントのpermalinkとか、favotterのURIと元ネタtwitterのURIが違うのは当たり前というか違うものなんだから別のURIじゃないと困るだろ。
- otsune: ちゅーか「今提供しているこのページはURIという一意のデータでいうと○○ですよ」というのをrel="bookmark"で示せってことで。「ソーシャルブックマークでそのURIを登録しなきゃダメ」なんて狭く斜め上に飛躍したデータを提示してるわけじゃない。"bookmark"という名前に惑わされ過ぎ。
- otsune: あと「blogとそのはてブ」とか「favotterと元ネタtwitter」なんてのはRFC 4685的な仕組みで提供できるように進化するのが筋の良い方法だと思う。（EntryExternalURIなんちゃらよりは健全）。
- otsune: とにかく「どっちをブックマークするか」なんてミクロ視点でrel="bookmark"の意味を読み違えるのはマズい。
- snj14: 「favotterのURIと元ネタtwitterのURIが違うのは当たり前というか違うものなんだから別のURIじゃないと困る」←もちろん．
- snj14: 「「今提供しているこのページはURIという一意のデータでいうと○○ですよ」というのをrel="bookmark"で示せってことで」←これが複数の意味で解釈できるから嫌い．favotterはrel="bookmark"をつける場合，元のtwitterのパーマリンク対してrel="bookmark"をつけるのか，favotter内のパーマリンクに対してrel="bookmark"をつけるのか？
- snj14: rfc 4685的な仕組み がよく分かってないんだけど，HTML内のmicroformatsでスレッドを表現するんだったら，やっぱり，twitterのパーマリンクとfavotterのパーマリンクを別のmicroformatsで表現する必要があるんじゃないの？
- otsune: 俺の感覚だと明らかに「favotter内のパーマリンクに対してrel="bookmark"をつける」がまっとうに見える。なぜならそのリソースはfavotterであってtwitterではないじゃん。
- otsune: だから「あるマッシュアップサイトの言及先とか元ネタを示す一意のURI」をrel="bookmark"に入れるのも混乱した間違いだし、rel="bookmark"をまったく無しにするってのもアホにしかみえない。
- otsune: ただ「用途外の利用法だけどfavotterのAtomで元ネタのURIを知りたいんだ。じゃないと個人的に不便」っていう欲望があることは尊重されるべきで。そういう人間の欲望を満たすために規格や仕様は進化するべきだとも思っている。
- otsune: そのときに「用途外の使い方が出来ないからrel="bookmark"は嫌いだ」ってのが、違う話を一緒くたにしている混乱だと思ったのだ。
- snj14: 「なぜならそのリソースはfavotterであってtwitterではないじゃん。」←じゃあ，googleみたいなページはどうなる？「googleなりのサマリ」というメタデータのついたgoogle内のpermalinkみたいなものは無いと思う．
- snj14: であれば，googleの検索結果の先のリンクにはrel-bookmarkを付けられないことになる．もし付けるなら，machine readableではないよね．サイトによってrel-bookmarkの意味が「内部のpermalink」か「外部のpermalink」かが変わるんだから．
- snj14: じゃあ，これらを明示するために，rel-bookmarkっていう規格(仕様?)を進化させる必要があるんじゃないか？と思って，EntryInternalURIとかEntryExternalURIとか書いたんだわ．
The Whole World is peaceful.
『オレ、rel-bookmarkも嫌いなんだわー』とブツクサ言うsnj14
“ stupid and rapidly.
“ stupid and rapidly.
“ stupid and rapidly.
culturite:(via images24.fotosik.pl)
gotham racing (via Jibbo)
just another dance (via habitante)
(via entrelinhas:)
“ 出会い頭、ソレに心を射貫かれていた。
“ 出会い頭、ソレに心を射貫かれていた。
“ 出会い頭、ソレに心を射貫かれていた。
“ 日本人で一番海外で稼いだ選手は間違いなく、カーンだろうな
“ 日本人で一番海外で稼いだ選手は間違いなく、カーンだろうな
“ 日本人で一番海外で稼いだ選手は間違いなく、カーンだろうな
“ 「おお、前田アキラか…」「ローデス？」
“ 「おお、前田アキラか…」「ローデス？」
“ 「おお、前田アキラか…」「ローデス？」
“
Microformatsはyoupyさんからアイデアをもらいました
“
Microformatsはyoupyさんからアイデアをもらいました
“
Microformatsはyoupyさんからアイデアをもらいました
“ hAtom is based on a subset of the Atom (http://www.atomenabled.org/) syndication format.
“ hAtom is based on a subset of the Atom (http://www.atomenabled.org/) syndication format.
“ hAtom is based on a subset of the Atom (http://www.atomenabled.org/) syndication format.
“ xFolk (from “xFolksomony”) is a simple and open format for publishing collections of bookmarks.
“ xFolk (from “xFolksomony”) is a simple and open format for publishing collections of bookmarks.
“ xFolk (from “xFolksomony”) is a simple and open format for publishing collections of bookmarks.
“ フォークソノミー(folksonomy)とは、インターネットのウェブサイト上の情報に、利用者自らが複数の「タグ」（tag,名札）を自由に付け加え、検索できるようにしていく分類の方法をいう。folks（民衆）とtaxonomy（分類法）を合わせた造語。
“ フォークソノミー(folksonomy)とは、インターネットのウェブサイト上の情報に、利用者自らが複数の「タグ」（tag,名札）を自由に付け加え、検索できるようにしていく分類の方法をいう。folks（民衆）とtaxonomy（分類法）を合わせた造語。
“ フォークソノミー(folksonomy)とは、インターネットのウェブサイト上の情報に、利用者自らが複数の「タグ」（tag,名札）を自由に付け加え、検索できるようにしていく分類の方法をいう。folks（民衆）とtaxonomy（分類法）を合わせた造語。
『microformats 使わなきゃ良いんじゃない？』
- snj14: パーマリンクはいらないけどブログの構造は欲しいっていう他のプログラムまで「パーマリンクのmicroformatsがなければinvalid！」とか無駄じゃん． [http://twitter.com/snj14/statuses/820163964]
- snj14: とりあえず今日の発言のまとめ http://snj.tumblr.com/post/36093545 [http://twitter.com/snj14/statuses/820171511]
- forestk: @snj14 遅レスですが、パーマリンクをユーザが決めるべきというのであれば「microformats 使わなきゃ良いんじゃない？」ということだと思いますよ [http://twitter.com/forestk/statuses/821344389]
- forestk: @snj14 もともと microformats ってそれを利用したサービスやアプリケーションのための物（？）なのでそこはユーザに見えなくても良いんじゃないかなと [http://twitter.com/forestk/statuses/821345223]
- forestk: @snj14 「パーマリンクはいらないけどブログの構造は欲しい」とか、まさに microformats がいらない例じゃないかなぁ、と思うんですが。全部が全部に組み込むのも違う気がしますし [http://twitter.com/forestk/statuses/821345856]
- forestk: なんでもかんでもに microformats を導入するのもどうかと思うけどね。それが必要なコンテンツかどうかが第一じゃないかなぁ [http://twitter.com/forestk/statuses/821353814]
『オレ、rel-bookmarkも嫌いなんだわー』とブツクサ言うsnj14
- taizooo: http://d.hatena.ne.jp/taizooo/20080523/1211535403
- otsune: hAtomにrequiredなAuthorが無いな
- snj14: authorはhAtom0.2でoptionalになるらしいよ．個人的にはmicroformatsにrequireは不要だと思う．組み合わせれば良いんだし．
- forestk: 同意しつつも最低限を決めておかないと、活用しにくいかもとは思う。hAtom に rel="bookmark" ないとどうかなぁ、とか
- ↑from: [http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/taizooo/20080523/1211535403]
- :
- snj14: オレ，rel-bookmarkも嫌いなんだわー． [http://twitter.com/snj14/statuses/820148977]
- snj14: 例えば http://tinyurl.com/5kqdxo はtwitter検索内のパーマリンクなんだけど，twitterのパーマリンクは http://twitter.com/fuba/statuses/815883523 [http://twitter.com/snj14/statuses/820149407]
- snj14: 両方のリンクをHTML内に入れるとして，どっちがrel="bookmark"なの？「どっちをブックマークするか」ってユーザが決めることなんじゃないの？なんでサイト側が指定すんの？…同じ問題がふぁぼったーとかパーマリンクのあるSBMとかでもあるよねぇ． [http://twitter.com/snj14/statuses/820151794]
- snj14: SBMの例だと，これとか→ http://tinyurl.com/6z7a3c [http://twitter.com/snj14/statuses/820153088]
- snj14: ミスった．これね． http://tinyurl.com/6aruno はてなスターの状況を見たいときはこっちだけど， [http://twitter.com/snj14/statuses/820154602]
- snj14: 本文読みたいときってこっちじゃん． http://d.hatena.ne.jp/taizooo/20080523/1211535403 ユーザが選べるようにしたほうが良いはずだよね．rel-bookmarkっていう用途を限定したmicroformatsにしたからこうなる． [http://twitter.com/snj14/statuses/820155560]
- snj14: そうじゃなくて，rel="EntryExternalURI"とかrel="EntryInternalURI"とかみたいに純粋に構造だけを記述すれば(なんか長くてキモイけど)， [http://twitter.com/snj14/statuses/820157695]
- snj14: キカイが「ああ，なんか二つある．でもオレっちは本文読む用のプログラムだからexternalの方を開こうっとー」とか，出来るわけで． [http://twitter.com/snj14/statuses/820157952]
- snj14: と，そんなことを http://tinyurl.com/6qyqk9 のforestkさんのコメントを見て思った． [http://twitter.com/snj14/statuses/820159545]
- snj14: hAtomは(残念なことに)，「Atomに変換する用」になっちゃってるから，Atomに変換するんだったら「パーマリンクが要る」って思うのではないかと． [http://twitter.com/snj14/statuses/820160534]
- snj14: 用途と構造を別にすれば，Atomに変換するプログラムは「ブログのエントリ用のmicroformatsが使われていて，かつ，パーマリンクもあったらAtomに変換できるよ．でなきゃinvalidだからオレっちを使ってAtomに変換したいなら両方定義してね」って宣言しちゃえば良い． [http://twitter.com/snj14/statuses/820162477]
- snj14: パーマリンクはいらないけどブログの構造は欲しいっていう他のプログラムまで「パーマリンクのmicroformatsがなければinvalid！」とか無駄じゃん． [http://twitter.com/snj14/statuses/820163964]
- otsune: あるblog entryのURIとそれのブックマークコメントのpermalinkとか、favotterのURIと元ネタtwitterのURIが違うのは当たり前というか違うものなんだから別のURIじゃないと困るだろ。
- otsune: ちゅーか「今提供しているこのページはURIという一意のデータでいうと○○ですよ」というのをrel="bookmark"で示せってことで。「ソーシャルブックマークでそのURIを登録しなきゃダメ」なんて狭く斜め上に飛躍したデータを提示してるわけじゃない。"bookmark"という名前に惑わされ過ぎ。
- otsune: あと「blogとそのはてブ」とか「favotterと元ネタtwitter」なんてのはRFC 4685的な仕組みで提供できるように進化するのが筋の良い方法だと思う。（EntryExternalURIなんちゃらよりは健全）。
- otsune: とにかく「どっちをブックマークするか」なんてミクロ視点でrel="bookmark"の意味を読み違えるのはマズい。
- snj14: 「favotterのURIと元ネタtwitterのURIが違うのは当たり前というか違うものなんだから別のURIじゃないと困る」←もちろん．
- snj14: 「「今提供しているこのページはURIという一意のデータでいうと○○ですよ」というのをrel="bookmark"で示せってことで」←これが複数の意味で解釈できるから嫌い．favotterはrel="bookmark"をつける場合，元のtwitterのパーマリンク対してrel="bookmark"をつけるのか，favotter内のパーマリンクに対してrel="bookmark"をつけるのか？
- snj14: rfc 4685的な仕組み がよく分かってないんだけど，HTML内のmicroformatsでスレッドを表現するんだったら，やっぱり，twitterのパーマリンクとfavotterのパーマリンクを別のmicroformatsで表現する必要があるんじゃないの？
- otsune: 俺の感覚だと明らかに「favotter内のパーマリンクに対してrel="bookmark"をつける」がまっとうに見える。なぜならそのリソースはfavotterであってtwitterではないじゃん。
- otsune: だから「あるマッシュアップサイトの言及先とか元ネタを示す一意のURI」をrel="bookmark"に入れるのも混乱した間違いだし、rel="bookmark"をまったく無しにするってのもアホにしかみえない。
- otsune: ただ「用途外の利用法だけどfavotterのAtomで元ネタのURIを知りたいんだ。じゃないと個人的に不便」っていう欲望があることは尊重されるべきで。そういう人間の欲望を満たすために規格や仕様は進化するべきだとも思っている。
- otsune: そのときに「用途外の使い方が出来ないからrel="bookmark"は嫌いだ」ってのが、違う話を一緒くたにしている混乱だと思ったのだ。
- snj14: 「なぜならそのリソースはfavotterであってtwitterではないじゃん。」←じゃあ，googleみたいなページはどうなる？「googleなりのサマリ」というメタデータのついたgoogle内のpermalinkみたいなものは無いと思う．
- snj14: であれば，googleの検索結果の先のリンクにはrel-bookmarkを付けられないことになる．もし付けるなら，machine readableではないよね．サイトによってrel-bookmarkの意味が「内部のpermalink」か「外部のpermalink」かが変わるんだから．
- snj14: じゃあ，これらを明示するために，rel-bookmarkっていう規格(仕様?)を進化させる必要があるんじゃないか？と思って，EntryInternalURIとかEntryExternalURIとか書いたんだわ．
- otsune: それだと「rel="bookmark"なんて嫌いだ」とか意味不明な駄々を主張してんじゃなくて「「googleなりのサマリ」というメタデータのついたgoogle内のpermalinkみたいなもの」をrel="bookmark"に入れる事に成るよね。
- otsune: Googleが検索対象には（SEOにはこうしろという発言によって）綺麗なpermalinkを要求しているわりに、自分の結果結果には（わざとなのか）汚くてpermalinkじゃないURLを使っているって現状があることはよく解るけど。
- otsune: それは「「どっちをブックマークするか」ってユーザが決めることなんじゃないの？」という指摘とはまったく無関係なことだよね？ おれはその指摘は完全にrel="bookmark"のネーミングで誤解した的外れなものだと思ったの。
- otsune: むしろGoogle検索結果はmap reduceでその場で自動生成したページだし、二度と同じ結果が出ないからpermalink（っぽいURI）をわざと付けてないと思う。
- otsune: これはGoogleに限らず「再現性の無いWebページはpermalink（っぽいURI）をあえて付けないよ」という運用としてはアリなんじゃないかなぁ。（すくなくともそういうWebページはxFolkにはなるだろうけど、hAtomにはならないだろうし）
“
rel=”bookmark”
The HTML4 spec (http://www.w3.org/TR/REC-html40/types.html#h-6.12) describes a bookmark as “a link to a key entry point within an extended document”. By convention (citation needed), this entry point also captures the notion of a “permalink”.
“
rel=”bookmark”
The HTML4 spec (http://www.w3.org/TR/REC-html40/types.html#h-6.12) describes a bookmark as “a link to a key entry point within an extended document”. By convention (citation needed), this entry point also captures the notion of a “permalink”.
“
rel=”bookmark”
The HTML4 spec (http://www.w3.org/TR/REC-html40/types.html#h-6.12) describes a bookmark as “a link to a key entry point within an extended document”. By convention (citation needed), this entry point also captures the notion of a “permalink”.
rel-bookmarkの話しよくわかんねーや。
googleのページなんてオイラのページじゃないし。
microformatsってそのページの創造主がそのページに力を与えるためのモノなんでしょ。
tumblrで考えたときに、さあどうなんだ?
LDRize で “v” とか “o” したときに、どのページが開いてほしいかってことだよねえー
オレ・レベルまで落し込んでいうと。
なんか違うか。
“ ストロング小林VSビル・ロビンソン
カール・ゴッチVSビル・ロビンソン
ストロング小林VSモンスター・ロシモフ（後のアンドレ・ザ・ジャイアント）
グレート草津、ラッシャー木村VSダスティ・ローディス、ディック・マードック
アニマル浜口VSブラック・ジャック・マリガン
ストロング小林VSバーン・ガニア
カール・ゴッチVSビル・ロビンソン
ストロング小林VSモンスター・ロシモフ（後のアンドレ・ザ・ジャイアント）
グレート草津、ラッシャー木村VSダスティ・ローディス、ディック・マードック
アニマル浜口VSブラック・ジャック・マリガン
ストロング小林VSバーン・ガニア
“ ストロング小林VSビル・ロビンソン
カール・ゴッチVSビル・ロビンソン
ストロング小林VSモンスター・ロシモフ（後のアンドレ・ザ・ジャイアント）
グレート草津、ラッシャー木村VSダスティ・ローディス、ディック・マードック
アニマル浜口VSブラック・ジャック・マリガン
ストロング小林VSバーン・ガニア
カール・ゴッチVSビル・ロビンソン
ストロング小林VSモンスター・ロシモフ（後のアンドレ・ザ・ジャイアント）
グレート草津、ラッシャー木村VSダスティ・ローディス、ディック・マードック
アニマル浜口VSブラック・ジャック・マリガン
ストロング小林VSバーン・ガニア
“ ストロング小林VSビル・ロビンソン
カール・ゴッチVSビル・ロビンソン
ストロング小林VSモンスター・ロシモフ（後のアンドレ・ザ・ジャイアント）
グレート草津、ラッシャー木村VSダスティ・ローディス、ディック・マードック
アニマル浜口VSブラック・ジャック・マリガン
ストロング小林VSバーン・ガニア
カール・ゴッチVSビル・ロビンソン
ストロング小林VSモンスター・ロシモフ（後のアンドレ・ザ・ジャイアント）
グレート草津、ラッシャー木村VSダスティ・ローディス、ディック・マードック
アニマル浜口VSブラック・ジャック・マリガン
ストロング小林VSバーン・ガニア
“
microformats | About microformats
にmicroformatsは”An evolutionary revolution”であって”defining the whole world, or even just boiling the ocean”じゃないって書いてある。
“
microformats | About microformats
にmicroformatsは”An evolutionary revolution”であって”defining the whole world, or even just boiling the ocean”じゃないって書いてある。
“
microformats | About microformats
にmicroformatsは”An evolutionary revolution”であって”defining the whole world, or even just boiling the ocean”じゃないって書いてある。
“ えええ、「rel=”nofollow”」って、単に<a>タグにアトリビュート拡張してるだけじゃん。これがMicroformat？ マジすか？ いきなり驚愕。
“ えええ、「rel=”nofollow”」って、単に<a>タグにアトリビュート拡張してるだけじゃん。これがMicroformat？ マジすか？ いきなり驚愕。
“ えええ、「rel=”nofollow”」って、単に<a>タグにアトリビュート拡張してるだけじゃん。これがMicroformat？ マジすか？ いきなり驚愕。
“ いくつかのページをざっと見て、最初のとっかかりに選んだのは「はてな」のnaoya氏のエントリ。「microformats って一体何だ?」
“ いくつかのページをざっと見て、最初のとっかかりに選んだのは「はてな」のnaoya氏のエントリ。「microformats って一体何だ?」
“ いくつかのページをざっと見て、最初のとっかかりに選んだのは「はてな」のnaoya氏のエントリ。「microformats って一体何だ?」
実はmicroformatsをグリグリ最大限に使って恩恵にあずかっている人達って、tumblr界隈だったりLDR界隈だったりごく限られたところだけだったりするんか?
twitter界隈もか。
って、界隈ってなんだよー、気持わるい言葉つかっちまった。
cxx:
cxx:
Dashboardで読んだ最新postのIDを覚えておいて http://www.tumblr.com/dashboard/10000/-[ID] にアクセスし、newerリンクを辿っていくことで前回の続きから読める。2回目からは最後に読んだ箇所をブックマークしておけばいい。AutoPagerizeを切っておかないと却って邪魔になる。ので、快適にやりたければ専用クライアントなりが必要になる（AutoPagerizeのソースに http://www.tumblr.com/dashboard/*/-* のSITEINFOを書いちゃってもいいか）。でも、Dashboardを全部読もうとするのはfollowingをそれなりに絞ってない限り不毛じゃないかなーと思う。AutoPagerize で継ぎ足されるブロック毎の先頭に “page: xx” っていうアンカーが出るので、最後に読んだブロックのそれをクリックしてからブックマークしてます。（話の趣旨が違う？）
僕の書き方が悪かったです。言いたかったのは、Dashboardは通常は最新postから読むことになるけど、最後に読んだpostを起点に”newer”を反対に辿っていけば、「あれ？ 前にここ読んだっけ？」という状況は起こらないなーということです。
すいません、こっちが勘違いしてました。Dashboard は過去に向かって潜る使い方しか頭に無かった。AutoPagerize をうまく改造できれば逆の座標も面白いですね。
“older” を遡るのが「潜る」なら、”newer” を辿るのは水面へ向かって浮上していくイメージだろうか。しかも水位はリアルタイムに上昇していくと。
ぜんっっぜん、関係ないんだけど、オレ、
javascript:(function(){var id = Number( window.location.pathname.match(/\d+/)[0] );url ='http://www.tumblr.com/dashboard/100/' + (id + 1);window.open(url);})();
っていうbookmarkletを使って特定のpostのフローを http://www.tumblr.com/dashboard/100/-[ID] っていう permalink? (snapshot?) とみなして Clip してるんだ。
だけど otsune からはそーいう tumblr 外の人からは全然わけわかめな link を公衆の面前に晒すのはバカっぽいからヤメたほうがいいんじゃね(意訳)といわれた。でも、reblogフローのなかの1postに着目してもなんもわかんないんだもん。ねエ～。
それから潜水とか浮上とかの感覚は好きなんだけど、LDRizeが正当に進化すればたぶん、ページの概念は吹っ飛んでしまうんだろーと思うよ。
ただひたすら、”j”で古いpostへ、”k”で新しいpostへ、って。
(思うっていうよりは、期待しているっていうか、まあ、自分にもなにかできないかなあとか)
あと、dashboardを流れるpostをどう読むかわ、じぶんの自由!!!
みんなdashboardをどううまく潜るかみたいな感じなのかなあ。そういう意味ではもうオレは”ヘタレ”てるかもしれんなあ。
おもしろいpostがどんな風にreblogされていくかとか、コレとコレとコレのphotoが並んでいてみんなはコッチをもっていくのにコッチは持っていかないなあ、とか、そういう下世話なところに気持ちがいっている。
ああ、やっぱりこの人はコレを持っていくんか、じゃあオレはアレをいただこうとか、表側からブラインドにphotoを貰っていって、後でウラから見て、ああ、やっぱりオレのrblgするphotoはちょっと写真の人からはズレてるんかあ、とか確認してみたり。
いや、前はそういう行為を卑しいかとおもってたんだよ。tumblrってそういうもんじゃねーだろー、とか。
でも、いまは前よりも、やっぱりソーシャルなところを意識してるんだな。無言のコミュニケーション。なんつったっっけ? ノンバーバル?
なんつーか、ノイズ?
『オレ、rel-bookmarkも嫌いなんだわー』とブツクサ言うsnj14
- taizooo: http://d.hatena.ne.jp/taizooo/20080523/1211535403
- otsune: hAtomにrequiredなAuthorが無いな
- snj14: authorはhAtom0.2でoptionalになるらしいよ．個人的にはmicroformatsにrequireは不要だと思う．組み合わせれば良いんだし．
- forestk: 同意しつつも最低限を決めておかないと、活用しにくいかもとは思う。hAtom に rel="bookmark" ないとどうかなぁ、とか
- ↑from: [http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/taizooo/20080523/1211535403]
- :
- snj14: オレ，rel-bookmarkも嫌いなんだわー． [http://twitter.com/snj14/statuses/820148977]
- snj14: 例えば http://tinyurl.com/5kqdxo はtwitter検索内のパーマリンクなんだけど，twitterのパーマリンクは http://twitter.com/fuba/statuses/815883523 [http://twitter.com/snj14/statuses/820149407]
- snj14: 両方のリンクをHTML内に入れるとして，どっちがrel="bookmark"なの？「どっちをブックマークするか」ってユーザが決めることなんじゃないの？なんでサイト側が指定すんの？…同じ問題がふぁぼったーとかパーマリンクのあるSBMとかでもあるよねぇ． [http://twitter.com/snj14/statuses/820151794]
- snj14: SBMの例だと，これとか→ http://tinyurl.com/6z7a3c [http://twitter.com/snj14/statuses/820153088]
- snj14: ミスった．これね． http://tinyurl.com/6aruno はてなスターの状況を見たいときはこっちだけど， [http://twitter.com/snj14/statuses/820154602]
- snj14: 本文読みたいときってこっちじゃん． http://d.hatena.ne.jp/taizooo/20080523/1211535403 ユーザが選べるようにしたほうが良いはずだよね．rel-bookmarkっていう用途を限定したmicroformatsにしたからこうなる． [http://twitter.com/snj14/statuses/820155560]
- snj14: そうじゃなくて，rel="EntryExternalURI"とかrel="EntryInternalURI"とかみたいに純粋に構造だけを記述すれば(なんか長くてキモイけど)， [http://twitter.com/snj14/statuses/820157695]
- snj14: キカイが「ああ，なんか二つある．でもオレっちは本文読む用のプログラムだからexternalの方を開こうっとー」とか，出来るわけで． [http://twitter.com/snj14/statuses/820157952]
- snj14: と，そんなことを http://tinyurl.com/6qyqk9 のforestkさんのコメントを見て思った． [http://twitter.com/snj14/statuses/820159545]
- snj14: hAtomは(残念なことに)，「Atomに変換する用」になっちゃってるから，Atomに変換するんだったら「パーマリンクが要る」って思うのではないかと． [http://twitter.com/snj14/statuses/820160534]
- snj14: 用途と構造を別にすれば，Atomに変換するプログラムは「ブログのエントリ用のmicroformatsが使われていて，かつ，パーマリンクもあったらAtomに変換できるよ．でなきゃinvalidだからオレっちを使ってAtomに変換したいなら両方定義してね」って宣言しちゃえば良い． [http://twitter.com/snj14/statuses/820162477]
- snj14: パーマリンクはいらないけどブログの構造は欲しいっていう他のプログラムまで「パーマリンクのmicroformatsがなければinvalid！」とか無駄じゃん． [http://twitter.com/snj14/statuses/820163964]
- otsune: あるblog entryのURIとそれのブックマークコメントのpermalinkとか、favotterのURIと元ネタtwitterのURIが違うのは当たり前というか違うものなんだから別のURIじゃないと困るだろ。
- otsune: ちゅーか「今提供しているこのページはURIという一意のデータでいうと○○ですよ」というのをrel="bookmark"で示せってことで。「ソーシャルブックマークでそのURIを登録しなきゃダメ」なんて狭く斜め上に飛躍したデータを提示してるわけじゃない。"bookmark"という名前に惑わされ過ぎ。
- otsune: あと「blogとそのはてブ」とか「favotterと元ネタtwitter」なんてのはRFC 4685的な仕組みで提供できるように進化するのが筋の良い方法だと思う。（EntryExternalURIなんちゃらよりは健全）。
- otsune: とにかく「どっちをブックマークするか」なんてミクロ視点でrel="bookmark"の意味を読み違えるのはマズい。
- snj14: 「favotterのURIと元ネタtwitterのURIが違うのは当たり前というか違うものなんだから別のURIじゃないと困る」←もちろん．
- snj14: 「「今提供しているこのページはURIという一意のデータでいうと○○ですよ」というのをrel="bookmark"で示せってことで」←これが複数の意味で解釈できるから嫌い．favotterはrel="bookmark"をつける場合，元のtwitterのパーマリンク対してrel="bookmark"をつけるのか，favotter内のパーマリンクに対してrel="bookmark"をつけるのか？
- snj14: rfc 4685的な仕組み がよく分かってないんだけど，HTML内のmicroformatsでスレッドを表現するんだったら，やっぱり，twitterのパーマリンクとfavotterのパーマリンクを別のmicroformatsで表現する必要があるんじゃないの？
- otsune: 俺の感覚だと明らかに「favotter内のパーマリンクに対してrel="bookmark"をつける」がまっとうに見える。なぜならそのリソースはfavotterであってtwitterではないじゃん。
- otsune: だから「あるマッシュアップサイトの言及先とか元ネタを示す一意のURI」をrel="bookmark"に入れるのも混乱した間違いだし、rel="bookmark"をまったく無しにするってのもアホにしかみえない。
- otsune: ただ「用途外の利用法だけどfavotterのAtomで元ネタのURIを知りたいんだ。じゃないと個人的に不便」っていう欲望があることは尊重されるべきで。そういう人間の欲望を満たすために規格や仕様は進化するべきだとも思っている。
- otsune: そのときに「用途外の使い方が出来ないからrel="bookmark"は嫌いだ」ってのが、違う話を一緒くたにしている混乱だと思ったのだ。
- snj14: 「なぜならそのリソースはfavotterであってtwitterではないじゃん。」←じゃあ，googleみたいなページはどうなる？「googleなりのサマリ」というメタデータのついたgoogle内のpermalinkみたいなものは無いと思う．
- snj14: であれば，googleの検索結果の先のリンクにはrel-bookmarkを付けられないことになる．もし付けるなら，machine readableではないよね．サイトによってrel-bookmarkの意味が「内部のpermalink」か「外部のpermalink」かが変わるんだから．
- snj14: じゃあ，これらを明示するために，rel-bookmarkっていう規格(仕様?)を進化させる必要があるんじゃないか？と思って，EntryInternalURIとかEntryExternalURIとか書いたんだわ．
- otsune: それだと「rel="bookmark"なんて嫌いだ」とか意味不明な駄々を主張してんじゃなくて「「googleなりのサマリ」というメタデータのついたgoogle内のpermalinkみたいなもの」をrel="bookmark"に入れる事に成るよね。
- otsune: Googleが検索対象には（SEOにはこうしろという発言によって）綺麗なpermalinkを要求しているわりに、自分の結果結果には（わざとなのか）汚くてpermalinkじゃないURLを使っているって現状があることはよく解るけど。
- otsune: それは「「どっちをブックマークするか」ってユーザが決めることなんじゃないの？」という指摘とはまったく無関係なことだよね？ おれはその指摘は完全にrel="bookmark"のネーミングで誤解した的外れなものだと思ったの。
- otsune: むしろGoogle検索結果はmap reduceでその場で自動生成したページだし、二度と同じ結果が出ないからpermalink（っぽいURI）をわざと付けてないと思う。
- otsune: これはGoogleに限らず「再現性の無いWebページはpermalink（っぽいURI）をあえて付けないよ」という運用としてはアリなんじゃないかなぁ。（すくなくともそういうWebページはxFolkにはなるだろうけど、hAtomにはならないだろうし）
- snj14: まとめてみたら，ちょっとスッキリしたのでもう少し追記する．先に謝っておくと，rel-bookmarkサン，嫌いって言ってゴメン．あんた分かりにくすぎるよホントにもう．今は好きだよ．
- snj14: さっきまではrel-bookmarkの名前が悪いと思ってたけど，とりあえず，これだけ広まってるマークアップの名前が悪いわけが無いと仮定する．rel-bookmarkの意味を名前だけ見て解釈すると，relは現在のページからリンク先のページへの関係を表すので，「このページから見ると，このリンク先のページはbookmarkの関係にある」となる．
- snj14: bookmarkの関係って何だろうか．少し無理やり解釈すると「このページでは，この(パーマリンクのある)リンク先のページをブックマークしろ」もしくは「このページは，この(パーマリンクのある)リンク先のページをブックマークした」の２つくらいだと思う．
- snj14: まず前者は，上のほうでオレも書いたしotsuneさんも「「ソーシャルブックマークでそのURIを登録しなきゃダメ」なんて狭く斜め上に飛躍したデータを提示してるわけじゃない」と書いているのでたぶん違う．
- snj14: じゃあ後者が正解なのかといえば，上に書いたように，「このパーマリンクのあるリンク先のページ」ってのが複数解釈できる．favotter内のパーマリンクとtwitter内のパーマリンクの両方をブックマークしたページなわけだ．なので，どちらのリンクにrel-bookmarkをつけても関係としては正しいと考えられる．
- mattn: 実は「rel-bookmark」というのはAsIsな物な気がしてきた[http://b.hatena.ne.jp/mattn/20080527#bookmark-8748398]
- mattn: rel-bookmarkとは、それが含まれるドキュメントの内1点を指すべき物であり、rel-bookmarkがドキュメント内で実際のリンク先を指すべき、とまでは決めてない。あくまでpermalink扱い。[http://mattn.kaoriya.net/web/20080527204717.htm]
- snj14: そういうことなんだと思う．どちらも正しいのだけれどotsuneさんの感覚でいうと「favotter内のパーマリンクにrel-bookmarkを張るべき」なんだろうと思う．
- snj14: じゃあ，どっちにもrel-bookmarkを入れれば良いじゃん！ってなるけど，そうするとキカイが判断できなくなる．人には理解できてもmachine readableでない．それじゃあmicroformats的じゃない．
- snj14: そこで，解決策としてrel-bookmarkを廃止してEntryExternalURIとか言ってみたんだけど，それもmicroformats的じゃない．
- snj14: microformatsとは「人がまず優先、機械はその次という考えのもとにデザインされた Microformats は、すでに現存し、幅広く受け入れられている標準をベースに整備された、シンプルでオープンな一連のデータ形式です。」って，http://microformats.org/wiki/what-are-microformats-ja に書いてあるからね．
- snj14: そこで新しい提案．relは複数の値を入れることが出来るので，rel="bookmark external"とかrel="bookmark origin"のようにすれば万事オッケーじゃね？rel-bookmarkの意味を損なうことなく，よりmachine readableになる．2つ目の単語(external 外部の, origin 起源,,,)はしっかり考えないといけないけど．
“ その議論どこでやってるんすか？
“ その議論どこでやってるんすか？
“ その議論どこでやってるんすか？
“ twitter，はてブのコメ，Tumblrが入り乱れて，ですかね．
“ twitter，はてブのコメ，Tumblrが入り乱れて，ですかね．
“ twitter，はてブのコメ，Tumblrが入り乱れて，ですかね．
なんつーか、ただの、コレクション癖のあるおっさんと化している。
“ rel-bookmark戦争
“ rel-bookmark戦争
“ rel-bookmark戦争
“ http://www.tumblr.com/dashboard/check_for_new_posts/after/0 でDashboardの全post数が分かるかと思ったけど誤差があるみたいだ。もしかしたら誤差があるのは http://www.tumblr.com/dashboard/n の方かも知れないけど。
“ http://www.tumblr.com/dashboard/check_for_new_posts/after/0 でDashboardの全post数が分かるかと思ったけど誤差があるみたいだ。もしかしたら誤差があるのは http://www.tumblr.com/dashboard/n の方かも知れないけど。
“ http://www.tumblr.com/dashboard/check_for_new_posts/after/0 でDashboardの全post数が分かるかと思ったけど誤差があるみたいだ。もしかしたら誤差があるのは http://www.tumblr.com/dashboard/n の方かも知れないけど。
cxx gj!!!
中学生日記のくせにナマイキだ :)
どうせだからさー、wedataにあげちゃえヨ! だれにも迷惑かかんないって。そうとう狭いスイートスポットなんだからさー。
AutoPagerizeでnewerリンクを辿っていくためのSITEINFO
cxx:
Dashboardを時系列に読む。ページ内のpostは逆順になるけど。{ url: '^http://www\\.tumblr\\.com/dashboard/\\d+/-\\d+', nextLink: 'id("pagination")/a[@title="Go to newer posts"]', pageElement: 'id("posts")', exampleUrl: 'http://www.tumblr.com/dashboard/2/-1', },ロケーションバーにhttp://www.tumblr.com/dashboard/100000/-[最後に読んだpostのID]などと入力して使う（ハイフン忘れずに）。Dashboardのお姉さんが出てきたら終点。
“ web3.0の正しい読み方。3の倍数で3がつく数字なので「うえぶさあ〜んてんじぇろ」と読むのが正解。
“ web3.0の正しい読み方。3の倍数で3がつく数字なので「うえぶさあ〜んてんじぇろ」と読むのが正解。
“ web3.0の正しい読み方。3の倍数で3がつく数字なので「うえぶさあ〜んてんじぇろ」と読むのが正解。
