Ipfs: IPFS-LD - 关联数据

嘿@jbenet ，IPFS 做得很好，对你正在做的事情非常感兴趣，因为我们正在研究使用 DHT（类似 Kademlia）+ 数字签名 + 查询网络来替换 Internet 上的命名（最终替换 DNS）。 我们正在做的基本工作与您使用 IPFS 所做的工作非常接近： https ://manu.sporny.org/2014/identity-credentials/。 我们正在为此计划使用 JSON-LD，您知道 Telehash 吗？ 如果没有，您应该看看其中一些概念可能会加强 IPFS。

在任何情况下，如果您希望网络上的元数据是机器可读和可处理的，但以可扩展的方式，您应该使用 JSON-LD。 如果您使用 JSON-LD，您很有可能可以集成 W3C 的 Web 支付和凭证工作，因为这两个工作集也是构建在 JSON-LD 之上的。 JSON-LD 的主要好处之一是您可以合并来自不同来源的数据。 另一个是您可以指定基本数据格式并允许人们在不与您协调的情况下扩展协议（如果您希望系统以指数速度增长，这一点很重要）。

只是一些想法，如果您有问题，请提问。 在网络上的每个 JSON blob 中都需要一个@context并不是一个严格的要求。

谢谢你的想法！

我们正在研究使用 DHT（类似 Kademlia）+ 数字签名 + 查询网络来替换 Internet 上的命名（最终替换 DNS）。

然后确保查看论文中的 IPNS 部分： http://static.benet.ai/t/ipfs.pdf (3.7)。 :)

你知道 Telehash 吗？

是的，我非常赞成总体概念+构建它的动力，但不赞成该项目的许多决策。 举个例子，标语是“JSON + UDP + DHT = Freedom”，但我认为这类系统应该（a）不强制数据格式，（b）不强制传输协议，（c）不强制路由系统。 当然，这三个是今天的不错选择，但必须构建这些协议以适应跨层和跨时间。 因此，IPFS 允许用户使用他们想要的任何格式，IPFS 可以在任何传输之上进行分层，尽管第一个路由系统将是 DHT，但还有其他需要探索。

您可以将 IPFS 视为 Telehash + (merkle) Web。

如果您希望网络上的元数据是机器可读和可处理的，但以可扩展的方式，您应该使用 JSON-LD。

我认为我们可以在您的工作中使用 -LD 部分，而不需要 JSON 作为传输。 即我认为你的（很棒的）工作可以推广到任何树数据结构，并且比其他语义网络格式要好得多。 （惊人的简单性 + 灵活性！）所以我在这些笔记中指向的是使用@context的等价物，但在 IPFS 链接数据结构中（它不是 JSON，它是一种用于快速搜索对象的二进制打包格式-- 今天的 protobuf，但以后也可能是自我描述的 -- 我希望 IPFS 足够快，可以作为数据库工作。不是今天，而是将来 :) )。

在网络上的每个 JSON blob 中要求@context并不是一个严格的要求。

是的，我也有同样的看法：）

@jbenet 回复： https ://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309 - 是的，我认为你的论点非常好，消息灵通。

我真的对你在做什么很感兴趣，我浏览了报纸并开始观看你的视频。 不幸的是，我今天需要完成最后期限，但要阅读您的论文并观看我的待办事项列表中的整个视频。 我不知道您是否知道这一点，但我致力于通过 W3C 为 Web 构建标准。 我们现在有一系列问题需要与您概述的解决方案类似的解决方案。 我想看看我们是否可以将您的一些工作集成到我们正在为 Web 开发的下一代 W3C 标准登录解决方案中（我在上面提到的帖子）。 我们目前正在使用 Telehash，但确实对它有一些担忧，而且您似乎已经以更适合我们用例的方式分解了问题。

无论如何，让我深入了解您创建的内容，然后再回复您。 如果您在一周内没有收到我的消息，请再次联系我。

嘿@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更有效。 如果我们期待更多这样的事情，也许它只是要求将链接划分为内部和外部集合。 您可以通过添加一个“内部”布尔值来将@context类型条目与任何@context文件条目（例如）。

抱歉，此时格式（几乎可以肯定）没有改变。 我花了几个月的时间把它归结为这个，并且不会再打开那个闸门。 剩下的问题（如链接扩展）已经知道了一段时间，只是找到了正确的方法。

ipfs 对象是像 json 或其他任何东西的树。 这意味着所有可用于 JSON 的解决方案（包括 JSON-LD、JSON-schema 等）都可用于 IPFS。 此外，将 RDF 三元组表示为 ipfs 对象也很简单。 因此，您可以做任何事情。

