• ivy

    @JuerGenie 我们会实现的,征途大海

    posted in 综合讨论 read more
  • ivy

    最大的优势其实就是关联数据啦,和 BaaS 等 Serverless 产品相比劣势还挺多的。
    比如难用的技术栈,firebase 这些都是常用的后端技术(MySQL、MongoDB)等,SoLiD 的技术较为冷门。别说研究生要学「语义网」,现在研究生还是少数群体。

    优势较少,还是想想怎么解决劣势问题比较好。比如怎么让 RDF 变得更为大众一些,包括图的搜索能力也比不上关系型数据库,要想办法看能不能融合 DGraph,感觉 Graphql-LD 是个非常好的方向呢。

    posted in 综合讨论 read more
  • ivy

    通过激励协作实现语义 Web 的弱中心化

    本文由 SoLiD 中文社区 翻译自:https://ruben.verborgh.org/articles/incentivized-collaboration/

    个人隐私数据正在以一种前所未有的规模被大量使用,由此引发了 Facebook + Equifax、Google Plus 等大公司的隐私丑闻事件。去中心化只是个乌托邦,我们不谈去中心化,只谈弱中心化。个人数据的弱中心化可以让普通人控制他们的数据(尤其是网络数据),语义网技术可以让数据集成变的更快。但是,对于弱中心化的数据处理需要更复杂的算法,由此需要更强大的算力。由于不是中心化的数据处理中心,各个数据节点的处理能力更低(你是否想到了边缘计算?)。本文介绍了一个愿景,使用分布式账本进行数据处理协作,并激励网络中的各节点。通过利用所有节点的集体处理能力,我们可以寻求除了当前「集中式计算机房」外另外的替代方案,使人们能够在不影响功能的情况下重新获得数据的所有权。

    通过弱中心化个人数据的存储来重新获得数据的控制权

    在过去的几年里,我们目睹了网络上个人数据前所未有的集中化。无论你同意与否,大型社交媒体都在收集我们的信息,并在其强大的数据处理中心存储和分发这些信息。人们为了获取更好的服务,不得不将数据共享给软件服务商。例如,在 Facebook 上,包含家庭成员的相册会上传进去。Equifax 和 Facebook 的严重隐私丑闻让我们看到了将大量数据集中在一处可能产生的风险。而重新获得对数据的控制权是万维网发明人 Tim Berners-Lee 在 2017 年制定的三个主要挑战中的两个。

    让人们重新控制数据的方式是允许数据存储在他们想存储的任何地方,而这和他们想要使用的应用程序无关。这是 SoLiD 等计划背后的核心思想:数据是分散的,是弱中心化的,每个人都可以将数据存储在自己的空间中,并且应用程序与数据分离,因为使用 A 应用程序创建的资源可以被 B 应用程序读取和修改。

    https://pic1.zhimg.com/80/v2-2e8cafca45bd2e82209fa92a7e8290bc_hd.jpg

    应用程序无权要求所有权,而是从分散的数据中心查询数据

    上图是一个示例,可以看到社交应用的数据源是由其他应用程序创建的图片或者会议事件。此外,通过从多个存储位置查询数据来构建社交推送,而无需事先集中收集数据,也是 SoLiD 的一个核心亮点。这样,人们就可以自由选择他们的存储提供商和他们的应用程序提供商,并可以随意转移他们的数据。他们可以让应用程序,其他人或公司在他们认为合适的时候访问其数据的特定部分,并在任何给定的时间点撤销或限制该权限。这可以实现真早的数据所有权和完全控制。

    由于这种方式需要处理相同的数据,所以需要一份标准协议,这可以通过 RDF、SPARQL 等语义网技术实现。开发者可以通过选择被广泛认可的本体来表示数据,每个人都可以自由选择他们的本体,并且由于语义学的存在,推理可以弥合本体间的差异。换句话说,关联数据(Linked Data)的弱中心化特质和 RDFS 、OWL 的不协调性质非常适合 SoLiD 的目标。

    弱中心化的性能问题

    与集中式计算中心相比,弱中心化的系统面临着两个问题:

    1. 单个节点不仅要解决更难的问题,所拥有的资源也更少;
    2. 由于分布式,弱中心化数据处理比集中式数据处理需要更多的计算能力和网络带宽;

    此外,现在很多数据处理算法还没有为弱中心化的数据处理做好准备。我们举一个简单但实际的例子,构建具有 500 个朋友的社交网络推送,在最坏情况下需要执行对 500 个不同数据源的查询,其中每个人朋友将他们的数据存储在不同的位置。最先进的 SPARQL 查询引擎只需要查询十几次。相比之下,弱中心化的数据存储将需要联合查询数百个小型数据集。数据源的选择策略对于性能至关重要。

    最后,通过查询链接暴露个人数据存储带来了安全问题上的挑战。联合 SPARQL 查询通常在私有网络中进行测试。在公共 Web 上,SPARQL EndPoint 长期以来一直受到可用性问题的影响,无论是技术原因还是管理原因,这些问题至少可以通过个人数据的掌控权表现出不可忽视的风险。当数据在越来越多的节点上传播后,我们可能遇到严重的带宽使用问题和查询速度下降问题。

    通过多方协作最大化性能

    若中心化网络具有特定资产:即使单个节点与大规模服务器集群相比资源有限,但总体而言,这些节点具有更大的计算能力和带宽。每个单独的个人数据存储以及每个客户端(计算机、智能手机、平板电脑)都会使用自己的 CPU - 这些 CPU 在集中式环境中通常未得到充分利用。如果我们找到可以让这些节点协作的方法,我们就可以解决弱中心化网络中的资源问题。如果我们采取优化措施,例如在最接近数据的节点上执行计算工作(也就是所谓的「边缘计算」),我们就可以抵消由于弱中心而产生的算法复杂度提升。

    我们可以把这种理念应用于应用程序的数据收集阶段,在弱中心化网络中,这相当于联合查询(从不同的数据存储中心上查询)。社交媒体通常包含重叠的人群,因此任何人都可能成为其他人的联系人。所以,我们可以达成一个共识,也就是,如果你帮助我执行了我的查询,我也可以帮助你执行你的查询。然后,我们就可以将更大的子查询并行的委托给 10 个或 20 个节点,而不是将子查询发送到例如 500 个节点。因此,我们不是在服务器或客户端完全执行数据收集,而是通过网络动态地重新分配查询执行。

    通过分布式账本提供激励和信任

    为了实现可持续的协作,需要激励节点充当网络的贡献者。否则,节点无法确定,如果它在空闲时帮助其他节点,则其他节点需要记录此节点的优先级。但是,当创建激励时,节点可能会产生不诚信问题,因此我们需要一种信任机制来验证工作是否正确完成。由于在弱中心化网络中不存在集中式的实体,我们需要一种弱中心化的共识来建立这种激励和信任。这可以通过分布式账本来实现,它可以跟踪所执行的工作,从而获得其他人的帮助。

    一类分布式账本是区块链,需要证明才能在账本中添加内容。比特币是以无意义计算而闻名,但较新类型的区块链项目(比如 Filecoin)为此引入了更有意义的计算。使用 Filecoin,人们可以向其他人安全的存储和检索他们的数据,并且复制证明和时空证明会确认数据始终存在。我们同样需要开发一个查询证明结果,它既可以捕获所执行的工作,也可以捕获结果的正确性。

    下面这张图显示了网络中单个节点的架构体系。当一个查询到达时,该节点确定它愿意接受的激励和愿意为其他人支付的激励。在可能委派了一些工作并自行执行完成之后,它会保留数据的出处并生成结果的正确性证明。整个交易在区块链上注册,以便所有参与者都能获得奖励。某些节点可能会提前计算常见查询的部分结果,或者缓存常见数据以加快查询速度。

    https://pic2.zhimg.com/80/v2-508189bcbb806a6e4cd9468de7136d89_hd.jpg

    网络中的每个节点都有一个查询处理器,可以自己执行查询或把部分委托给其他人。激励模型会捕获所需要的奖励、出处和提供正确性保证。执行任务及其激励措施会记录在区块链上。

    预计影响

    在目前的弱中心化语义数据网络中,整个想法先于了市场发展。上面的一些示例只是说明了对个人数据查询的委托,还可以将其作为其他服务,比如将数据转换为不同本体的推理。所有这些应用程序都依赖于客户端 CPU 在大多数时间属于空闲状态的原则,也就是说,当我们不需要使用 CPU 时将其借给其他人使用,当我们 CPU 不够用时可以委托其他人帮助我们计算。

    这份提案将对语义网技术的规模化成长产生巨大影响,尤其是在缺乏明确业务模型的情况下。它为弱中心化算法开辟了新的方向,并在语义网和「agent」代理理论指南建立了联系,同时还应用了经济模型中的激励措施。当然我们还要注意隐私等问题,也许我们可以通过加密来保证安全。最重要的是,这个愿景向大小玩家都勾画出了一个面向 Web 的语义 Web 之路。

    参考文献

    [1]Berners-Lee, T. (2017), “Three challenges for the Web, according to its inventor”, World Wide Web Foundation, March, available at:https://webfoundation.org/2017/03/web-turns-28-letter/.

    [2]Mansour, E., Sambra, A.V., Hawke, S., Zereba, M., Capadisli, S., Ghanem, A., Aboulnaga, A., et al. (2016), “A Demonstration of the Solid Platform for Social Web Applications”, inCompanion Proceedings of the 25thInternational Conference on World Wide Web, pp.223–226, available at:http://crosscloud.org/2016/www-mansour-pdf.pdf.

    [3]Buil-Aranda, C., Hogan, A., Umbrich, J. and Vandenbussche, P.-Y. (2013), “SPARQLWeb-Querying Infrastructure: Ready for Action?”, inProceedings of the 12thInternational Semantic Web Conference, available at:https://aran.library.nuigalway.ie/handle/10379/4545.

    [4]Verborgh, R., Vander Sande, M., Hartig, O., Van Herwegen, J., De Vocht, L., De Meester, B., Haesendonck, G., et al. (2016), “Triple Pattern Fragments:a Low-cost Knowledge Graph Interface for the Web”,Journal of Web Semantics, Vol.37–38, pp.184–206, available at:http://linkeddatafragments.org/publications/jws2016.pdf.

    [5]Nakamoto, S. (2008), “Bitcoin: APeer-to-Peer Electronic Cash System”, available at:https://bitcoin.org/bitcoin.pdf.

    [6]Filecoin: A Decentralized Storage Network, Whitepaper. (2017), , Protocol Labs, available at:https://filecoin.io/filecoin.pdf.

    [7]Grubenmann, T., Dell’Aglio, D., Bernstein, A., Moor, D. and Seuken, S. (2017), “Decentralizing the Semantic Web: Who will pay to realize it?”, inProceedings of the Workshop on Decentralizing the Semantic Web, available at:http://ceur-ws.org/Vol-1934/contribution-01.pdf.

    posted in 综合讨论 read more
  • ivy

    不需要承担费用,可以放心食用

    posted in 招聘求职 read more
  • ivy

    我也有一块 ruff 板,放着快积灰了……你说的这个想法挺好的。个人网盘最重要的是硬盘和文件管理系统

    posted in 综合讨论 read more
  • ivy

    @EurekaChen Protege 确实是个有名的软件,也很复杂

    posted in 问答求助 read more
  • ivy

    建议学一下 prolog,可以解决你很多疑问

    <小明,朋友,韩梅梅>

    关于对话那个,其实 triple 理解为主谓宾是最好的。

    如:
    <小明,对话,韩梅梅>

    关于自己创建 owl,要请 @linonetwo 来回答下。

    posted in 问答求助 read more
  • ivy

    支持的,这是 SoLiD 规范之一

    posted in 综合讨论 read more
  • ivy

    数据存储 schema 都是可以自定义的,分 pod 读取和存储就行了,不影响,非常解藕

    posted in 综合讨论 read more
  • ivy

    一套开发者友好的关联数据开发体验

    原文地址:https://ruben.verborgh.org/blog/2018/12/28/designing-a-linked-data-developer-experience/
    <br>
    翻译: SoLiD 中文网

    优化开发体验的目的是使关联数据的开发变得有趣。

    引言

    虽然语义网社区正在领域内努力奋斗,但我们未能吸引那些一线开发者:前端开发人员。具有讽刺意味的是,语义网爱好者未能专注于一线开发; 虽然我们的技术正在为专业的后端系统提供生产力,但未实现面向普通用户的应用程序。在分布式 Web 应用程序的 Solid 生态中,关联数据和语义网技术发挥着至关重要的作用。在过去的一年里,我坚定地致力于 Solid,我意识到设计一个开发者友好的开发体验对于它的成功至关重要。 通过与前端开发者交流后,我创建了几个 JavaScript 库,这些库可以帮助开发者轻松地与复杂的关联数据进行交互,而无需了解 RDF。 这篇文章介绍了 Solid 的 React 组件以及 LDFlex 查询语言,以及从他们的设计中吸取的经验教训。

    在 2000 年左右,一种新的网络分工以越来越复杂和专业化的趋势悄然出现:homo developerensis frontendicus,通常被称为前端开发者。它们通常有两个与其他开发者不同的地方:与喜欢与机器交互的后端开发人员(backendicus)相比,前端开发人员倾向于与普通人进行更多交互(也就是进行人机交互设计)。虽然许多后端开发人员会用他们对 Perl 的深刻理解挑战你,并尝试用 Java Spring XML 配置文件给潜在的合作伙伴留下深刻印象。但前端开发者常常不认为他们是伟大的开发者,因为他们的工作比较无趣。前端开发者构建人们想要和喜欢的东西;而后端开发人员使他们能够轻松完成。

    随着分布式系统的出现,语义网技术可以在解决数据互操作性方面发挥关键作用。 特别是,表示知识的关联数据非常适合在分布式网络中存储和编程。但是,我们的技术栈并不是特别适合开发者。在语义网和 RDF 社区建立之后,前端开发者在社区中展现出了超出常人的活跃度,但我们犯了很大的错误,因为我们忽略了他们的存在 - 即使它们远远超过我们。我们正在坚持 Java 的范式,如 RDF / XML 和Turtle,并拼命地试图说服世界他们错了,我们是对的,他们应该关注我们。

    事实证明确实是我们错了。

    你猜怎么着?如果我们不遵循它们,那么我们将成为过时的人。我们的错误在于我们没有关注 Web 的发展方向。如果我们不改变方向,使 Web 重新去中心化的使命可能最终缺乏足够的数据集成而导致失败。

    前端开发者 - 图片

    Front-end developers determine how people interact with technology. ©2018 Honeypot

    今年早些时候,我在 GraphQL Day 非常清楚地看到了前端开发者的重要性。不知何故,一种查询语言已经成功地聚集了一个房间的人,这些房间里有很多有趣的人在使用 GraphQL 查询各种数据,并在此基础上构建漂亮的应用程序。GraphQL 被称赞(错误地)作为 REST 架构的替代品,并且一些人低估了其他解决方案的复杂性,例如语义网的查询语言 SPARQL。具有讽刺意味的是,我了解了将会大大复杂化并重塑 GraphQL 的未来计划,这是为了能够涵盖 SPARQL 多年来积累的基础技术。

    但是,责怪 GraphQL 或前端开发社区是非常错误的。多年来,我们已经使用Linked Data,RDF 和 SPARQL 获得了金牌,但我们未能覆盖那些能够将其带给终端用户的人。这是我们的失败,和其他人无关。

    我坚信我们应该将语义网带到 Web 上。 我们需要为前端开发人员提供工具和库。这就是为什么自从加入语义网社区以来,我花了很多时间从头开始为浏览器创建 JavaScript 库,只有这样我们才可以在 Web 上实现语义网。如果我不坚持这样做,我会更快地推进,但是我建造的东西永远不会到达终端用户。

    但是,到目前为止,我还没有为前端开发人员撰写文章:我的库提供了一个关键数据的底层结构。它们暴露了 RDF 三元组,这是一个单独的分支,而不是开发人员熟悉的 JSON 树。大多数开发人员不想要 RDF,他们是对的。我们应该为分布式 Web 应用程序提供良好的开发体验,这些开发工具应该屏蔽 RDF 的底层复杂性但能提供关联数据的优势

    为什么要使用关联数据(Linked Data)?

    去中心化 Web 应用拥有多个后端

    第一个关键的问题是分布式 Web 应用是否需要关联数据。为什么不像其他 Web API 一样,服务器发送客户端可以轻松解析的自定义 JSON?Solid 中的分布式想法是应用程序没有自己的数据存储,而是将数据存储在用户选择的位置。因此,应用程序需要更加灵活,以便与不同的后端兼容。多个应用程序可能同时使用多个后端。例如,社交媒体应用中的数据可以存储在不同的位置。

    smb-img

    举个例子,如果你想对一篇文章点赞,那么需要以下两点:

    1. 你需要一种方法将你的“点赞”和文章做关联。
    2. 你的喜欢需要具有普遍含义(语义),因此不同的应用可以使用它。

    Web API 目前使用的自定义 JSON 解决这些问题并不容易。

    关联数据使 Web 应用独立于特定的后端

    关联数据(Linked Data)使用链接解决这个问题。在关联数据中,“点赞”和“文章”都将有一个链接,比如:

    1. 文章可能是:https://articles.org/posts/1234
    2. 点赞可能是:https://you.example/likes/2019/02#like-on-post-1234

    所以“点赞”和“文章”的连接方式是:

    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "actor": "https://you.example/profile#you",
      "type": "Like",
      "object": "https://articles.org/posts/1234", // 文章地址
      "published": "2018-12-28T10:00:00Z",
      "id": "#like-on-post-1234" // 点赞
    }
    

    由于像 type, object, actor 类似的单词在不同的应用中有不同的含义,关联数据将始终使用 链接(links) 来建立一个通用含义。上面的代码片段中有一个 @context 键,这个键使得 actor 指代 https://www.w3.org/ns/activitystreams#actor。这也叫 JSON-LD (JSON Linked Data) 上下文(Context)

    但通过抽象层进行抽象后,你不用了解上述任何内容。

    下面两章会详细探讨 React关联数据表达式的使用方法,主要针对 JavaScript 开发者,如果你不感兴趣可以跳过。

    Solid React 组件

    选择一个语言和框架

    在设计开发者友好的开发框架时,第一个问题是要定位的语言和框架,JavaScript 和 React 在 2018 年的 JavaScript 生态中成为明显的赢家。对于一般的框架我并不是特别兴奋,因为它们的受欢迎程度上升和下降得如此之快,以至于没有一个被认为是安全的赌注(还记得 jQuery 吗)。尽管从未学过 React,但我发现很容易调整代码来兼容 React,所以我很好奇并开始探索。然后我开始编写自己的组件来简化一些重复的 Solid 身份认证代码。当我发现高阶组件(HoC)时,我完全迷上了构建 React 组件库的禅道。

    然而,我和 Solid 团队都没有和 React 完全绑死,我们还会留意其他当前和即将到来的框架。重要的是,许多经验教训(以及一些生成的库)可以直接应用于其他框架。

    可以在 GitHubNPM 上找到 Solid 的 React 组件。

    登录和退出

    Solid 的第一类 React 组件提供身份认证功能。虽然不是特定于关联数据,但身份认证对于在分布式网络中获取私有数据至关重要。与 Facebook 和其他社交网络相比,Solid 网络中不使用实体按钮登录。相反,人们使用自己的数据窗口登录,该数据窗口可以驻留在 Web 上的任何位置。因此,一致的登录体验至关重要,但我注意到,连接我们现有的身份认证库可以轻松地使用十几行代码完成。通过将这些行减少到单个组件,开发人员可以重用经过良好测试的解决方案。以下是结果代码的片段:

    <LoggedOut>
      <p><LoginButton popup="popup.html" /></p>
      <p>你已退出,这是一个不受保护的区域</p>
    </LoggedOut>
    <LoggedIn>
      <p>你已登录,可以看到受保护的特殊内容</p>
    </LoggedIn>
    

    有趣的是,Solid React 库不仅仅是提供组件:它也使开发人员能够轻松构建自己的 Solid 组件。 例如,上面的 <LoggedIn> 组件有一个简单的实现:它不是必须自己调用身份认证库,而是包含在 withWebId Helper 中。 此帮助程序将 webID 属性传递给 <LoggedIn> 组件,该组件包含已登录用户的标识。所有 <LoggedIn> 需要做的是检查是否已设置其 webID 属性,并且仅在这种情况下,呈现其内容。开发人员构建自己的涉及身份认证的 Solid 组件可以简单地重用 withWebId 高阶组件,而不必担心它是如何工作的。

    展示关联数据

    第二类 React 组件提供了硬核的功能:轻松访问关联数据。在以前,即使是非常简单的任务,例如显示登录用户的名字,也需要几行很不直观的代码,并要求开发人员理解 RDF 的细节,这是有难度的。

    在 React 中,用一个组件代替了这些有复杂度的代码:

    <p>Welcome, <Value src="user.name" /></p>
    

    <Value> 组件显示通过 src 属性标识的一段 Linked Data 的值。与身份认证一样,这是通过名为 evaluateExpressions 的高阶组件实现的,这样开发人员可以轻松创建自己的 Linked Data 组件。你需要做的就是使用 evaluateExpressions 包装你的组件,并指出哪些属性可以包含Linked Data 表达式(在本例中为 src)。然后将这些表达式计算为值,并将这些值传递给你的组件。

    比如,假如我们定义了一个 <Span> 组件:

    const Span = evaluateExpressions(({ src }) =>
                   src ? <span>{src}</span> : <em>pending</em>);
    

    那么我们可以传递 src 属性给他:

    <p>Your first name is <Span src="user.firstName" />.</p>
    

    这个 src 属性将被 evaluateExpressions 转换为实际值,这样渲染的值将变为:

    <p>Your first name is Ruben.</p>
    

    该库包含一些非常方便的组件,可以通过各种方式显示关联数据:

    <LoggedIn>
      <p>Welcome, <Value src="user.firstName" /></p>
      <Image src="user.image" defaultSrc="profile.svg" />
      <ul>
        <li><Link href="user.inbox">Your inbox</Link></li>
        <li><Link href="user.homepage">Your homepage</Link></li>
      </ul>
      <h2>Your friends</h2>
      <List src="user.friends.firstName" />
    </LoggedIn>
    

    如果您将上述代码与使用关联数据的基于 RDF 和三元组的方式进行比较,你会注意到它简化了很多事情。着不仅适用于前端开发人员,也适用于想要构建关联数据Web 应用的所有人。例如,考虑使用 jQuery 和 RDFlib.js 或使用 React 组件实现的 Solid 个人资料查看器。前者需要理解 RDF 和本体,而后者仅需理解 React 和 Linked Data 表达式。此外,React 实现的身份认证和数据组件经过严格测试,因此生成的应用程序具有更强的质量保证

    比较一下,这是以前繁杂的代码:

    const store = $RDF.graph();
    const fetcher = new $RDF.Fetcher(store);
    const fullName = store.any($RDF.sym(user), FOAF('name'));
    $('#fullName').text(fullName && fullName.value);
    

    我想以这种方式书写:

    <Value src="user.name" />
    

    绝对更有趣和更健壮。如果一件事复杂度很高,那么人们很可能本能的抗拒。因此,这将导致 Solid 永远不会和终端普通用户产生联系,或者在最坏的情况下,根本不会有 Solid 应用。这更加突出了设计开发者友好的关联数据开发体验是多么重要。

    LDFlex:通过 JavaScript 查询 Web 网络

    简单数据需要简单的表达式

    你可能已经注意到,上面 React 组件易于使用的地方是它可以方便地检索互联数据。使用一种名为 LDFlex 的查询语言——我为此创建了该语言。 LDFlex 是 JavaScript 的领域专用语言(dsl),这意味着它的所有表达式最终都会被转化为 JavaScript 对象。

    LDFlex 是我提出的一种解决方案,用于满足开发者在构建应用时快速获取数据的需求。比如获取用户名或主页等内容时,开发者无需再写很多行代码,也不必使用硬编码方式。LDFlex 通过简洁的表达式满足这些需求,通过浏览器中的 solid.data 暴露到全局:

    const name = await solid.data.user.firstName;
    const email = await solid.data.user.email;
    for await (const friend of solid.data.user.friends.firstName)
      console.log(friend);
    

    上面几行代码内部到底做了什么?虽然它看起来像遍历本地对象,但每次我们等待 LDFlex 表达式时,我们实际上都在查询 Web。以下是 LDFlex 表达式 solid.data.user.friends.firstName 背后发生的事情:

    1. 获取当前用户的 WebID URL。
    2. 将 friends 和 firstName 解析为其唯一标识符。
    3. 将表达式转化成一个 SPARQL 查询(例子)。
    4. 通过 http 获取根节点的文档(在本例中为用户的WebID)。
    5. 对文档执行 SPARQL 查询并返回结果。
      每当需要获取数据,这些步骤(或其变体)都需要开发者亲自实现。虽然可以把这些步骤抽象成函数,但是目前大部分开发者已经习惯了直接从对象中取数据。这样的代码长度比将 GraphQL 查询注入到 React 组件要短得多;事实上,表达式可以简单地写为内联属性。

    除了用户数据,你还可以在Web上查询任何互联数据资源:

    solid.data [ 'https://ruben.verborgh.org/profile/#me'].firstName
    solid.data [ 'https://ruben.verborgh.org/profile/#me'].homepage
    solid.data [ 'https://ruben.verborgh.org/profile/#me'].friends.firstName
    solid.data [ 'https://ruben.verborgh.org/profile/#me'] .blog.schema_blogPost.label
    

    这些表达式可以单独使用,也可以作为Solid React 组件的 src 属性中的值使用(为简洁起见,省略了 solid.data)。这些表达式不光只能用在React里。例如,如果你想用 Angular 或 Vue.js 构建,LDFlex 也会派上用场。

    让“开发体验”好一点

    我见过的几个比较旧的库,将 Linked Data 资源进行特定的面向对象包装。你给他们一个文件的 url,他们会为你提供一个人物,照片或任何其他特定领域概念的 JSON 对象。这种方法有几个缺点:

    1. 这些库只能用于特定一类事物。如果你正在处理不同类型的数据,则无法使用它们。这很不对劲,因为互联数据可以为任何东西建模。
    2. 他们假设对象具有一组特定的属性。这是一个最大的限制,因为互联数据中的数据结构是任意的。
    3. 他们通过将互联数据扁平化为本地对象来删除链接。但是,该对象不可能包含所有数据,因为关联数据遍布整个 Web。
    4. 换句话说,通过将互联数据降级为普通的 json 对象,我们失去了互联数据的优点和灵活性,并且只继承了缺点。发生这种情况是因为 JSON 对象是树,而 Linked Data 是图。因此,关联数据的纯面向对象抽象在设计上就是失败的。

    在设计 LDFlex 时,我一直在寻找一种抽象方式,能够释放互联数据的力量和“感觉”,同时仍然让开发者熟悉。这就是为什么 LDFlex 表达式感觉像本地 JSON 对象,而实际上不是。仔细体会下面这种形式的表达式:

    solid.data['https://ruben.verborgh.org/profile/#me'].label
    

    你可以使用任何其他互联数据资源替换我的WebID网址,它仍然有效。因此 solid.data 构成一个具有无限属性的对象,这更接近于互联数据的真实本质。

    当我们使用 JavaScript await关键字时,会发生从本地表达式到远程数据源的神奇切换:

    //执行到下面这一行还什么也没做
    const expression = solid.data.user.friends.name;
    // ...但下面这行将从Web获取数据
    const name = await expression;
    

    实现原理:JavaScript Proxy 和 JSON-LD

    LDFlex 通过 JavaScript 代理对象工作,它提供拦截任意属性的机制。使用 Proxy,我们可以确保任意复杂的路径(如 my.random.path.expression)会被解析为有意义的值,即使 my 对象实际上没有任何这些属性。

    回想一下,对于 Linked Data,术语具有普遍含义,因此它们可以跨越不同的后端。因此,LDFlex 的核心任务是将简单的术语翻译成 URL。例如,solid.data 上的路径 user.friends.firstName 将通过以下方式解析:

    1. user变为:https://you.example/profile#you(当前用户的 WebID)
    2. friends变成:http://xmlns.com/foaf/0.1/knows
    3. firstName成为:http://xmlns.com/foaf/0.1/givenName

    至关重要的是,这些转换并没有硬编码到 LDFlex 本身。从术语到 URL 的转换可以通过 JSON-LD context 自由配置。因此,LDFlex 将这种使用 @context 标记 json 对象的机制应用于 Web 上无限的互联数据。这种灵活性是通过多个库实现的:

    LDFlex 核心库包含解析和查询机制,但是并没有具体实现。它知道如何解析路径并生成 SPARQL 查询,但你仍然需要使用 JSON-LD context 和查询引擎进行配置。

    Comunica for LDFlex 可以让 Comunica 查询引擎与 LDFlex 表达式一起使用。LDFlex 核心库将给 Comunica 传递一个 SPARQL 查询以供执行。

    LDFlex for Solid 是 LDFlex 的一套配置,它提供 user object 和包含 Solid 专用术语的 JSON-LD context。因此,此配置定义了 user,friends 和 firstName 对 Solid 应用程序的含义。

    它们合在一起,共同提供了一种感觉——拥有无限属性的本地对象,可以访问整个 Web 上的互联数据。LDFlex 核心库实现了 await和 for await 支持,就这点魔法。当 await 用于 LDFlex 表达式时,表达式被视为 Promise,内部实现就是调用 then 方法。LDFlex 将到查询执行的第一个结果通过 then 方法向外传递。同样,for await被包装成对 Symbol.asyncIterator 的方法调用。

    在 Solid LDFlex playground 探索 LDFlex。你可以在 Solid LDFlex 文档及其 JSON-LD context 中找到表达式的灵感。

    未来就是对 Web 的读写

    Solid 旨在通过互联数据实现读写 Web。作为 Inrupt 的技术倡导者,我在优化开发体验方面来支持这一目标。在我之前的博客文章中,我指出了查询在去中心化应用程序的重要性,因为应用程序不会(也不应该)知道如何检索数据。 LDFlex 通过简单的查询表达式实现了这一点。虽然 LDFlex 不是所有查询需求的解决方案,它覆盖了许多场景下快速查询的案例,写起来比其他查询语言更快。

    在未来,我们肯定希望探索更强大的语言,如 GraphQL。我故意不提 SPARQL,因为 GraphQL 的开发者工具要好得多,将 GraphQL 通用化,而不是从头开始构建 SPARQL 工具可能更有意义。

    LDFlex 的下一个飞跃显然是写入:使添加或更改数据像读取数据一样容易。由于互联数据的灵活性,写入数据带来了一些挑战,例如在哪存储数据,如何存储数据。编写互联数据并不意味着编写三元组,正如以下例子所示(亲自尝试一下!):

    // 关注我
    solid.data [ 'https://ruben.verborgh.org/profile/#me'].follow()
    // 为我的所有博客文章点赞
    solid.data [ 'https://ruben.verborgh.org/profile/#me']
    .blog.schema_blogPost.like()
    // 给 Facebook 拍砖
    solid.data [ 'https://facebook.com/'] .dislike()
    

    当点赞变得像调用like()方法一样简单时,这种调用方式对开发者友好,因此考虑优先提供。

    发展去中心化应用的开发者体验

    在他2018年的技术回顾中,AndréStaltz 表示,虽然在治理和自由方面得分很高,但去中心化的项目仍然需要注重用户体验(UX)。在这篇博客文章中,我认为去中心化开发的社区应该首先关注开发者体验(DX),因为前端开发人员是那些接触最终用户并塑造他们体验的人。我们应该相信,他们创造卓越的用户体验的才能远远超过我们。

    因此,问题在于我们怎样才能最好地为前端开发人员铺平道路。Dan Brickley 和 Libby Miller 在撰写时写道:

    人们认为 RDF 是一种痛苦,因为它很复杂。事实更糟。RDF 非常简单,但它允许你处理非常复杂的现实数据和问题。

    但是,这并不意味着每个人都需要接触到 RDF。除了去中心化编程的可怕复杂性之外,RDF 引入了一种不同的思维方式,我们不应该将它强加在前端开发人员身上。相反,我们应该释放前端开发者们已有的大量知识,融入他们的框架和工具。

    我们对前端开发者唯一的要求就是理解互联数据。试图将互联数据包装在简单的 JSON 对象中会丧失去中心化生态系统的优势。不要低估了前端开发人员走出舒适区域的意愿。根据我的经验,互联数据激发了以前从未见过它的开发人员,因为他们突然可以访问整个 Web 数据,而不只是从一个后端。它开辟了巨大的机会,因为他们不再依靠收获数据来建立一些不错的东西。

    这些开发人员不会受到过去语义 Web 错误的影响,例如我们过度依赖 XML 和本体。我们不会尝试重新启动语义 Web,也不会再迫使开发人员进入我们的世界。这是关于互联数据作为构建去中心化应用程序的解决方案。 Schema.org 的成功表明这些解决方案还有发展空间,我看到了在 Solid 世界中迈出第一步的年轻开发人员的热情。这就是未来,而不是过去。

    重要的是,React 和 LDFlex 库不仅为前端开发人员提供了构建终端用户应用程序的工具。它们还包含了一些基本组件用来创建新的库和工具。我们的目标应该是培养这些生态系统,而不是自己编写一切。

    通过支持前端开发人员,我们开辟了一条创新高速路,使去中心化的 Web 能够更快,更好地覆盖终端用户。而且,我们可以使用相同的库和工具来加速我们自己的开发。因此,我们从一大批新人中获利,同时能够更好地利用我们自己的人才。帮助前端开发人员就是帮助用户,并最终实现自我。

    原文地址:https://ruben.verborgh.org/blog/2018/12/28/designing-a-linked-data-developer-experience/
    <br>
    翻译: SoLiD 中文网

    posted in 综合讨论 read more
  • ivy

    贡献说明

    The Goal

    Our goal is not to have the biggest list of everything available out there.
    Our goal is to have a list of things that anybody would have to learn if they were to enter the field today.

    Contributing

    Your contributions to this repo are always welcome!
    Bear in mind, that this repo is highly opinionated, unbiased and curated.
    Your opinion on value of any resource may not match the opinion of curator.

    No PR will be discarded without explanations!

    How are these roadmaps made?

    Roadmaps are made using Balsamiq

    • Clone the repository
    • Open Balsamiq, click <kbd>Project > Import > Mockup JSON</kbd>,
    • Copy and paste the JSON for the roadmap that you want to update
    • Add your changes
    • Export the JSON file <kbd>Project > Export > Mockup to JSON</kbd> and put it in the <kbd>project</kbd> directory
    • Export the image <kbd>Project > Export > Current Mockup to PNG</kbd> and put it in the <kbd>images</kbd> directory
    • Commits your changes and open a PR

    Guidelines

    • <p><strong>Adding everything available out there is not the goal!</strong><br>
      The roadmaps represents the skillset most valuable today i.e. if you were to enter any of the listed fields today, what would you learn! There might be things that are of-course being used today but prioritize the things that are most in demand today e.g. agreed that lots of people are using angular.js today but you wouldn't want to learn that instead of React, Angular or Vue. Use your critical thinking to filter out non-essential stuff. Give honest arguments for why the resource should be included.</p>
    • <p><strong>One item per Pull Request</strong><br>
      There may be a discussion related to an item you want to add. Adding just a single item per pull request makes it much easier for everyone involved.</p>
    • Write meaningful commit messages
    • Look at the existing issues/pull requests before opening new ones

    posted in 综合讨论 read more
  • ivy

    Solid 中文网发布全球首个 Solid 学习路线图。
    请参考:https://github.com/LearnSolid/solid-roadmap

    posted in 综合讨论 read more
  • ivy

    SoLiD 官方提供了一套设计范式,地址为:https://design.inrupt.com

    posted in Solid 资讯 read more
  • ivy

    初始版本侧重于 React SDK 和 Application Generator 的核心基础架构。 后续版本中的组件将作为该版本的一部分合并到生成器中。

    原文:https://github.com/Inrupt-inc/solid-react-sdk/blob/master/README.md#release-timeline

    APP 生成器:https://github.com/Inrupt-inc/generator-solid-react

    附上一个 Release Timeline:

    Release Timeline

    We follow an iterative release pattern, and will have scheduled releases every two weeks. Releases may include new components, as well as improvements or fixes to existing ones.

    Date of Release (2019) Targeted for Release Notes
    January 30th ✅ Application Generator, User Authentication, User Registration, Design System, Accessibility, Test Infrastructure, Error Handling Initial release focused on standing up the core infrastructure of the SDK and Application Generator. Components in subsequent releases will be incorporated into the generator as part of that release.
    February 13th Linked Data Javascript API, User Profile Reading and writing Linked Data associated with a User Profile using LDFlex, as well as other examples of how to read and write Linked Data with Forms.
    February 27th Internationalization, User Preferences Weaving in i18n and Preferences.
    March 13th Notifications Reading and writing notifications, with real-time support over websockets.
    March 27th Access Control Helpers and componentry for reading and writing WAC statements
    April 10th Linking Things, Data Discovery An approach for universal data discovery, and intuitive examples of how to create a linked data graph for use in your applications.

    posted in Solid 资讯 read more
  • ivy

    https://ruben.verborgh.org/articles/redecentralizing-the-web/

    介绍了 Web 的全部历史和 Solid 的愿景,非常清晰。

    posted in 综合讨论 read more
  • ivy

    @creator 美国人还是专注于在美国交流,很多中文论坛的人也倾向于去美国论坛问,我太忙了,很多问题没法解答

    posted in 意见建议 read more