Prompt 1:
Using https://atproto.com/guides/faq for @base, create an RDF rendition of the following using Turtle Notation, terms from schema.org, and relative hash-based hyperlinks for subject and object denotation. Place output in a single code-block with ## Turtle Start ## and the beginning and ## Turtle End ## at the end.

Prompt 2:
Redo, creating an FAQ Instance graph comprising Questions and related Answers.

FAQ
Frequently Asked Questions about the Authenticated Transfer Protocol (ATP).

Is ATP a blockchain?
No. ATP is a federated protocol. It's not a blockchain nor does it use a blockchain.

Why not use ActivityPub?
ActivityPub is a federated social networking technology popularized by Mastodon.

Account portability is the major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements. Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.

Other smaller differences include: a different viewpoint about how schemas should be handled, a preference for domain usernames over AP’s double-@ email usernames, and the goal of having large scale search and discovery (rather than the hashtag style of discovery that ActivityPub favors).

Response 1:
## Turtle Start ##
@prefix schema: <http://schema.org/> .

<#faq>
    a schema:FAQ;
    schema:name "Frequently Asked Questions about the Authenticated Transfer Protocol (ATP).";
    schema:mainEntity [
        a schema:Question;
        schema:acceptedAnswer [
            a schema:Answer;
            schema:text "No. ATP is a federated protocol. It's not a blockchain nor does it use a blockchain."
        ];
        schema:question "Is ATP a blockchain?";
    ];
    schema:mainEntity [
        a schema:Question;
        schema:acceptedAnswer [
            a schema:Answer;
            schema:text "Account portability is the major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements. Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data. Other smaller differences include: a different viewpoint about how schemas should be handled, a preference for domain usernames over AP’s double-@ email usernames, and the goal of having large scale search and discovery (rather than the hashtag style of discovery that ActivityPub favors)."
        ];
        schema:question "Why not use ActivityPub?";
    ];
.
## Turtle End ##

Prompt 2:

Repeat for:
Why create Lexicon instead of using JSON-LD or RDF?
ATP exchanges data and RPC commands across organizations. For the data and RPC to be useful, the software needs to correctly handle schemas created by separate teams. This is the purpose of Lexicon.

We want engineers to feel comfortable using and creating new schemas, and we want developers to enjoy the DX of the system. Lexicon helps us produce strongly typed APIs which are extremely familiar to developers and which provides a variety of runtime correctness checks (which are vital in distributed systems).

RDF is intended for extremely general cases in which the systems share very little infrastructure. It’s conceptually elegant but difficult to use, often adding a lot of syntax which devs don't understand. JSON-LD simplifies the task of consuming RDF vocabularies, but it does so by hiding the underlying concepts, not by making RDF more legible.

We looked very closely at using RDF but just didn't love the DX or the tooling it offered.


Response 2:
## Turtle Start ##
@prefix schema: <http://schema.org/> .

<#faq>
    a schema:FAQ;
    schema:name "Frequently Asked Questions about the Authenticated Transfer Protocol (ATP).";
    schema:mainEntity [
        a schema:Question;
        schema:acceptedAnswer [
            a schema:Answer;
            schema:text "ATP exchanges data and RPC commands across organizations. For the data and RPC to be useful, the software needs to correctly handle schemas created by separate teams. This is the purpose of Lexicon. We want engineers to feel comfortable using and creating new schemas, and we want developers to enjoy the DX of the system. Lexicon helps us produce strongly typed APIs which are extremely familiar to developers and which provides a variety of runtime correctness checks (which are vital in distributed systems). RDF is intended for extremely general cases in which the systems share very little infrastructure. It’s conceptually elegant but difficult to use, often adding a lot of syntax which devs don't understand. JSON-LD simplifies the task of consuming RDF vocabularies, but it does so by hiding the underlying concepts, not by making RDF more legible. We looked very closely at using RDF but just didn't love the DX or the tooling it offered."
        ];
        schema:question "Why create Lexicon instead of using JSON-LD or RDF?";
    ];
.
## Turtle End ##


Prompt 3:

Repeat for:
What is “XRPC,” and why not use ___?
XRPC is HTTP with some added conventions.

XRPC uses Lexicon to describe HTTP calls and maps them to /xrpc/{methodId}. For example, this API call:

await api.com.atproto.repo.listRecords({
  user: 'alice.com',
  collection: 'app.bsky.feed.post'
})
Maps to

GET /xrpc/com.atproto.repo.listRecords
  ?user=alice.com
  &collection=app.bsky.feed.post
Lexicon establishes a shared method id (com.atproto.repo.listRecords) and the expected query params, input body, and output body. By using Lexicon we get runtime checks on the inputs and outputs of the call, and can generate typed code like the API call example above.

Response:
## Turtle Start ##
@prefix schema: <http://schema.org/> .

<#faq>
    a schema:FAQ;
    schema:name "Frequently Asked Questions about the Authenticated Transfer Protocol (ATP).";
    schema:mainEntity [
        a schema:Question;
        schema:acceptedAnswer [
            a schema:Answer;
            schema:text "XRPC is HTTP with some added conventions. XRPC uses Lexicon to describe HTTP calls and maps them to /xrpc/{methodId}. For example, this API call: await api.com.atproto.repo.listRecords({user: 'alice.com', collection: 'app.bsky.feed.post'}) maps to GET /xrpc/com.atproto.repo.listRecords?user=alice.com&collection=app.bsky.feed.post. Lexicon establishes a shared method id (com.atproto.repo.listRecords) and the expected query params, input body, and output body. By using Lexicon we get runtime checks on the inputs and outputs of the call, and can generate typed code like the API call example above.";
        ];
        schema:question "What is “XRPC,” and why not use ___?";
    ];
.
## Turtle End ##