真实数据非常混乱。 世界上没有人成功地迫使人们采用特定的数据类型系统——我不会花时间在这些争论上。 从长远来看，我认为唯一可行的解​​决方案是使系统足够灵活，让人们可以随心所欲地做任何事情，并且足够严格，以便一切都相互联系。

现在，_preferred_ 方式——我们建议人们做事的方式——很可能是来自（非常强大和简单）JSON-LD 的@context / @type 。

但我不知道你是如何摆脱那条链条的

我不明白这个问题。 没有链，你解决上下文一次，就是这样。 那是对象的上下文文件。 如果它不是一个有效的上下文——有一个规范——你忽略它。 应用程序不应_依赖_这些类型是否正确，而应在正确时利用它们。

@tv42还提出了与文件名冲突的担忧，因为目录节点使用子段名称作为它们的键。

如果一个 dir 数据结构已经有一个@context它将不允许创建另一个文件 - （或者在最坏的情况下，在（稳定排序）之后附加链接）。 这与尝试创建两个具有相同名称的文件相同。

2015 年 5 月 1 日星期五上午 03:51:22 -0700，Juan Batiz-Benet 写道：

抱歉，此时格式（很可能）没有改变。 一世
花了几个月的时间把它煮沸，而不是打开洪水
盖茨再次。 剩下的问题（如链接扩展）
已经知道了一段时间，只是找到了正确的方法
它。

链接扩展应该可以正常工作。 并将链接键添加到
命名空间它们也不是那么糟糕。 填充类型信息
into Data 也可以工作（这就是文件和目录现在的工作方式
[1,2,3,4,5]）。 枚举类型不是一种可持续的方法，但
这些地方中的任何一个都可以作为存储类型哈希的地方。

现在，_preferred_方式——我们建议人们做事的方式
-- 很可能是@context / @type来自
（非常强大和简单）JSON-LD。

JSON-LD 很好，但它周围的生态系统需要了解
@-前缀是特殊的。 我更喜欢存储特殊性
通过使用附加数据显式扩展链接条目（例如
内部/外部标志），所以我们在@context 之间没有歧义
文件和@context类型链接。 但是如果所有文件/子目录链接都被键入
与'孩子/'，那么你可以有类型的'上下文'
文件（或其他）的链接和“子/上下文”。 它还在继续
必须是对象生成器的外部定义约定
消费者需要通过非自我描述的渠道达成一致。

但我不知道你是如何摆脱那条链条的

我不明白这个问题。 没有链条，你解决
上下文一次，就是这样。 这是上下文文件
目的。 如果它不是一个有效的上下文——有一个规范——你
忽略它。

这对我行得通。 我想知道你如何结束自我描述
链：

A是什么类型？ 让我们跟着 A/ @context到 B。B 是什么类型？
让我们跟着 B/ @context到 C…

但是，如果您要分发 B 规范（在我的示例中为 C），则没有
需要一个 B/ @context链接。 但如果你有一个渠道
分发类型规范（C），为什么不也用它来分发
类型模式本身（B）？ 似乎最好有一个
对象中的常规位置，其中包含描述其的多重哈希
类型（您的@context链接，或其他）。 然后让开并
让生产者/消费者社区来决定这是否是一个
对类型定义的引用（可能在规范 C、Cv2 或
替代 CCv1.3，或……），或者如果他们只想使用多重哈希作为
一个不透明的标识符。 然后您仍然可以执行以下操作：

切换 pbn.GetType() {
案例 ft.T 目录：
root.val = NewDirectory(pointsTo.String(), mnode, root, fs)

只是 GetType 会获取@context Link 哈希（或
任何地方），并且 TDirectory 将是一个多重哈希
(QmWellKnownDirectoryType)。

应用程序不应_依赖_这些类型是否正确，但
而是在它们存在时利用它们。

这听起来像是一个不透明的标识符。 也许我们说的一样
事物 ;）。

@tv42还提出了对文件名冲突的担忧，因为
目录节点使用子段名称作为它们的键。

如果 dir 数据结构已经有@context它不会允许
创建另一个文件——（或者在最坏的情况下，在后面附加链接
（稳定排序））。 这与尝试使用
一样的名字。

如果你想让@context文件非法;)。 如果你想
允许人们创建@context文件，你需要一些方法来
消除“this link points at a type”和“this link”之间的歧义
指向文件/子目录/…”。 但是有很多方法
围绕这个问题，所以只要我们选择其中一个我会很高兴
;)。

几天前我与@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 日星期五晚上 9:24:27 -0700，W. Trevor King 写道：

链接扩展应该可以正常工作。 并将链接键添加到
命名空间它们也不是那么糟糕。 填充类型信息
into Data 也可以工作（这就是文件和目录现在的工作方式
[1,2,3,4,5]）。 枚举类型不是一种可持续的方法，但
这些地方中的任何一个都可以作为存储类型哈希的地方。

