JSON-LDにおいて`{"@id": "subject", "predicate": "object"}`と`{"@id": "object", "reversePredicate": "subject"}`（ただし`{"reversePredicate": {"@reverse": "predicate"}}`とする）は意味論的に等価で、だからといって普通は`subject`の参照外しに対して後者の表現を返すようなことはないわけだけど、この気持ちをもう少し規格として良い感じに定式化できないものだろうか
例えばActivity Streamsはcompacted formのみを使うように求めているけど、それだけでは後者の表現を妨げるものではない
ActivityPub の文脈では「データを JSON-LD データとして解釈して JSON-LD プロセッサで処理することもできますよ」とは言っているけど、意味論的に等価なあらゆる表現が ActivityPub 的に解釈可能として許容されていると言ってるわけではない気が (もう忘れた)
ActivityPub
https://www.w3.org/TR/activitypub/#Overview
> If you know what JSON-LD is, you can take advantage of the cool linked data approaches provided by JSON-LD. If you don't, don't worry, JSON-LD documents and ActivityStreams can be understood as plain old simple JSON. (If you're going to add extensions, that's the point at which JSON-LD really helps you out).
まあ実際拡張なしでやれるんかというと、それは些か現実の状況に合っていないのではと思うところはあるが……
まあ`@graph`や`@included`などのplain JSON consumerによる解釈を想定していなそうな仕組みを除けば、データセットを木でなく一般の有向グラフにしてしまうようなアノマリーは`@reverse`の他に存在しない気がするし（実際どうなのかは知らぬ）、これについては拡張でも使わないものとすれば済む話ではありそうか
JSON-LDのキーワードを入力するときにメンションになってしまわないか身構えがち
実際、JSON-LD関係のGitHubのissueなどでは日常的に@context氏にメンションが飛んでいるので（？）
まあ一般的なURIについてはサーバ実装が良い感じに常識的な振る舞いをすることに期待して良いだろうけど、<actor#main-key>のようなフラグメント付きのURIが絡んでくると現実にレスポンスのトップレベルの`@id`が元のURIと異なるものにならざるを得なくて、この扱いが非自明という話がある：
Guidance on fragments in ids · Issue #367 · w3c/activitypub
https://github.com/w3c/activitypub
JSON-LDはRDFであると同時にRDFとは無関係に単なるJSONとして解釈することが想定されているから意味論に加えてJSONとしての具体的な構文についても配慮する必要があって、この性質が議論がややこしくしているみたいなところがある気がする（自分が勝手にややこしく考えているだけなのでは）
意味論だけを考えれば済むなら机上の議論は簡単になるけど、実運用として意味論的に等価な複数の表現を受け容れることを実装に要求する方が面倒だろうし、まあ、はい
個人的にどこに気持ち悪さを感じているのかというと、結局現実的には実質的に特定の構文に従うことが要求されている一方で規格側の構文に関する詰め方が中途半端なところなのかも知れない。例えばActivity Vocabularyにおける単一要素のみからなる`items`の扱い（<https://github.com/w3c/activitystreams/issues/535>）とか
ある程度は常識的に判断するべきとは言っても、その「常識」で済まされている範囲が広すぎやしないかというか何というか
