Skip to content

Note

このドキュメントは2026-02-27 02:38にPLaMo Translation Modelを使用して自動翻訳されました。

FEP-e229: 拡張性に関するベストプラクティス

概要

現在広く利用されているActivityPubの実装では、拡張性への対応が不十分なケースが多く見られます。本FEP（機能提案）は、拡張性を実現するための基本的な要件を明確にするとともに、特にLD（JSON-LD）非対応の消費者との互換性問題を回避したい開発者向けに、推奨される実装方法を提示することを目的としています。

一般的な推奨事項

LD非対応の消費者向け

タイプを型セットとして正規化する

[AS2-Core]または[AP]におけるオブジェクトは単一のタイプしか持たないという誤解は、残念ながら誤りです。この考え方は適切な拡張性を阻害します。汎用的なActivityStreams消費者が、[AS2-Vocab]で定義されたタイプと[AS2-Core]のメカニズム（コレクションなど）のどちらを扱っているかを判定する必要がある場合、その型がtypeセットに含まれていなければ判断できません。ただし、拡張語彙では追加のタイプをインターフェースとして宣言し、対象オブジェクトがその要件を満たしていることを明示する必要があります。このため、LD非対応消費者が行う型チェックでは、type値を必ず集合に変換し、その中に必要な型が含まれていることを確認するよう注意してください。

例えば "type": "Collection" という記述は、"type": ["Collection"] のように正規化する必要があります。

JSON-LDコンテキストを理解していない場合は無視する

LD非対応消費者はJSON-LDコンテキスト宣言に対して単純な文字列比較を行ってはいけません。受信したドキュメントが有効なAS2形式であっても@contextを宣言していない場合、いくつかの可能性が考えられます。一つはそのコンテンツタイプが application/activity+json であり、プロデューサー側がLD非対応であるケースです。もう一つはプロデューサー側がLD対応しているものの、同じ用語を定義する異なるコンテキストIRIを使用している場合です。さらに別の可能性として、プロデューサー側がインラインで用語定義を埋め込んでいる場合もあります。いずれの理由であれ、消費者側がその仕様を理解しているかいないかのどちらかです。

LD対応の消費者向け

AS2コンテキストが提供されていない場合はAS2コンテキストを想定する

[AS2-Context]を含めることは必須ではなく推奨事項に過ぎないため、一部のLD非対応プロデューサーは@context宣言なしでドキュメントをシリアライズすることがあります。コンテンツタイプが application/activity+json の場合、[AS2-Core]セクション2.1に従い、文書内に[AS2-Context]を必ず含めるか注入する必要があります。

LD非対応の生産者向け

共有されることが想定される用語にはIRIを明示的に宣言する

デフォルトでは、[AS2-Context]ドキュメントでは@vocabが_:に設定されており、これはデフォルト語彙ネームスペースがブランクネームスペースであることを意味します。拡張タイプやプロパティは、LD非対応プロデューサーでもそのまま実装可能であり、JSON-LD展開アルゴリズムによってtermは_:termに変換されます。JSON-LD圧縮処理でこれらのプロパティは削除されませんが、@vocab: _:宣言がない場合、これらは除去されてしまいます。これは実験的な用語や他の消費者が使用しないことが想定される場合には許容できるかもしれませんが、拡張性の観点からは好ましくありません。ブランクネームスペースをプロパティに使用する手法は時代遅れであり、将来のJSON-LD仕様では廃止される可能性があります。

LD対応の生産者向け

不必要な用語プレフィックスの使用を避ける

コンパクトなIRIプレフィックスは、プロデューサーが使用するコンテキストによって、複数の用語が同じプレフィックスにマッピングされることがあります。例えば、http://example.com/というプレフィックスがある場合、example:termを含むドキュメントもあれば、ex:termやhttp://example.com/termを含むドキュメントも存在する可能性があります。LD対応消費者であれば、JSON-LD展開を適用してすべての用語を明確にした後、ローカルで優先するコンテキストに対してJSON-LD圧縮を行うことができます。一方、LD非対応消費者は無限に存在し得る同等の用語を扱う必要があり、ケースバイケースで対応するか、あるいは独自にJSON-LD展開を実装しなければなりません。この問題は、既存の標準的なプレフィックスを再利用することで緩和可能です。その一例が[RDFa-Context]の「初期コンテキスト」です。