在相关说明中（分发散列类型 ID 以及
有效载荷）， @tv42刚刚让我注意到了 Ethos ETypes [1,2,3]。 所以
我认为对这些事情有某种明确的插槽将是
伟大的。

还没有看到 ETypes，感谢浮出水面。 将在接下来的几天内阅读。 相关的是 Kathleen Fisher 的 PADS 工作 + 相关。 PADS 项目页面最近似乎已更改（如果只有一些内容寻址的网络不可变存储......）。 （但互联网档案再次拯救了我们\o/：http://web.archive.org/web/20130125041549/http://www.padsproj.org/）

• PADS：用于处理即席数据的特定领域语言
• PADS 项目：概述
• PADS/T：一种用于描述和转换 Ad Hoc 数据的语言
• 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
• scheme://full-uri ：被识别为谓词为 URI 的链接
• prefix:name ：被识别为一个链接，其谓词是前缀 URI（在上下文中定义）和 name 的串联
• 名称：仅在上下文中定义时才被识别为链接

特别是，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将始终引用 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 文档是可以接受的（因为所有内容都打包在一个文件中），但对于每个节点具有不同哈希并且必须单独跟踪的 IPFS 可能不可接受。

也许，我们想要的不是按原样使用 JSON-LD，而是定义我们自己的受 JSON-LD 启发的上下文格式。 这会更好，因为我们的格式不是 JSON，并且非常具体：我们希望能够描述任意键映射（对于 unixfs），并且我们还希望使用 IPFS 对象的数据部分（JSON 没有那个）。

由于 IPFS 对象的链接部分非常严格，因此链接具有名称并指向另一个对象。 它不能包含文字值。 我们需要在上下文中指定的是 URI 形式的链接的完全限定名称。 由于我们还有一个数据部分，我们需要定义它包含的内容。

对于 unixfs，我会想象以下对象：

• directory :
  
  
  
  • 链接@context指向目录上下文
  
  
  • 链接entry:README.md指向 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

重要笔记：

• 放宽链接到_allow_包含其他值（非常需要），我们只保留{"@type": "mlink", "hash": "<multihash>"}
• 用户可以为他们的数据结构定义上下文
• 可以_nest_链接，使用路径表示法遍历例如https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141

我认为你和我都在正确的轨道上。 我还认为我们可以在不偏离 JSON-LD 的情况下做很多这样的事情。 只是放弃一些限制

@mildred在这里记录

还应该说——从我与 dlongley 的谈话来看——在技术上不偏离 JSON-LD 标准的情况下，应该可以做我们想做的事，只是_调用转换（压缩/扩展）_会去掉所有“非-上下文定义的”键。 （我们应该努力不偏离）

我认为您可以通过根据生成的三元组来考虑 JSON-LD，而不是 json-ld.js 解析器在转换 JSON 时的作用，从而消除很多困惑。 JSON 转换步骤特定于该解析器，您可以想象以另一种方式轻松转换它而不会出现问题。

现在，如果我很好地理解你在用go-ipld做什么，它可能会替换当前 IPFS 对象中的 Link 部分，对吧？ 这个东西： merkledag.proto

我看到那里有问题。 以前我们有一个允许有效处理的简单结构（链接名称，与路径直接相关，和链接哈希），现在我们有一个更复杂的结构。 要获得链接的哈希，您必须在哈希表中解析字符串“mlink”。 这真的有必要吗？

如果你想要链接数据/RDF，为什么不简单地定义你自己的有线格式（就我而言，protobuf 很棒）以及它可以转换为 JSON 的方式。 然后在此之上使用 JSON-LD 上下文。

现在，关于您正在考虑的不同数据结构，我认为它们很棒，除了 unixfs：我们不能将文件名作为 JSON-LD 键，因为 JSON-LD 键在任何情况下都必须引用 RDF 谓词。 文件名是文字值。

代替：

