BibTeX 記法を SNS なり HTML なりに書いてそれっぽいリンクにならないのはシンプルに処理系がそういうのに対応していないからであって、 BibTeX の記法がリンクとして使えないことを意味しているわけではない。既存フォーマットを abuse せずにちゃんと処理系で適切な表現を出すことを考えるべき

たとえば「ISBN や URL だけでは不十分だから BibTeX の .bib フォーマットを使う」みたいなのはそういうことだと思うんだけど

意図にせよなんにせよ、 canonical form が存在しない情報への一意なラベルとして ID というものが存在しているわけなので、 ID は一意なラベル以上の何かであることを期待すべきではないし、もし何でもいいから別の情報が入っていてほしいならそのためのフォーマットを発明すべき

後から「分割」する必要が生じるのがそもそも自然ではなくて、最初から「別物だが表示上は一体化できる」くらいの距離感であるべきなんですよ。まあ実装やリンク設計がダルそうというのはもちろんそうなんですが……

さっきの記事の言葉で言うなら、「脱線」はそもそも特定の記事という最小単位パッケージに対する追加ではなく、独立した記事を “埋め込む” ことによって実現される (たとえば『ラーメンばかり食っていると危ない』という小さな “記事” を『ラーメン』記事に “埋め込む” ことでインラインに表示する) べき、ということ

> DB上のページIDと、ページ内容が脱線していく事がある

「ページの『意図』」がそもそも変異しうる、という話では？

よくわかんないけど、場所を示す文字列がどういうフォーマットであろうが、その文字列の中に意図の情報が含まれていないと、場所(URLならばリンク先)が変化してしまうと意図の解釈がおかしくなるって話だと思うんだけど＞＜

つまり「セクションが一方的に “記事” に従属しているように見えてしまうが、そもそもセクション自体が単体で記事レベルのアイテムとして成立しうるし、それが単にリンクされ埋め込み表示されていると捉えるべきではないか？ (そして大抵のアプリはそういうモデリングをできていない)」というのと、「アイテムがひとつの親アイテムの下にあるという木構造はそもそも情報の関係性のモデリングとしてあまりに貧弱すぎるし、それがサブアイテムの切り出しや整理を阻害しているのではないか？」という感じで世界を見ています

「おいしい食事」記事の中に「おこめ」があるかもしれないが、それが埋め込まれて見えているのは本質的な性質ではなく、「おいしい食事としてのおこめ」という情報が「おいしい食事」情報 “でもある” という関係を埋め込みで表現した、ということだと思うのよね。
で、「おいしい食事としてのおこめ」は同時に「おこめ」情報 “でもある” し、また「生活の買い物」情報 “でもある” かもしれないし、さらには「俺のお気に入り」情報 “でもある” かもしれない。
ほらもう木構造では厳しくなってきた

これは私はちょっとだけ違う捉え方をしていて、「セクションと記事の区切りはどこにある」というのと「情報のまとまりの『親』が単一であることを URL や木構造ナビゲーションは要求するが、本来は情報の関係性ってグラフだよね」というのがある

つまり既存の URL 意味論との互換性云々を無視したとしても、混ぜ込むのは健全な設計であるとは思わないし可能な限り避けるべきバッドプラクティスだと思う

IDとタイトルの話、これ思い出した
https://scrapbox.io/shokai/wiki%E3%81%A7%E3%83%9A%E3%83%BC%E3%82%B8%E3%81%AEURL%E3%82%92ID%E3%81%AB%E3%81%99%E3%82%8B%E3%81%A8%E7%B5%B6%E5%AF%BE%E3%81%AB%E3%81%86%E3%81%BE%E3%81%8F%E3%81%84%E3%81%8B%E3%81%AA%E3%81%84

もし新規設計するなら「人間フレンドリーな文字列 + 純粋な識別子」というデータ構造を用意するだろうし、「識別子中に人間用非規範データを混ぜ込む」という手はやっぱり取らないと思う

URL (というよりか URI) が **HTTP/S においては** ID ばかりでなくルーティング情報としても機能しているから「ルート中に無意味な部分があってもナビゲーションに使われなければ問題ない」という発想になってしまうのかもしれないが、 URI 一般にそれを期待すべきでないし、 HTTP でのみ URI 標準から異様に乖離した非ID文字列としてのエセ URI を使ってほしいとも思わない

勝手に改変される identifier、これほど信用できないものもない

それはむしろ「別の用途で使われているかもしれない構造を外部で第三者が勝手に『問題ないだろ』として改変する」ことを推奨しているわけで、 ID どころの騒ぎではないのでは……？

実際、ロケーションバーから URL を全コピーして他所で貼り付けるというのはあまり良い体験ではない。たまに失敗して日本語部分が URL encode されてない人とかいるし。ボタンﾎﾟﾁｰとかで実現されるべきよね

