Solid 后端实现范例与参考资料

我现在熟悉 Solid 平台的基本要素(需要支持 Solid Pods)。也就是说,LDP 要存储 WebID 和 ACL(访问控制列表)。我研究了下 node-solid-server,它的实现方式是使用服务器上的文件系统托管 Turtle 和其他资源文件,以及访问控制文件。

是否有其他的 demo 或实现方法?之前有没有人讨论过?即使是在实验阶段也行。

有没有人尝试过,或者打算在数据库类型结构(如键/值存储)之上实现 Solid 平台?

我的兴趣在于探索使用 SAFE 网络作为 Solid 后端的不同方法。我已经实现了最原始(仅存储)的 Solid 平台,并通过在浏览器中模拟 Solid 协议,演示了在 SAFE 网络上运行的 Solid 应用程序(Solid Plume,我对原始应用程序进行了少量修改)。对于后端,我采取了简单的方法——效仿 node-solid-server,我给一个文件系统创建了 LDP 接口,就像API一样(SAFE NFS,SAFE 网络文件系统)。这个文件系统存储了一些资源,包括 Turtle 文件。请参看下面链接中的视频和幻灯片:SAFE Plume 演示

继此之后,Maidsafe 一直在探索其他实现方法,并实现了一个实验性的 RDF API,用于演示去中心化的 WedID 管理器和图表应用,所有这些都存在于 SAFE 网络上。曾在 DWebSummit 2018 上展示:请参阅 SAFE 论坛主题(如果有更好的链接 @bochaco 请通知我)。

这种“概念证明”展示了一种不同的方法,将 RDF 片段存储在基于键/值的可变数据中,而不是我之前使用的方法——键/值功能用于存储指向不可变 blobs(对应于 node-solid-server 托管的文件)的指针。

有一个主题,详细介绍了实验性的 RDF API 如何在键/值存储中存储 RDF 片段,因此如果你想阅读或提供反馈,请参阅这个 Solid 论坛主题

重申一下我的问题,是否还有其他示例,模型等,用于Solid平台实现或关联数据存储?这可能有助于探索出其他存储方式(不仅仅是 SAFE)

外国友人真是厉害啊

Thank you @acoburn & @bergos these are both what I was hoping for. ☺

我曾经开发过 JavaScript LDP 实现。 它不完整而且已经过时了,但从架构的角度来看值得参考。 它使用 RDF-Ext 作为 RDF 资源。 对于 blob,可以使用 blob-store 包。 现在 RDF-Ext 的东西应该用 RDFJS 包替换,但 blob store 的东西应该仍然是最新的。
https://github.com/bergos/ldp
https://github.com/maxogden/abstract-blob-store

前段时间我写了一些关于 HDT 的想法,一个二进制 RDF 序列化。 标签我设置成了 IoT,但我也考虑标记为了 IPFS 和 SAFE。
https://gist.github.com/bergos/321e0fe458d8a31f41508ba8628c8220

我们的团队一直致力于开发基于 Java 的 LDP 服务器,目的是使其完全符合 SOLID 规范。现在兼容得差不多了,支持 WebACL,WebID 和各种 LDP 容器类型。目前不支持 WebID-TLS 身份验证,但即将推出。

我提到这个项目的原因是它引入了一组抽象层,可以为 LDP 资源编写不同的持久性后端——它不依赖于文件系统或某种用于处理持久性的技术栈。可以想象,使用三元组存储(参考实现)来持久化 RDF 非常简单直接。我还编写了一个基于 RDBMS 的持久层。不算太复杂:虽然 LDP 对数据查询有很多限制,但创建一个支持 RDF 数据和 LDP 结构的模式相当简单。此外,这些实现是同步的(通常)意味着单节点系统。

但你的问题是关于键值存储的。是的,我们目前正在构建一个基于 Cassandra 的后端,它被设计为严格的键值存储模式。在内部,我们将 NFads 格式的 RDF 数据存储为 blob 数据(即使输出始终是 RDF 三元组)。命名图用于将用户管理的数据与其他种类的资源数据(例如审计日志,服务器管理的三元组等)分开。 NQuad 格式虽然并不总是像 Turtle 一样简洁,但非常灵活,它可以轻松地将 RDF 以流的形式传到客户端。关于像 Cassandra 这样的键值存储,有一点需要注意的是,虽然 LDP Basic Containment 并不太难实现,但 Indirect Containment 不是首选。 (Direct Containment 位于中间,实现方面)。幸运的是,SOLID 只需要支持 Basic Containment,因此没有打算支持基于 Cassandra 服务器的 Indirect Containers。目前正在讨论对 Direct Containment 的支持。另一方面,关系数据库或三元组存储使得实现其他种类的 LDP 结构并不太困难。

另一个(更实验性的)持久层实现使用了“RDF-Delta 2”格式。我特别感兴趣的是随着时间的推移跟踪 RDF 资源,这使我能够将某个资源的 RDF 建模为仅附加日志(即,添加这些 quads,删除那些 quads)。同样,持久层是 RDF(或 RDF-Delta)数据的严格键 / 值 blob。这与 Memento 标准结合使用,可以在任意时间点检索 RDF 资源的状态。资源日志——每个资源都有自己的日志——也有一个简洁形式(即普通的 NQuads),它可以用任何简单的GET请求读取。通过这种实现,几乎所有东西都是异步的,并且它充分利用了 Kafka 作为事件总线,Apache Spark 作为数据处理层。该体系结构比简单的文件系统或关系数据库复杂得多,但它也非常快,并且可以进行横向扩展。

在 LDP 上下文中处理键值(或任何类型的异步,分布式)持久性存储时,复杂的一点在于管理资源状态。例如,当一个 HTTP 客户端 POST 到容器以创建子资源而另一个客户端同时向该容器发送 DELETE 请求时会发生什么?

我希望你觉得有帮助!如果您想了解更多详细信息,请与我们联系。

这个讨论很有意义,用文件系统存储 RDF,是有很大瓶颈的

这句话描述了我如何让 Solid Plume 运行在 SAFE 网络上。如上所述,它反映了 node-solid-server 的工作方式,将 LDP、Turtle 和其他任意文件类型存储为文件 / blob。

键/值功能用于存储指向不可变 blobs(对应于 node-solid-server 托管的文件)

所以这不是存储为 RDF 的,对吧? 我们希望所有内容都应该是 RDF,即我们认为指向不可变 blob 的指针列表也应该是RDF。