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

protocol/ATP/atproto
概要

前回: 記事: 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に似たものを検討していました。が、時間が無くなり、他の方法に目を向けました。

残り4183文字。続きはSilver/Gold会員限定。

Free=0/Bronze=220/Silver=1100/Gold=1980円。

会員登録/ログイン (About Member)

Comments

Ads Blocker Image Powered by Code Help Pro

広告ブロッカー検知/Ads Blocker Detected

このサイトは会費と広告で運営されています。[Bronze=月220円以上に登録] するか、広告ブロッカーを無効にしてください。

This site is operated by membership and advertise. Please [register at least Bronze=220 JPY/month], or disable ads blocker.

Copied title and URL