「PC でも Android 等の共有機能みたいにタイトルをペアにする方式を標準で提供しろ」という方向に行くのが一番健全な気がしますね。 ID の構造や意味を弄るよりは。

うーん……
コメントならそれこそ ID と別に並べて書いてしまえばいいわけで、やっぱり「ブラウザなり何なりが標準でタイトルも付加する」形式の方がストレートに見えるなぁ。
Android の共有機能とかは実際にタイトルと URL の組を受け渡しすることを標準的な手法として実現しているわけで

それって一般的な web サーバの機能として持つべきか……？
そもそも「タイトル」と言ってもタイトルバーに出る文字列と記事そのもののタイトルは違ったりするし、さらに content negotiation によってクライアントごとに言語や表示フォーマットが異なる可能性があるし、そういう諸々の複雑な “人間向け” 要件を ID 内に取り込むのはだいぶ余計な複雑さの導入に見えるけど

タイトルはリソースへのナビゲーションに使われないし、人間もナビゲーションに使われると想定しないので。言ってみれば「変なことになっていてもおかしくない領域」としてちゃんと (いくらか) 安全に分離されている

そもそも URL にオプショナルでタイトルを含めたところでいかなる検査もされないとすれば、最初から信用できないし、むしろ悪意の入り込む余地を残すだけ。
「〒284大阪府-0044」と書かれていたら無頓着な人々が騙されるばかりか、「この記事が書かれたときは 284 は大阪府だったのかなぁ」などと余計な気を回す人まで騙されかねないわけで、どう考えても害のほうが大きい

これも全く同じことを逆から言ってるだけで、「郵便物の配達先を郵便局アプリケーションが識別するためのコード」を人間が地域を察するのに使おうとするのが目的外利用であって、そういう使い方をするやつが全面的に悪い

問題の半分以上は、タイトル+改行+URL のような形でコピーさせてくれないブラウザやアプリの共有機能に責任がある。
ブラウザならアドオンがいくつもあるので改行挟むなり markdown 形式にするなり好き放題できるが。

そもそも URL が「どこであるか」を識別するのは人間の仕事ではない (アプリケーションの仕事である) のだから、人間にどこであるかをわからせる必要があるなら ID と別に書けという話ですね (つまり タイトル+改行+URL とかにすればよろしい)

住所に「消防署の方から来ました」と入ってるようなもんですよ (?)

でも Amazon が ASIN を別物に使いまわしたら？

?foo=bar (query 部) をトラッキングとか流入元指定に使ってるの、特定サービスがそういうのを無視するという仕様を持っているという前提で個別に許されていると考えるべきで、一般化するとまあまあ邪悪だし真似するべきではないです (文字通りトラッキングに使えるし)

?foo=bar みたいなやつは ID 機能の一部と見做されるので # frag みたいなフラグメント指定しかその用途では使えないけど、フラグメントは文書の特定部分を指す用途で使われているので……

Amazon がタイトルを 実効性のない形で URL に含むしぐさやってるけど……あれを望ましいとは思わないです

タイトルを含むことで得られる価値、ID 破壊リスクや一意性喪失リスクや ID と名前のミスマッチリスクを呑み込むには値しない (そりゃ検索エンジンだけを考えるなら canonical をメタデータで指定すれば統合はできるが……ブラウザのブックマークとかはどうする？)

それは徹底してそういう人に全責任を押し付けるべき

それは URL ではなくその外側の仕事だし (つまりタイトル+URL で投げられるべき)、なんなら記事のバージョン管理あたりのトピックかもしれない (それこそ wiki の履歴ビューアとか WebArchive とか)

ワイのﾌﾞﾖｸﾞの id は自前で指定しているのでタイトルの変更を生き延びられる (完全に outdated になる可能性もあるが、そこまで大きく変化したらそもそも別コンテントとも言えるし別の id を振り直すのもあり)

有用なドキュメントを作るために心掛けたいこと - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2018/12/24/creating-useful-document/#stable-permalinks-per-sections

wiki システムとか markdown プロセッサにありがちな、セクション名をナイーブに id や slug にする実装、現実見えてないし全部廃れろと結構強めに思ってる

ドキュメント書くサービス、書いてくに当たってタイトルが変わることは普通にあるからそれならnotionみたいにURLはランダムなIDのほうがいい気がするな

外国人の名前、正しく発音できる自信ないし、それどころか正しく聞き取れる自信がそもそもない

言うて我々も習近平をシーチンピンと呼ばずシューキンペイと呼んでたりしたわけで、差別と呼ぶのは簡単かもしれないが肉体に染み付いた動作特性を無かったことにするのも極端だとは思うんだよな。もちろん何事も程度の問題ではあるだろうが……