Ipfs: IPFS-LD-リンクトデータ

ねえ@jbenet 、IPFSで素晴らしい仕事をしました。インターネット上の名前を置き換えるために、DHT（Kademliaのような）+デジタル署名+クエリネットワークを使用することを検討しているので、あなたが何をしているかに非常に興味があります（最終的にDNSを置き換えます）。 私たちが行っている基本的な作業は、IPFSを使用して行っている作業に近いものです： https ：//manu.sporny.org/2014/identity-credentials/。 そのイニシアチブにJSON-LDを使用していますが、Telehashをご存知ですか？ そうでない場合は、これらの概念のいくつかがIPFSを強化する可能性があるため、確認する必要があります。

いずれにせよ、ネットワーク上のメタデータを機械可読で処理可能にしたいが、拡張可能な方法にしたい場合は、JSON-LDを使用する必要があります。 JSON-LDを使用している場合は、W3Cで行われているWeb支払いとクレデンシャルの作業を統合できる可能性が高くなります。これらの作業セットも両方ともJSON-LDの上に構築されているためです。 JSON-LDの主な利点の1つは、異なるソースからのデータをマージできることです。 もう1つは、基本的なデータ形式を指定して、ユーザーが自分と調整せずにプロトコルを拡張できるようにすることです（これは、システムを指数関数的に成長させる場合に重要です）。

ちょっと考えてみてください。ご不明な点がございましたら、お問い合わせください。 ネットワーク上の各JSONBLOBで@contextを要求することは、大きな要件ではありません。

考えてくれてありがとう！

DHT（Kademliaのような）+デジタル署名+クエリネットワークを使用して、インターネット上の名前を置き換えることを検討しています（最終的にDNSを置き換えます）。

次に、ペーパーのIPNSセクションを確認してください： http ：//static.benet.ai/t/ipfs.pdf（3.7）。 :)

Telehashを知っていますか？

はい、私は一般的なコンセプトとそれを構築するための意欲を非常に承認していますが、プロジェクトの決定の多くには賛成していません。 適切な例として、タグラインは「JSON + UDP + DHT = Freedom」ですが、これらの種類のシステムは、（a）データ形式を強制しない、（b）トランスポートプロトコルを強制しない、（c）ルーティングシステム。 もちろん、これら3つは_今日_優れた選択肢ですが、これらのプロトコルは、レイヤー間および時間全体に適合するように構築する必要があります。 したがって、IPFSを使用すると、ユーザーは任意の形式を使用でき、IPFSは任意のトランスポートの上に重ねることができ、最初のルーティングシステムはDHTになりますが、他にも検討する必要があります。

IPFSは、Telehash +（merkle）Webとして見ることができます。

ネットワーク上のメタデータを機械可読で処理可能にしたいが、拡張可能な方法にしたい場合は、JSON-LDを使用する必要があります。

トランスポートとしてJSONを必要とせずに、作業の-LD部分を取得できると思います。 つまり、あなたの（素晴らしい）作業は、どのツリーデータ構造にも一般化でき、他のセマンティックWeb形式よりもはるかに優れていると思います。 （驚くほどシンプルで柔軟性があります！）したがって、これらのメモで指摘しているのは、 @contextと同等のものを使用することですが、IPFSリンクデータ構造（JSONではないため、オブジェクトをすばやく検索するためのバイナリパック形式です） --protobufは今日ですが、後で自己記述することもできます--IPFSは、データベースとして機能するのに十分な速度であると考えています。現在ではなく、将来的に:)）。

ネットワーク上の各JSONBLOBに@contextを要求することは、大きな要件ではありません。

うん、私は同じことを主張しました:)

@jbenet re： https ://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309-ええ、あなたの議論は非常によく、十分な情報に基づいていると思いました。

私はあなたがしていることに本当に興味があります、私は紙をすくい取ってあなたのビデオを見始めました。 残念ながら、今日は締め切りがありますが、あなたの論文を読んで、私のやることリストにあるビデオ全体を見ています。 あなたがこれを知っているかどうかはわかりませんが、私はW3Cを介してWebの標準を構築することに取り組んでいます。 現在、概説しているものと同様の解決策を必要とする一連の問題があります。 あなたの仕事の一部を、私たちがWeb用に取り組んでいる次世代のW3C標準ログインソリューションに統合できるかどうかを確認したいと思います（上記で触れた投稿）。 現在Telehashを使用していますが、いくつかの懸念があり、ユースケースにより適した方法で問題を分解したようです。

