記事: ATP/BlueskyでRDFを使わない理由とLexicon誕生秘話

概要

前回: 記事: ATP/BlueskyがMarkdownではなくRichTextを採用した理由 | GNU social JP Web。

前回に続くPaul FrazeeによるATPの技術選択の説明記事の紹介です。時系列としては、「記事: ATP/BlueskyがP2Pではない理由 | GNU social JP Web」の前です。

2024-01-18の「Why not RDF in the AT Protocol? | Paul’s Dev Notes」が元記事です。

問題提起としてサーバーと通信する際のJSONデータの一部を見た際に、それがマイクロブログの投稿だと判別不能です。従来のアプリの場合、例えば/api/getPostのサーバードキュメントで文書化されています。しかし、複数ベンダーになると、APIが異なるため判別不能です。

RDF

一般的な対応方法として、RDFがあります。ActivityPubやDIDなどで採用されています。

// the output of pfrazee.com
{
  name: "Paul Frazee",
  job: "Programmer"
}

RDFでは上記のJSONデータがあった場合、グローバル識別子を追加して、例えば schemas.com/name schemas.com/jobのように、完全なURIが提供されて曖昧さが解決されます。

ただし、フィールドごとに定義が必要になります。それに、RDFは開発体験が劣悪で有名です。というのも、データモデル内でURIが頻繁に使用されるため、コードが乱雑に見えます。

検討

RDFの問題解決のため、いろいろ検討しました。当初、RDFの機能の一部を削除したTurtleやJSON-LDに似たものを検討していました。が、時間が無くなり、他の方法に目を向けました。

gnusocialjp

詳細プロフィール。SNS: X Twitter/GS=gnusocialjp@gnusocial.jp/WP=gnusocialjp@web.gnusocial.jp。2022-07-17からgnusocial.jpとweb.gnusocial.jpのサイトを運営しています。WordPressで分散SNSに参加しています。このアカウントの投稿に返信すると、サイトのコメント欄にも反映されます。