orange @[email protected]

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

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

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

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

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 は大阪府だったのかなぁ」などと余計な気を回す人まで騙されかねないわけで、どう考えても害のほうが大きい