いずれにせよ、私はあなたが作成したものに取り掛かり、それからあなたに戻ってきます。 1週間以内に連絡がない場合は、もう一度pingしてください。

ねえ@jbenet 、私は週末にホワイトペーパーをより詳細に調べ、あなたのプレゼンテーションを見る機会がありました。 今週は話をする時間を設定しましょう。 私は米国東海岸にいます。 火/水を除くほとんどの日、午前10時から午後2時までご利用いただけます。 私の電子メール： [email protected] 、Skype：msporny、SIP： sip：[email protected]できるだけ早く私と連絡を取ってください。

ipnsとこのwrtについて説明したいと思います。 Web、クレデンシャル、およびWeb支払いにログインします： https ：//manu.sporny.org/2014/identity-credentials/

@msporny素晴らしい！ しましょう。 タッチベースに今すぐメールを送信しました。 この問題から連絡先の詳細を削除することをお勧めします（公開されているなど）。

今日は、IRCで「これはどのようなオブジェクトですか」という質問に答える方法を検討していました。 @jbenetはLSON-LDスタイルの@typeまたは@contextリンクについて言及しましたが、そのチェーンからどのように抜け出すかはわかりません。 @contextリンクはずっと下にありますか？ @ tv42は、ディレクトリノードが子セグメント名をキーとして使用するため、ファイル名との衝突についても懸念を表明しました。 セグメント名の前に付けるかエスケープすることでこれを回避できますが、タイプの説明のハッシュIDを保持するための明示的なタイプフィールドを追加するよりも作業が多いようです。 この種のことをもっと期待するのであれば、リンクを内部セットと外部セットに分割する必要があるかもしれません。 @jbenetが提案したLinkprotobuf拡張アプローチ（それが問題になる場合）では、「内部」ブール値を追加して@contextタイプのエントリを任意の@contextファイルエントリから分離することでこれを行うことができます（例えば）。

申し訳ありませんが、この時点では形式は（ほぼ確実に）変更されていません。 私はそれをこれまで煮詰めて何ヶ月も費やし、その上で再び水門を開くつもりはありませんでした。 残りの質問（リンク拡張機能など）は以前から知られており、正しい方法を見つけるだけです。

ipfsオブジェクトは、jsonなどのツリーです。 これは、JSONで利用可能なすべてのソリューション（JSON-LD、JSONスキーマなどを含む）がIPFSで利用できることを意味します。 さらに、RDFトリプルをipfsオブジェクトとして表すのは簡単です。 したがって、あなたは何でも何でもすることができます。

実際のデータは非常に乱雑です。 世界の誰も人々に特定のデータタイピングシステムを採用させることに成功していません-そして私はそれらの議論に時間を費やすつもりはありません。 私が長期的に実行可能だと思う唯一の解決策は、人々がやりたいことを何でもできるようにシステムを十分に柔軟にし、すべてが相互に関連するように十分に堅固にすることです。

さて、_preferred_の方法（人々に何かをするように提案する方法）は、（驚くほど強力でシンプルな）JSON-LDの@context / @typeになる可能性があります。

しかし、あなたがその連鎖からどのように抜け出すのかはわかりません

質問がわかりません。 チェーンはありません。コンテキストを一度解決すれば、それだけです。 これがオブジェクトのコンテキストファイルです。 有効なコンテキストではない場合（仕様があります）、無視します。 アプリケーションは、これらのタイプが正しいことに_依存_するのではなく、正しい場合にそれらを活用する必要があります。

@ tv42は、ディレクトリノードが子セグメント名をキーとして使用するため、ファイル名との衝突についても懸念を表明しました。

dirデータ構造にすでに@contextがある場合、別のファイルを作成することはできません-（または、最悪の場合、（安定ソート）の後にリンクを追加します）。 同じ名前の2つのファイルを作成しようとするのと同じです。

2015年5月1日金曜日03:51:22AM-0700に、JuanBatiz-Benetは次のように書いています。

申し訳ありませんが、この時点ではフォーマットは（ほとんどの場合）変更されていません。 私
これまで沸騰させて洪水を開かないようにするために何ヶ月も費やしました
再びその上にゲート。 残りの質問（リンク拡張など）
しばらく前から知られていて、正しい方法を見つけているだけです
それ。