{
  "@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。 它通过列出每行包含一个的所有三元组来定义完整的数据结构。

JSON-LD 中的 JSON 键是连接主语（键所在的对象）和对象的谓词：JSON-LD 键的值。 在这种情况下，URI 不用于指代主体和客体。 如果要指定可用于引用它的对象的 URI，则有@id属性。

与通过 HTTP 的工作方式相比，是否有任何地方解释 IPFS 上的链接数据如何工作？ （URI 是什么样的？IPFS 上的链接数据的发布者和消费者的最佳实践应该是什么？）

看：

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

IPLD 为您提供 json 数据模型。 您可以在 IPLD 之上分层任何 JSON-LD。

（还没落地）

@jbenet刚刚通读了这个帖子，恕我直言，使用链接数据是一个很好的举措

您是正确的，因为 Linked Data 不要求任何一种序列化。 可以使用 JSON-LD、RDF/XML、RDFa、Turtle 或一堆其他格式

关联数据确实需要 JSON 中的键是 URI。 这可以像在它们前面加上urn:string:<key>一样简单，如果使用 JSON-LD 可以在上下文中作为一个衬里完成，或者显式写出。

另一种（通常首选的）方法是将它们用于键的术语放在 http(s) 或 ipfs 中：包含每个术语的人类可读描述的文档。

我认为同样有趣的是用 Linked Data 编写的 IPFS 哈希的元数据。 我今天在 Turtle 中快速尝试了这一点，重用了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 列表，事件为您提供了时间和数据以及指向受邀人员的链接，人们为您提供了指向组和其他人的链接，等等。 通过 ipfs: 而不是 http: 做这一切当然工作正常，你可以链接两个空间。 例如，您可以断言一个空间中的某物与另一个空间中的某物相同。 您可以将您的朋友记录在 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实际上还没有工作。

现在它是fs:/ipfs/somehash用于 URI（在 IPFS 网关重定向插件中）和https://ipfs.io/ipfs/somehash用于 HTTP：

• 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

所以，我知道这是一个旧线程，但我正在添加自己以供后代使用。

我一直在使用 Verifiable Credentials 数据模型 (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，这对于与现有规范的互操作性是必要的。 如我所见，解决方案是将ipld:添加为 ietf 中的有效方案（请参阅：https://github.com/ipld/specs/issues/98）然后允许{ <attr> : ipld:<cid> }与{ "/" : <cid> }在 IPLD 中完成的相同（参见：https://github.com/ipld/specs/issues/99）。 另外/另外注册application/ipld的 MIME Con​​tent-type 以声明定义协议的类型。 这将复合以允许application/json+ipld与application/cbor+ipld以减轻混淆。 （ @mildred我不喜欢 ipfs:// 因为我们需要自然链接和 ` { "@context" : "/ipfs/" }' 是一个有效的 URI)

至于语义互操作性，我一直在 IPLD 之上分层 JSON-LD 上下文。 但是，这涉及到一个根本问题，通过将 URI 作为有效值嵌入 JSON-LD 可以轻松解决。

最终，它一直是Turtles :turtle: > :turtle: > :turtle: 直到你找到@timbl的底部，这就是为什么我认为他更喜欢 Turtle 作为一种格式 : smiley:。

（作为一个 rdfhead，我更喜欢 Turtle 作为一种格式，因为我发现它简单而强大，但你当然可以使用 JSONLD）

一个完美的例子是在https://w3id.org/did/v1处理@context中的可验证凭证的日期时间，它链接到引用http://www.w3.org/的xsd:datetime 2001/XMLSchema# ，其中作为文档源的解释在html中。

这个 xml 中我最喜欢的注释是：

首先是内置的原始数据类型。 这些定义仅供参考，真正的内置定义很神奇。

我可以使用这个魔法，只要我们接受 :turtle: > :turtle: > :turtle: 堆栈的底部我们同意它是@timbl然后我们可以使用 JSON-LD 来协调向后兼容性以上与ipld: 。

@jonnycrunch我支持你的想法。 Turtle 并不是最流行的，因为 JSON 在 Web 上已经很成熟了，尤其是 JSON 是浏览器原生的，而且学习曲线很浅。

在吸引广泛的开发社区和拥有一个可互操作的系统（不是非黑即白的）和功能丰富的系统之间需要取得平衡。

如果您输入完整的 url， @context问题就会消失。 虽然它有更多的字符，但我认为这是一个更好的实践，如果不是最佳实践的话，因为它避免了往返并且您不需要验证远程文件的完整性。

最终会出现混淆，因为 URI 既是名称（uuids）又是定位符（协议），大脑不容易同时考虑这两者。 如果我们能够在 JSON 的键中使用 URI 或 URI 的简写，那么这些问题中的许多问题都会消失。 事实上，命名 ipfs: 和 http: 应该成为合作网络的一部分，将链接数据作为一种粘合剂。

我更新了我的评论以使用语法ipld:<cid>意识到它是非权威的，因此不值得使用ipld://双斜杠// 。 由于有效载荷是自我描述的，它是它自己的权威，应该独立存在。 但这是专家的论点。

@jonnycrunch写道：

解决方案是添加 ipld: 作为 IETF 中的有效方案

我非常支持这种方法，并认为它会在（更传统的）关联数据社区和 IPFS/IPLD 社区之间带来一个伟大的互操作故事。