cxx:
http://{domain name}[/page/{page}][/rss]
http://{domain name}[/post]/{post id}[/{summary}][/rss]
http://{domain name}/tagged/{tag}[/chrono][/page/{page}][/rss]
http://{domain name}/search/{word}[/page/{page}][/rss]
http://{domain name}/day/{yyyy}/{mm}/{dd}[/rss]
http://{domain name}/mobile[/page/{page}]
http://{domain name}/js
http://{domain name}/archive
http://{domain name}/random
http://{domain name}/private/{post id}/{key}
http://{domain name}/api/(read[/json]|write|delete|authenticate)
http://{domain name}/sitemap[{page}].xml
http://{domain name}/robots.txt
自分のtumblr内を検索できるようにしたいのならGoogleサイト内検索ボックスを設置すればいいじゃない - さつまいものたねいも - たんぶら部 - Tumblove -
“AutoPagerize対応。万が一tumblrのSITEINFOが変わってもMicoroformats(autopagerize_page_element+autopagerize_insert_before)で対応しているので安心。
hAtomにも対応。だけどbodyの末尾にtumblr codeが自動的に埋め込まれるせいかうまく解析できない。
xFolkにも対応させたかったけど,QuoteやPhotoのtaggedlinkをどうすればいいのか分からなかったので諦めた。
”
『オレ、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の関係って何だろうか.少し無理やり解釈すると「このページでは,この(パーマリンクのある)リンク先のページをブックマークしろ」もしくは「このページは,この(パーマリンクのある)リンク先のページをブックマークした」の2つくらいだと思う.
- 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 起源,,,)はしっかり考えないといけないけど.
“Tomblooでquoteをpostするときに、Tumblr以外のサービスにpostすると自分の書いたテキストのように見えてしまうのでダブルクオートでくくって回避します。”
300
What happens when you follow more than 300 people? How does the dashboard know who to stop showing? Does he start from the back or the front?
Overfollowing Tumblrs like myself need to know.
The current limit is 400. We increase it every so often as our infrastructure grows to support it.
The Dashboard posts-of-friends fetch hits Tumblr’s database architecture harder than anything else in the service — and it gets hit a lot. We currently can’t afford to remove this limit.
As for which 400 people it chooses if you follow more than that, it’s undefined. There’s no ORDER BY in that query. It will probably include the most-recent 400, but that can’t be guaranteed every time, especially as we make changes and optimize that feature.
それTomblooでできるよ! Webページのスクリーンショットをとる « ku
引用:”Regionを選ぶと、キャプチャする範囲をマウスで選べます。Elementだとマウスを動かすとHTMLの要素単位でハイライトされるのでキャプチャしたい要素を選んでクリックします。Viewを選ぶと今ブラウザに表示されている範囲がキャプチャされます。Pageを選ぶと今表示されていない部分も含めたページ全体がキャプチャされます。”
“ただWindowsではFirefoxの問題でFlashがスクリーンショットに映らないです。Flashのページのスクリーンショットをとりたいときは別の何かを使ってください…”
“「われわれはプラグインをなくしたいと思っています。これはセキュリティの問題にも通じるのですが、せっかくGoogle Chromeで、マルチプロセスでサンドボックス化していても、プラグインがあると、そこがネックになり得ます」”
Reblogとは
tzz:
いまこちらのポストを当方でReblogしたわけだが,これは一体なんだろうという気がする。どうも引用や転載とは違いそうだ。引用なり転載なりの場合,対象となるテクストや画像が他人のそれであることを一般に公示することが最も基本的なルールなので,そうした公示をせずに他人の文章を頂戴したりすれば剽窃ということになってしまう。ところがTumblrではそれが許されている。
__________________
誰も許してはいない。
後からすごい請求書が来るから、
貯金のない人は気を付けて。
__________________
僕はこれを凄くwitに富んだjokeだと思って、感心したのだけど、
自意識が肥大化した人にとっては「私に絡んでこようとする者」と認識及び形容されてしまう、という事がわかって、
自意識とはげにおそろしきものだと思い至った。—
これからは(笑)とかwをつけてジョークであることを明らかにしないといけない予感
\\\
全てがジョークやユーモアなんで、自分のtumblrのタイトルに
(笑)とかwをつけて見ようかと思ったけど、読んだ人にとって
面白くなかったときを考えると。。。
最近の Tumblr 転載問題
参考:転載、引用、盗用 区別のつかない人が意外に多い http://d.hatena.ne.jp/lastline/20080111/1200040740
- 引用は、要件を満たせば著作者・著作権者の承諾無しにできる。
- 転載は、著作者・著作権者の承諾を得れれば可能。ただし、著作者・著作権者の条件を飲む必要がある。基本的には転載元を明確にすることが求められる。
- 盗用は著作者・著作権者の承諾を得ない転載、引用の要件を満たさない引用。
- 盗作は、他人の著作物を自身の著作物として発表すること。
Tumblr では画像転載しまくりである。
同様に、pya! とかねたミシュラン、その他画像掲示板も転載しまくり。ほとんどは作者の許可を得ていないっぽいので盗用だろう。転載するにしても、せめてオリジナルが何かを示して欲しいが、転載の繰り返しでオリジナルが不明になっているのだろう。だから、転載の転載はイカンのであるが。
Tumblr は転載元が大体書かれているし、改変されるということもない。だからと言って、転載が許可されてない画像を転載するのはイカンだろう。Tumblr の場合は某所が画像を紹介する際に画像がたくさん貼られた Tumblr にリンクを貼って紹介するのが問題になっておるようですが。Tumblr 側が転載元を明示していても読者がそこまで辿るとは限らない。そもそも、Tumblr に画像を紹介する側がオリジナルにリンク貼ればよいだけの話でもある。もちろん、Tumblr にガンガン画像を転載しても良いという理由にはならないが。
この、オリジナルにリンク貼らない問題は個人ニュースサイトにもありますね。エロ動画サイトよろしく、大元の記事にたどり着くまでにたくさんのニュースサイトを経由させる場合が偶にある。これも最初から元の記事にリンク貼れよと。
翻って、拡散係数と言う観点で見ると転載は恐ろしいほどに広まる。これがネットの長所でもあり怖さであろう。僕としては、オリジナルであることが保障されてるならガンガン転載して広めて欲しいとも思う。その点で、Tumblr の reblog は面白いなと思う。
ニコニコ動画の無断転載に「ありがとう」──「魔理沙は~」「ウサテイ」のFlash作者が語る本音 (http://ascii.jp/elem/000/000/096/96036/index-4.html)ってのはオリジナルが保障されているからだろう。動画は画像と違って情報量が多いので、誰が作ったのか分かりやすいし。クレジットを入れることも可能。画像に、絵画のサインみたいにクレジット例えばURLを挿入する方法もあろうが、それは描き手の責任じゃないし。転載する側が勝手に挿入するのは改変ですし。
極論すれば、転載されたくないならネットに載せるな!って話ではあるんですが、それはいくらなんでも極論過ぎる。また、転載までは仕方が無いとしてもだからと言って盗用・盗作が正当化される分けでもない。「転載」といいながら、オリジナルが別に存在することを明記して無いなら盗用・盗作でしょうよ。
— lastline
そう。元サイトのリンク貼らないと盗作扱いと思われても仕方ないかと
— felynn
とりあえず盗作に関しては「tumblr上のpostは全てオリジナルではない」と言い切ってしまうことはできると思う。オリジナルがどこにあるかを示せなくても、オリジナルは別にあるはずですとは言い切っちゃって良いでしょ。盗作の回避はそれで充分ではないかと。
[tumblrと転載と広告効果のおはなし]
上の図はWikipediaのロングテール項から拾ってきたものであるが、これを参考にしながら私なりにtumblrと転載と広告効果ついて語ってみようと思う。決して実測データから得られたものではないのだが、これから説明する内容は雰囲気だけ分かってもらえれば良いものだと思うので、読者も雰囲気だけ捉えて欲しい。
- まず前提として、図の縦軸をtumblrに転載されたpostのオリジナルへのリンク率とし、横軸を単位時間内の転載post件数として見る事とします。
- パレートの法則(例:売上の8割は、全従業員のうちの2割で生み出している)に則り色分けがされている訳ですが、今回は緑の部分は転載postから閲覧者がオリジナルに辿り着くのに良く貢献し、黄色のロングテール部分は転載postから閲覧者がオリジナルに辿り着くにはあまり貢献しない部分という意味にとります。
- オリジナルへのリンクを優先すると閲覧者がオリジナルに到達しやすくなりますが、掲載が制限されるためpost数は減少します。そのため、広告効果は減少します。
- オリジナルへのリンクを気にしないほどpost数は大きくなりますが、閲覧者がオリジナルへ到達しにくくなっていくので、やはり広告効果は減少します。
- つまり、どちらの軸を優先してもtumblrは広告媒体としての有用性を損ないます。
- 権利侵害を気にする余り、post数をゼロにした場合は確かに権利侵害はしませんが、広告効果もゼロになるので最善手であると同時に最悪手です。
- 緑色の部分は主に閲覧者をオリジナルに案内する効果があります。
- ロングテール部分は確かに閲覧者がオリジナルに辿り着くにはあまり貢献しない部分ではありますが、全くの無駄ではありません。この部分は大量のpostによって閲覧者が新発見をしやすい部分であり、その発見は「同じ作者の作品をもっと見たい」と考えてもらえる可能性を生み、そういった新規需要を掘り返すのに向いた部分であると言えます。少なくとも、あなたの作品を一度も見た事が無い人が「あなたの作品をもっと見たい」とは決して思わないでしょう。この新規需要の掘り出しに向いた部分がtumblrや類似サービスの新しくも楽しい部分であり、アドバンテージで有るとも考えられます。
- tumblrやそれに類するサービスは閲覧者の新規需要を掘り返す部分と、閲覧者をオリジナルへ案内する部分が混然一体になっているため、運が良ければ新需要を掘り起こした上に閲覧者をオリジナルへ案内する可能性があります。パレートの法則を真に受ければ大体2割ぐらいの確率でしょうか?
- 以上の事を総合すると、tumblrによる広告効率が最も良くなるのはどちらかの軸に偏る事ではなく、うまいことバランスを取った時であろうと推測される。ただ、今回は実測データを元にした話ではないので転載postのオリジナルへのリンク率がいくらぐらいが適当かは提示できません。悪しからず。
◆帰結としてクリエイターの方々へ
- まず、貴方の作品が広まれば広まるほど「作品は知っているけれど、作者が誰であるかは知らない」という人は増えていきます。それは自然のことであり、そこには厳然たるトレードオフが存在します。このトレードオフを無視して「私の作品がどれだけ広まろうとも、私の作品を知る者は全て作者が私である事も知っているべきである」と要求する事は、少なくとも統計上現実的では無い事を理解していただけると幸いです。
- tumblrがクリエイター側に与える恩恵としての広告効果は、パレートの法則を鵜呑みにするならば「tumblr上であなたの作品の転載postに出会って興味を持った人々のうち、20%ぐらいはオリジナルに辿り着くだろう」という程度のものである。がっかりするかもしれないし、そうではないかもしれません。ただtumblr上で貴方の作品に出会って興味を持った人が1000人いれば、そのうち200人はオリジナルに辿り着くというのはそれほど悪い数字ではないと思いませんか?
- そして、この広告効果のコストとして貴方の作品がtumblr上に転載されることを許容していただけると概ね丸く収まると思うのですが、いかがでしょう?
◆終わりにここまで書いてきて言うのもなんだが、自分は統計屋でもなんでもない。むしろド素人である。多分、統計を良く知るものから見れば間違いもあると思う。もし気が付いた点があれば改良して再投していただけると嬉しく思う次第。
『オリジナルへのリンクを優先すると閲覧者がオリジナルに到達しやすくなりますが、掲載が制限されるためpost数は減少します。』でいってる「掲載が制限される」というのが意味不明。何で制限されるの? 「元記事へのリンクを埋め込みたくない人が多い」と仮定してる? 現状の tumblr を見ている限り、そういう仮定は間違いだと思うんだけどなぁ。
「転載postのオリジナルへのリンク率」はかなり高いと思う。体感的には95%以上、リンクが存在してる。少なめにみても80%以上はリンクしてるでしょう。
Rain installation by Stacee Kalmanovsky…
RefControl利用時に起こる現象とその原因など
cxx:
cxx:
この、follow したとたんに dashboard に飛しやがるヤツあ、バグですよねえ。tumblr.inc さん。
RefControlなどを入れてるとそうなります。follow/unfollowをクリックするとフォームが送信されてiframeの中身が更新されますけど、RefControlが有効だと更新後の正しいフォームではなく http://www.tumblr.com/ を読みにいって、それがdashboardに転送されて、更にdashboardにはiframeのチェックが入っていてiframeの中でdashboardが開かれるとlocationが書き換えられるみたいです。普通にアクセスすると起きないことなのでバグと言っちゃうのは気の毒。
あー、RefControl 入れてたわー。しかしさすが cxx だね。どやってしらべてんの? ところで reblog 時に refere 偽装 ってまだ必要だったけ? (試せばいいのか)
前はRefControlが有効だとiframeの中身がdashboardになっていたのが、最近になってtopがdashboardに移動するようになったのでiframe対策だろうと思ってLive HTTP headersでHTTPヘッダ見たりとかjsunpackでapplication.js読んだりとかしました、ツールでreblogするときにrefererを偽装する必要はもうないはずです。
Live HTTP headers ね。試してみよ。今迄 HTTP レスポンスとかは Firebug で見てた。あと、この jsunpack ってオモシロそうだねえ。javascript を unpack するってことね。
(英語ニガテなんだけど…)