リンク拡張機能は正常に機能するはずです。 そして、リンクキーの前に
名前空間もそれほど悪くはありません。 タイプ情報の詰め込み
into Dataも機能します（これがファイルとディレクトリの機能です
[1,2,3,4,5]）。 タイプを列挙することは持続可能なアプローチではありませんが、
これらの場所はいずれも、型ハッシュを格納する場所として機能します。

さて、_preferred_方法-人々に何かをするように提案する方法
-からの@context / @typeになる可能性があります
（驚くほど強力でシンプル）JSON-LD。

JSON-LDは問題ありませんが、その周囲のエコシステムを理解する必要があります
@プレフィックスは特別です。 特殊性を保存したい
リンクエントリを追加データで明示的に拡張する（例：
内部/外部フラグ）、@context間にあいまいさがないようにします
ファイルと@contextタイプのリンク。 ただし、すべてのファイル/サブディレクトリリンクにキーが設定されている場合
と'子/'、次にタイプの'コンテキスト'を持つことができます
ファイル（またはその他）のリンクと「子/コンテキスト」。 それはまだ起こっています
オブジェクトジェネレーターが外部で定義された規則である必要があります
そして消費者は、自己記述的でないチャネルを通じて同意する必要があります。

しかし、あなたがその連鎖からどのように抜け出すのかはわかりません

質問がわかりません。 チェーンはありません、あなたは解決します
コンテキストを1回実行すると、それだけです。 これがのコンテキストファイルです
物体。 それが有効なコンテキストではない場合-仕様があります-あなた
それを無視します。

それは私にとってはうまくいきます。 どうやって自己記述を終わらせるのかしら
鎖：

Aとは何ですか？ A / @contextをBまでたどってみましょう。Bとはどのタイプですか？
B/ @contextをCまでたどってみましょう…

しかし、B仕様（私の例ではC）を配布している場合、
B/ @contextリンクの必要性。 しかし、あなたがのためのチャネルを持っているなら
タイプスペック（C）を配布し、配布にも使用してみませんか
タイプスキーマ自体（B）？ ただ持っている方がいいようです
それらを説明するマルチハッシュを保持するオブジェクト内の従来の場所
タイプ（ @contextリンクなど）。 次に、邪魔にならないようにして
それが
タイプ定義への参照（おそらく仕様C、Cv2、または
代替CCv1.3、または…）またはマルチハッシュを次のように使用したい場合
不透明な識別子。 その後、次のようなことができます。