追加のコンテキストに対してAS2コンテキスト文書のみを圧縮対象とするドキュメント生成を検討する

JSON-LD展開形式は曖昧性がないため、可能な限りこれを使用することが望ましい場合があります。これにより人間による可読性が若干低下するものの、拡張データの表現方法を一意に決定できます。LD非対応消費者は、JSON-LD展開形式の構造を理解する必要が生じるかもしれません。一方、LD対応消費者であれば、追加で理解可能なコンテキストに対して文書を再圧縮するだけで済みます。

例えば、[FEP-fb2a]「Actorメタデータ」が導入される前の現在の「プロフィールフィールド」の使用方法を考えてみましょう。Mastodonが誤った定義のためにscを用語プレフィックスとして使用していることを無視すれば、部分的に展開されたJSON-LDを使用することで、このようなプレフィックスは不要になります：

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "https://example.com/~alyssa",
    "type": "Person",
    "name": "Alyssa P. Hacker",
    "attachment": [
        {
            "type": "http://schema.org/PropertyValue",
            "http://schema.org/name": "Pronouns",
            "http://schema.org/value": "she/her"
        }
    ]
}

一般的に、対象とする消費者が宣言するコンテキストを理解できるかどうかを考慮することが重要です。ActivityStreams専用の消費者の場合、[AS2-Context]は必須要件であるため、これを前提とすることができます。一部の仕様（例えば[WebAnnotations]）では独自のコンテキスト宣言が必須とされている場合もありますが、そうでないケースもあります。一般的には、コンテキストの強制を避け、部分的に展開された形式のみを使用することが推奨されます。これは複数のコンテキスト宣言が存在すると、それらが競合する可能性があり、最後に宣言されたコンテキストが優先されるため、予期せぬ動作を引き起こす可能性があるためです。このような問題は、コンテキスト宣言をより慎重に行い、どのコンテキスト文書を圧縮対象とするかを選択することで回避可能です。

追加のコンテキストに対して圧縮を行う場合、AS2コンテキスト文書は最後に登録する

[AP]および[AS2-Core]では[AS2-Context]に対する圧縮が義務付けられている一方で、用語の上書きを禁止しているため、[AS2-Context]は最も新しく宣言されるコンテキストとすることが最適です。例えば：

{
    "@context": [,
        "https://schema.org",
        "https://www.w3.org/ns/activitystreams"
    ],
    // ...
}

拡張定義の方法

LD非対応プロデューサーは、JSON-LDがどのように機能するかについて少なくとも基本的な理解が必要です。そうしないと、拡張機能がブランクネームスペースに配置され、将来のJSON-LD仕様で削除される可能性があります。上記のLD非対応生産者向け推奨事項を参照してください。

拡張プロパティ

拡張プロパティは主に以下の2種類に分類されます：

  • 値がリテラル値であるもの。この場合、展開前形式では@valueを使用します。
  • グラフ上のノードとして表現される値を持つもの。展開前形式では@idを使用します。

LD非対応プロデューサーの場合、以下のような形式のJSONを生成すれば十分です：

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "http://example.com/valueProperty": "文字列または数値またはブール値",
    "http://example.com/idProperty": {
        "@id": "https://example.com/some-resource"
    }
}

LD対応プロデューサーの場合、まず上記のLD対応生産者向けガイダンスで説明されているように、追加コンテキストに対して圧縮を行うと、LD非対応消費者による解析が困難になることに注意してください。宣言する任意のコンテキストは消費者と共有される必要があり、保証されるのはActivityStreamsコンテキストのみです。それでも、LD対応消費者のために、別途ダウンロード可能なコンテキスト文書を用意することが望ましいです。そのための一つの方法が[FEP-888d]で説明されています。

拡張用語定義に関する参考資料

著作権

CC0 1.0 Universal（パブリックドメイン献呈）

法律で認められる範囲において、このFediverse Enhancement Proposalの著者らは、本著作物に関するすべての著作権および関連する権利を放棄しています。