スイッチpbn.GetType（）{
ケースft.TDirectory：
root.val = NewDirectory（pointsTo.String（）、mnode、root、fs）

GetTypeが@contextリンクハッシュ（または
どこでも）、TDirectoryはマルチハッシュになります
（QmWellKnownDirectoryType）。

アプリケーションは、これらのタイプが正しいことに_依存_するべきではありませんが、
むしろ、それらが存在するときにそれらを活用します。

これは不透明な識別子のように聞こえます。 たぶん私たちは同じことを言っています
もの ;）。

@ tv42は、ファイル名との衝突についても懸念を表明しました。
ディレクトリノードは、子セグメント名をキーとして使用します。

dirデータ構造にすでに@contextがある場合、それは許可されません
別のファイルの作成-（または最悪の場合、後にリンクを追加します
（安定ソート））。 これは、を使用して2つのファイルを作成しようとするのと同じです。
同名。

@contextファイルを違法にしたい場合です;）。 あなたがしたい場合は
人々が@contextファイルを作成できるようにするには、いくつかの方法が必要になります
「このリンクはタイプを指している」と「このリンク」のあいまいさを解消します
ファイル/サブディレクトリ/…を指します。」 しかし、いくつかの方法があります
その問題の周りで、私たちがそれらの1つを選ぶ限り、私は幸せになります
;）。

数日前に@cryptixと会話し、JSON-LDの使用について簡単に話しました。 json-ldの仕様では、「リンク」を使用してjsonからjson-ldへのマッピングを記述できることを指摘しておきます。 私は個人的にこのアプローチを好みます。これにより、メタデータをjson-ldに準拠させることができ、RDFの現在の「ヒップ」なフレーバーに合わせてメタデータを再構築する必要がなくなります。

http://www.w3.org/TR/json-ld/#interpreting -json-as-json-ld

2015年5月1日金曜日09:24:27PM-0700に、W。TrevorKingは次のように書いています。

リンク拡張機能は正常に機能するはずです。 そして、リンクキーの前に
名前空間もそれほど悪くはありません。 タイプ情報の詰め込み
into Dataも機能します（これがファイルとディレクトリの機能です
[1,2,3,4,5]）。 タイプを列挙することは持続可能なアプローチではありませんが、
これらの場所はいずれも、型ハッシュを格納する場所として機能します。

関連する注記（ハッシュされたタイプIDを
ペイロード）、 @tv42はちょうど私の注意をEthosETypes[1,2,3]にもたらしました。 それで
私はこれらのもののためのある種の明示的なスロットを持つことは
すごい。

ETypesを見たことがない、浮上してくれてありがとう。 次の数日で読みます。 関連するものは、キャスリーンフィッシャーのPADS作業+関連です。 PADSプロジェクトページは最近変更されたようです（コンテンツアドレスの不変のWebストアがあった場合のみ...）。 （しかし、インターネットアーカイブは私たちを再び救いました\ o /：http://web.archive.org/web/20130125041549/http://www.padsproj.org/）

• PADS：アドホックデータを処理するためのドメイン固有言語
• PADSプロジェクト：概要
• PADS / T：アドホックデータを記述および変換するための言語
• PADS / ML：機能データ記述言語
• LearnPADS：アドホックデータからの自動ツール生成
• その他の論文：http： //web.archive.org/web/20120205185831/http ：// www.padsproj.org/doc.html#papers

とにかく、PADSは非常に正しい考えを持っています。 しかし、これまでのところ、私が知っているように、幅広い実装は見られていません。 おそらく、ここでそれを修正できるJSON-LDのスタイルの何かがあります。

JSON-LDは、 @contextリンクを追加するだけではありません。 特に、各リンク名（JSONのキー）は、次のいずれかのカテゴリに分類される必要があります。

• @context ：データを説明するコンテキストリンクまたはインラインノード
• @id ：現在のノードのURI
• スキーム：// full-uri ：述語がURIであるリンクとして認識されます
• prefix：name ：述語がプレフィックスURI（コンテキストで定義されている）と名前の連結であるリンクとして認識されます
• 名前：コンテキストで定義されている場合にのみリンクとして認識されます

特に、JSON-LDは任意のキー/値マップをサポートしていないようです。 キーがURIとして解釈できる場合、このURIを使用する述語と見なされます。 たとえば、以下は無効です。

{
  "http://xmlns.com/foaf/0.1/name": "<!DOCTYPE html><html><body><p>Hello World</p></body></html>"
}

http://xmlns.com/foaf/0.1/nameは、キャッシュされたバージョンのWebページではなく、常にFOAF名を参照するためです。

これは必ずしも問題ではありませんが、オブジェクト形式を設計するときにリンクをリンクトデータとして解釈する場合は考慮する必要があります。 たとえば、JSON-LDを使用してディレクトリを次のように表すことができます。

{
  "@context": {
    "entry": {
      "@id": "http://schema/unixfs#entry",
      "name": "http://schema/unixfs#filename",
      "content": {
        "@id": "http://schema/unixfs#filename",
        "@type": "@id"
      }
    }
  },
  "entry": [
    {
      "name": "README.md"
      "content": "/ipfs/<hash-of-README.md>"
    }
  ]
}

IPFS-LDでは、ディレクトリのノードがあり、コンテキストと各エントリのノードにリンクしています。 各エントリには、独自のコンテキストへのリンク、名前を含むノード、およびファイルコンテンツを含むノードがあります。

これにより、複数レベルの間接参照が追加されます。これは、JSONドキュメントでは受け入れられますが（すべてが1つのファイルにパックされるため）、各ノードに異なるハッシュがあり、個別に追跡する必要があるIPFSでは受け入れられない場合があります。

おそらく、私たちが望んでいるのは、JSON-LDをそのまま使用するのではなく、JSON-LDから着想を得た独自のコンテキスト形式を定義することです。 これは、フォーマットがJSONではなく、非常に具体的であるため、より適切です。任意のキーマップ（unixfsの場合）を記述できるようにし、IPFSオブジェクトのデータセクションも使用したい（JSONにはありません）。 ）。

IPFSオブジェクトのリンクセクションは非常に制限されているため、リンクには名前があり、別のオブジェクトを指します。 リテラル値を含めることはできません。 コンテキストで指定する必要があるのは、URI形式のリンクの完全修飾名です。 データセクションもあるので、そこに何が含まれるかを定義する必要があります。

unixfsの場合、次のオブジェクトを想像します。

• directory ：
  
  
  
  • ディレクトリコンテキストを指すリンク@context
  
  
  • README.mdオブジェクトを指すリンクentry:README.md
  
  
  • データなし
  
  
• README.md ：
  
  
  
  • ファイルコンテキストを指すリンク@context
  
  
  • README.mdの内容を含むデータセクション
  
  
• ディレクトリコンテキスト：

`` `
{{
// @type ：IPFSオブジェクトのタイプ
"@type"： " http：// schema / unixfs＃Directory "

// entry: declares the links starting with "entry:"
//   <strong i="38">@id</strong>: the relationship with the pointed object
//   <strong i="39">@key</strong>: the relationship with the link name suffix (after ':')
"entry": {
  "@id": "http://schema/unixfs#containsEntry",
  "@key": "http://schema/unixfs#hasFilename"
}

}
`` `

• ファイルコンテキスト：

`` `
{{
"@type"： " http：// schema / unixfs＃File "

// <strong i="50">@data</strong>: the relationship with the data section of the object
"@data": "http://schema/unixfs#content"

}
`` `

これをトリプルで表現したい場合は、次のようになります。

# Contained in directory object:
<hash of directory>        <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema/unixfs#Directory>
<hash of directory>        <http://schema/unixfs#containsEntry>              <hash of README.md object>
<hash of README.md object> <http://schema/unixfs#hasFilename>                "README.md"

# Contained in README.md object:
<hash of README.md object> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema/unixfs#File>
<hash of README.md object> <http://schema/unixfs#content>                    DATA SECTION of README.md

ねえ@mildred-素晴らしい分析。 おかしなことに、 irc：//irc.frennode.org#json -ldのdlongleyとの会話で同じ結論に達しました（興味があればログを送信できます）

私はここでもっと寛容なIPLDタイプのものを少し実験してきました-特に例を見てください。 これらは最終的なものではありませんが（または正しいですか？）、方向性を示します

• https://github.com/ipfs/go-ipld
• https://github.com/ipfs/go-ipld/issues/1
• https://github.com/ipfs/go-ipld/blob/master/ipld.go#L57 -L89
• https://github.com/ipfs/go-ipld/blob/master/examples/commit/commit.go#L10 -L15（ @valueの使用は無視してください、正しくありません）
• https://github.com/ipfs/go-ipld/blob/master/examples/sig/sig.go#L14 -L16
• https://github.com/ipfs/go-ipld/blob/master/examples/unixfs/unixfs.go#L16 -L18

重要な注意事項：

• 他の値を含めることを_許可_するためのリラックスしたリンク（多くのリクエストがあります）、 {"@type": "mlink", "hash": "<multihash>"}のみを予約します
• ユーザーはデータ構造のコンテキストを定義できます
• パス表記を使用してリンクを_ネスト_できます（例： https ：//github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141）

あなたと私は非常に正しい方向に進んでいると思います。 また、JSON-LDから大きく逸脱することなく、これを多く行うことができると思います。 いくつかの制限を削除するだけです

@mildredログはこちら

また、dlongleyとの会話から、JSON-LD標準から技術的に逸脱することなく、必要なことを実行できるはずです。_変換（圧縮/拡張）を呼び出す_は、すべての「非-context-defined」キー。 （逸脱しないように努力する必要があります）

JSONの変換でjson-ld.jsパーサーが行うことではなく、生成されたトリプルの観点からJSON-LDを考えることで、多くの混乱を取り除くことができると思います。 JSON変換ステップはそのパーサーに固有であり、問​​題なく別の方法で簡単に変換することを想像できます。

さて、あなたがgo-ipldで何をしているのかよく理解していれば、現在のIPFSオブジェクトのリンクセクションを置き換える可能性がありますよね？ このこと： merkledag.proto

そこに問題があります。 以前は効率的な処理を可能にする単純な構造（リンク名、パスに直接関連するもの、およびリンクハッシュ）がありましたが、今ではもう少し複雑な構造になっています。 リンクされたハッシュを取得するには、ハッシュテーブルの文字列「mlink」を解決する必要があります。 それは本当に必要ですか？

リンクトデータ/RDFが必要な場合は、独自のワイヤー形式（protobufは私に関する限り素晴らしい）とそれをJSONに変換する方法を単純に定義してみませんか。 次に、その上にJSON-LDコンテキストを使用します。

さて、あなたが考えていたさまざまなデータ構造については、unixfsを除いて素晴らしいと思います。JSON-LDキーはすべての状況でRDF述語を参照する必要があるため、JSON-LDキーとしてファイル名を使用することはできません。 ファイル名はリテラル値です。

それ以外の：

{
  "@context": "/ipfs/Qmf1ec6n9f8kW8JTLjqaZceJVpDpZD4L3aPoJFvssBE7Eb/merkleweb",
  "foo": {
    "@type": "mlink",
    "@value": <multihash>,
    "unixType": "dir",
    "unixMode": "0755",
  },
  "bar.jpeg": {
    "@type": "mlink",
    "@value": <multihash>,
    "unixType": "file",
    "unixMode": "0644",
  }
}

私はこれを次のようにモデル化します：

{
  <strong i="16">@context</strong>: {
    "ipfs":   "tag:ipfs.io,2015:ipfs:"
    "unixfs": "tag:ipfs.io,2015:unixfs:"
  }
  <strong i="17">@type</strong>: "unixfs:directory"
  "unixfs:contains": [
    {
      "@id":   "ipfs://<IPFS Hash>"
      "@type": ["unixfs:directory"]
      "unixfs:name": "foo"
      "unixfs:mode": "0755"
    },
    {
      "@id":   "ipfs://<IPFS Hash>"
      "@type": ["unixfs:file"]
      "unixfs:name": "bar.jpeg"
      "unixfs:mode": "0644"
    }
  ]
}

繰り返しますが、バイナリ/シリアル化されたバージョンはこのようである必要はありません。 この最後の表記をRDFトリップとして表す方法は次のとおりです。

DIRECTORY              <tag:ipfs.io,2015:unixfs:contains> <ipfs://Hash:foo>
DIRECTORY              <tag:ipfs.io,2015:unixfs:contains> <ipfs://Hash:bar.jpeg>
<ipfs://Hash:foo>      <strong i="21">@type</strong>                              <tag:ipfs.io,2015:unixfs:directory>
<ipfs://Hash:foo>      <tag:ipfs.io,2015:unixfs:name>     "foo"
<ipfs://Hash:foo>      <tag:ipfs.io,2015:unixfs:mode>     "0755"
<ipfs://Hash:bar.jpeg> <strong i="22">@type</strong>                              <tag:ipfs.io,2015:unixfs:file>
<ipfs://Hash:bar.jpeg> <tag:ipfs.io,2015:unixfs:name>     "bar.jpeg"
<ipfs://Hash:bar.jpeg> <tag:ipfs.io,2015:unixfs:mode>     "0644"

私はIRCにいます、そこで私にpingすることを躊躇しないでください。

このスレッドのRDFに慣れていない人のために、ここに少し説明があります：

RDFは、データを構造化する方法です。 JSON-LDの背後にあるデータモデルです。 RDFでは、すべてのデータをトリプルでエンコードする必要があります。

<subject> <predicate> <object>

• サブジェクトは、URIによって識別されるノードです
• 述語は<http://www.w3.org/1999/02/22-rdf-syntax-ns#name>のようなURIです。 URIは関係を一意に定義するため、仕様またはスキーマで適切に定義することが望ましいです。
• オブジェクトはリンク/述語のターゲットです。 リテラル値（通常はxsdスキーマから派生した整数や日付などのオプションで入力できる文字列）にすることも、URIで識別される別のノードにすることもできます。

トリプル表記は、すべてのサブジェクトノードとオブジェクトノードがそれを一意に識別するURIを持っていることを前提としています。 1行に1つずつ含まれるすべてのトリプルをリストすることにより、完全なデータ構造を定義します。

JSON-LDのJSONキーは、サブジェクト（キーが存在するオブジェクト）とオブジェクト（JSON-LDキーの値）をリンクする述語です。 この場合、URIはサブジェクトとオブジェクトを参照するために使用されません。 オブジェクトの参照に使用できるURIを指定する場合は、 @idプロパティがあります。

Linked Data over IPFSがHTTPでどのように機能するかと比較して、どのように機能するかを説明する記事はどこかにありますか？ （URIはどのようなものですか？IPFSを介したLinked Dataのパブリッシャーとコンシューマーのベストプラクティスはどうあるべきですか？）

見る：

• https://github.com/ipfs/specs/pull/37
• https://github.com/ipfs/specs/blob/ipld-spec/merkledag/ipld.md

IPLDはjsonデータモデルを提供します。 IPLDの上に任意のJSON-LDを重ねることができます。

（まだ着陸していません）

@jbenetはこのスレッドを読んだだけで、リンクトデータを使用することは素晴らしいイニシアチブですIMHO

LinkedDataが1つのシリアル化を義務付けていないという点であなたは正しいです。 JSON-LD、RDF / XML、RDFa、Turtle、またはその他のさまざまな形式を使用できます

Linked Dataに必要なのは、JSONのキーがURIであるということです。 これは、それらの前にurn:string:<key>を付けるのと同じくらい簡単で、JSON-LDを使用する場合は、コンテキスト内で1つのライナーとして実行するか、明示的に書き出すことができます。

別の（一般的に推奨される）方法は、キーの用語をhttp（s）またはipfs：ドキュメントに配置することです。このドキュメントには、各用語の人間が読める形式の説明が含まれています。

LinkedDataで書かれたIPFSハッシュのメタデータも面白いと思います。 私は今日タートルでこれを簡単に試み、 RFC6920で概説されているパターンを再利用しました。

<ni:///multihash;QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj> 
    <https://schema.org/sameAs> 
        <https://gateway.ipfs.io/ipfs/QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj> ,
        <http://ia801506.us.archive.org/3/items/NodeUp114/NodeUp%20114.mp3> ,
        <ipfs:/ipfs/QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj> ;
    <https://schema.org/contentType>
        "audio/mpeg" ;
    <https://schema.org/title>
        "NodeUp: A Node.js Podcast - Episode 114 - Internationalization Deep Dive" .

https://namedinstance.com/.well-known/ni/multihash/QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj

リンクトデータの考え方は、あなたが物事に与える識別子は、それらを調べれば、関連する物事にリンクするデータを含む有用なデータをそれらに与えるということです。 つまり、ディレクトリにはそこに含まれるもののURIのリストが表示され、イベントには時間とデータ、招待された人へのリンクが表示され、人はグループや他の人へのリンクが表示されます。 http：の代わりにipfs：を介してこれをすべて行うことはもちろん正常に機能し、2つのスペースをリンクすることができます。 たとえば、あるスペースの何かが別のスペースの何かと同じであると主張することができます。 あなたの友人はhttp：spaceに文書化され、あなたの出版物はipfs：spaceまたはあなたが好きなものに文書化されます。

（rdfheadとして、私はTurtleをフォーマットとして好みます。これは、シンプルで強力だと思いますが、JSONLDを確実に使用できます）

/meはstatic.benet.aiに接続してhttp://static.benet.ai/t/ipfs.pdfを読み取ることができません

@timblは、IPFSペーパーの最新バージョンをここで見つけることができます： https ：//github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdfまたはパブリックIPFSゲートウェイ経由の同じ論文： https ：//ipfs.io/ipfs/QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

たとえば、あるスペースの何かが別のスペースの何かと同じであると主張することができます。

はい！ これらはすべて同じです：

• dweb：/ ipfs / somehash
• ipfs：// somehash
• https://dweb.link/ipfs/somehash

申し訳ありませんが、dweb：URIスキームとhttps://dweb.linkは実際にはまだ機能していません。

今のところ、URI（IPFSゲートウェイリダイレクトアドオン内）の場合はfs:/ipfs/somehash $、HTTPの場合https://ipfs.io/ipfs/somehashです。

• ipfs：// somehash
• fs：/ ipfs / somehash
• https://ipfs.io/ipfs/somehash

このスレッドの人々がそれを見逃した場合、それは起こりました！

https://ipld.io/

https://github.com/ipld/ipldでコンボを続けましょう

もちろん。 リンクされたデータの側面について話し合うために、気軽に立ち寄ってください：

https://gitter.im/linkeddata/chat

@nicola確かにそのチャンネルの見知らぬ人ではありません

今日、私たちは実際にipfs：URIをシステムに追加することについて話し合っていました。 ipldで頑張ってください！

明らかにLDではないものに明確に定義された用語「リンクトデータ」を使用するのはなぜですか？
https://www.w3.org/standards/semanticweb/data

だから、これは古いスレッドだと知っていますが、後世のためにミックスするために自分自身を追加しています。

私は検証可能な資格情報データモデル（https://w3c.github.io/vc-data-model/）を使用していて、JSON-LDとIPLDで表される@contextを調整する際にいくつかの問題を思いつきました。 （https://github.com/w3c/vc-data-model/pull/261を参照してください）。 JSON-LDはIPLDと完全に互換性があることは認識できますが、IPLDはJSON-LDと完全に下位互換性がありません。これは、既存の仕様との相互運用性に必要です。 私が見ているように、解決策は、ietfの有効なスキームとしてipld:を追加し（https://github.com/ipld/specs/issues/98を参照）、 { <attr> : ipld:<cid> }を許可することです。 { "/" : <cid> }が達成するものと同じです（https://github.com/ipld/specs/issues/99を参照）。 また/追加でapplication/ipldのMIMEコンテンツタイプを登録して、プロトコルを定義するタイプを宣言します。 これは、混乱を緩和するためにapplication/json+ipldとapplication/cbor+ipldを比較できるようにするために複雑になります。 （ @mildred自然なリンクと `{" @context "：" / ipfs /が必要なため、これにはipfs：//は好きではありません。"}'は有効なURIです）

セマンティックの相互運用性に関しては、IPLDの上にJSON-LDコンテキストを階層化しています。 ただし、これはルート化の問題になり、JSON-LDに有効な値としてURIを埋め込むことで簡単に解決できます。

結局のところ、それはずっと下のカメです：turtle：>：turtle：>：turtle： @timblが見つかる底に到達するまで、それが彼がフォーマットとしてタートルを好む理由だと思います： smiley:。

（rdfheadとして、私はTurtleをフォーマットとして好みます。これは、シンプルで強力だと思いますが、JSONLDを確実に使用できます）

これの完璧な例は、 http：//www.w3.org/を参照するxsd：datetimeにリンクするhttps://w3id.org/did/v1の検証可能な資格情報の@contextでの日時の処理です。 2001 / XMLSchema＃ 、ドキュメントソースとしての説明はhtmlにあります。

このxmlでの私のお気に入りの注釈は次のとおりです。

まず、組み込みのプリミティブデータ型。 これらの定義は情報提供のみを目的としており、実際の組み込み定義は魔法です。

：turtle：>：turtle：>：turtle：のスタックの一番下でそれを受け入れる限り、この魔法で作業できます。 @ timblであることに同意し、JSON-LDとの下位互換性を次のように調整できます。上記のipld: 。

@jonnycrunch私はあなたのアイデアをサポートします。 特にJSONはブラウザにネイティブであり、学習曲線が浅いため、JSONはWeb上で非常に確立されているため、Turtleは最も人気がありません。

幅広い開発者コミュニティにアピールすることと、相互運用性があり（白黒ではない）、機能が豊富なシステムを使用することの間には、バランスが必要です。

完全なURLを入力すると、 @contextの問題は解消されます。 それはより多くの文字ですが、それがラウンドトリップを回避し、リモートファイルの整合性を検証する必要がないことを考えると、ベストプラクティスではないにしても、より良いと思うように見つめています。

最終的に、URIは名前（uuid）とロケーター（プロトコル）の両方であり、脳は両方を一度に簡単に考えることができないという点で混乱が生じます。 JSONのキーでURIまたはURIの省略形を使用しているところまで到達できれば、これらの問題の多くは解消されます。 実際、ipfs：とhttp：に名前を付けると、リンクトデータを一種の接着剤として使用して、協調ネットワークの一部になる必要があります。

コメントを更新して、構文ipld:<cid>を使用しました。これは、権限がないため、 ipld://のダブルスラッシュ//に値しないことを認識しています。 ペイロードは自己記述型であるため、それ自体が権限であり、独立している必要があります。 しかし、それは専門家の主張です。

@jonnycrunchは書いた：

解決策は、IPld：をIETFの有効なスキームとして追加することです。

私はこのアプローチを非常に支持しており、（より伝統的な）LinkedDataコミュニティとIPFS/IPLDコミュニティの間の素晴らしい相互運用ストーリーにつながると思います。