Solid 数据发现机制解析：基于 Type Index Registry 的 “Follow Your Nose“ 数据定位方案

【免费下载链接】solidSolid - Re-decentralizing the web (project directory)项目地址https://gitcode.com/gh_mirrors/sol/solid点击查看免费下载本文解读 SolidRe-decentralizing the Web去中心化 Web框架中的**应用数据发现Application Data Discovery**机制客户端如何从一个用户的 WebID 出发通过逐级跟随 HTTP 链接最终定位到该用户存储空间中与某个应用相关的数据资源与容器。文中将完整梳理 Type Index Registry类型索引注册表的组成、solid:publicTypeIndex/solid:privateTypeIndex两条谓词链路、solid:instance与solid:instanceContainer两种注册映射方式并结合仓库中相关提案给出可直接落地的 TurtleTTL数据示例。一、为什么要发现数据避免两难困境在 Solid 的去中心化数据模型中每个用户拥有独立的 Web 数据空间dataspace / root storage不同应用的数据散布在不同的容器container与资源中。当一个新应用例如通讯录管理应用被安装时它面临一个两难问题逐个提示用户选择每个相关实例或容器的位置——体验糟糕且要求用户理解底层存储结构遍历scan用户的整个数据空间/根存储逐个容器查找相关资源——代价高昂且可能触及用户不想暴露的私有区域。Type Index Registry 正是为打破这一两难而设计的注册表式发现机制它是按类型查目录而非全库扫描。客户端只需查询类型索引即可只获取它关心的那部分资源与容器。需要特别注意的是这里的**数据发现data discovery**不应与以下两种发现机制混淆原文明确区分应用配置发现Application Configuration Discovery见 app-discovery.md其通过space:AppIndex、solid:AppRegistration、solid:instanceIndex等谓词让应用发现自身配置/偏好数据的存放位置存储发现Storage Discovery从 WebID Profile 中定位用户拥有的所有存储storage的机制。类型注册表Type Registry在定位上主要作为一种库级Library发现机制。原文给出的建议是注册粗粒度的库类型——通常是那些与容器container相匹配的类型而不是应用写入的每一个 RDF 类RDF Class。这一粒度约束保证了注册表的可维护性与查询效率。二、数据发现工作流从 WebID 到数据位置的五个步骤Solid 客户端应用遵循以下工作流Workflow来发现用户数据空间中的数据位置。整个过程体现了 HTTP 领域经典的自描述思想——follow your nose顺着鼻子走即不依赖任何外部服务或中心化目录仅通过 HTTP 链接逐级导航以 WebID URI 为起点Solid 身份体系中的 WebID 是一个哈希型 URI如#me通常指代一个 FOAF Agent人/组织的身份标识获取 WebID Profile Document对 WebID 做取消哈希与局部标识fragment/localid的归一化处理后GET其背后的 profile 文档通常是一个 Turtle/RDF 文档记录该用户的公开信息解析 Profile 并加载扩展资料解析 profile 后进一步加载其中的Extended Profile资源包括 Preferences 文件以及任何owl:sameAs与rdfs:seeAlso链接指向的资源通常深入一层从 Extended Profile 提取注册表链接从扩展资料中提取两条关键的注册表链接——solid:publicTypeIndex谓词指向公开的Listed Type Index注册表solid:privateTypeIndex谓词指向私有的Unlisted Type Index注册表加载并查询类型索引按需加载一个或两个 Type Index 注册表文档查询其中应用关心的 RDF 类型solid:forClass所对应的数据位置。下面是一个 WebID Profile 的示例片段同时携带对两个类型索引资源的链接见>prefix solid: http://www.w3.org/ns/solid/terms#. # ... #me a foaf:Person; # Listed type index resource: solid:publicTypeIndex /settings/publicTypeIndex.ttl ; # Unlisted type index resource: solid:privateTypeIndex /settings/privateTypeIndex.ttl .从仓库结构看该工作流与 app-discovery.md 中的应用配置发现共用同一套起点与思路——都从 WebID Profile 出发逐级跟随链接只是关注的数据不同前者是应用数据后者是应用配置/偏好且后者还强调在解析公开 profile 时应一并抓取owl:sameAs、rdfs:seeAlso与space:preferencesFile链接深入一层。三、Type Index Registry两种索引资源的组成Solid Type Index Registry类型索引注册表由两个 Type Index 资源组成索引资源默认可见性默认创建位置默认 ACL资源类型Listed Type Index列出的类型索引公开可读/settings/publicTypeIndex.ttl公开可读 ACLsolid:ListedDocumentUnlisted Type Index未列出的类型索引仅所有者可读/settings/privateTypeIndex.ttl私有 ACL仅所有者可读solid:UnlistedDocument每个索引资源内部都包含若干注册条目registry entries这些条目将某个资源类型映射到用户数据空间中的某个位置即充当数据空间内按类型组织的目录页。3.1 注册条目Type Registration类型索引资源可以包含任意数量的solid:TypeRegistration类型语句它们将 RDF 类/类型class/type映射到用户数据空间/根存储中的位置。一个注册条目由以下核心谓词构成solid:forClass声明该注册所服务的 RDF 类type/class即应用关心的数据类型如vcard:AddressBook、sioc:Post映射位置的二选一谓词详见下文之一solid:instance或solid:instanceContainer。3.2 两种映射谓词instance 与 instanceContainer原文用两条谓词区分单资源与容器两种映射方式二者的消费方式截然不同solid:instance——将类型映射到一个单独的 Solid 资源上典型的例子是一个索引文档或目录列表类资源directory listing resource例如一个地址簿Address Book。客户端拿到该 URL 后直接获取该资源即可使用无需再遍历。solid:instanceContainer——将类型映射到一个Solid 容器上客户端拿到容器 URL 后必须列出list该容器才能得到该类型下的各个实例。也就是说映射到容器意味着类型下有多个实例需要进一步分页/枚举。以下是一个 Listed Type Index 资源的示例同时演示了两种谓词的用法# Maps the type vcard:AddressBook to an index document #ab09fd a solid:TypeRegistration; solid:forClass vcard:AddressBook; solid:instance /contacts/myPublicAddressBook.ttl. # Maps the type sioc:Post to a container #ab09cc a solid:TypeRegistration; solid:forClass sioc:Post; solid:instanceContainer /posts/.3.3 注册状态的迁移Listed ↔ Unlisted一个注册条目既可以存在于 Listed公开索引中也可以存在于 Unlisted私有索引中。更改注册的状态从 Listed 索引移到 Unlisted 索引或反之需要从原索引中**移除removing**该注册——通常通过基于 SPARQL 的 HTTP PATCH 操作完成在目标索引中**添加adding**该注册——同样通过 PATCH 完成。即在 Solid 的补丁协议下一次状态迁移对应两次 PATCH 写操作一删一增。这与仓库中 patch-directions.md 所探讨的 SPARQL/PATCH 操作方向一脉相承——Solid 对 RDF 资源内容的修改以原子化的 PATCH 为基本手段。四、Listed Type Index公开可发现的电话簿Listed Type Index列出的类型索引面向可被外部用户与应用发现的注册。原文以公开电话簿中的已列电话作比喻它公开地映射人名与电话号码、地址供任意一方查询。该索引具备如下属性通过solid:publicTypeIndex谓词从WebID Profile链接出来默认创建于/settings/publicTypeIndex.ttl默认拥有公开可读的 ACL资源类型为solid:ListedDocument。一个包含单个注册条目的 Listed Type Index 资源示例如下prefix solid: http://www.w3.org/ns/solid/terms#. # ... a solid:TypeIndex ; a solid:ListedDocument. #ab09fd a solid:TypeRegistration; solid:forClass vcard:AddressBook; solid:instance /contacts/myPublicAddressBook.ttl.注意这里索引文档自身用空节点声明为solid:TypeIndexsolid:ListedDocument即我是一个索引且我是公开索引双重声明而注册条目的哈希标识#ab09fd则是文档内的局部标识用于在同一文档中区分多个注册。五、Unlisted Type Index仅所有者可见的私有注册Unlisted Type Index未列出的类型索引面向对用户及其应用私有的注册服务于那些不公开可发现的类型。其属性如下通常通过solid:privateTypeIndex谓词从Preferences 文件或 Extended Profile 的其他私有部分链接出来——这与公开索引从 WebID Profile 直接链接形成对照默认创建于/settings/privateTypeIndex.ttl默认拥有私有 ACL仅所有者可读资源类型为solid:UnlistedDocument。一个 Unlisted Type Index 资源示例如下prefix solid: http://www.w3.org/ns/solid/terms#. prefix sioc: http://rdfs.org/sioc/ns#. # ... a solid:TypeIndex ; a solid:UnlistedDocument. #ab09cc a solid:TypeRegistration; solid:forClass sioc:Post; solid:instanceContainer /personal-diary/.该示例与前一示例形成了清晰的对照同样是sioc:Post类型在公开索引中映射到公开的/posts/容器而在私有索引中则映射到私密的/personal-diary/个人日记容器。这正是一类型多注册、按可见性分流的典型用法——一个类型可以同时在两个索引中注册指向不同位置由应用按需选择查询哪个索引。六、与其他发现机制的协同完整的发现拼图数据发现不是孤立的能力它与仓库proposals/目录下的其他提案共同构成 Solid 客户端的发现三件套数据发现本文主题定位应用数据资源与容器见>赞分享【免费下载链接】solidSolid - Re-decentralizing the web (project directory)项目地址https://gitcode.com/gh_mirrors/sol/solid点击查看免费下载相关推荐ClipIt默认快捷键大全7个组合键让操作效率翻倍ClipIt默认快捷键大全7个组合键让操作效率翻倍 ClipIt是一款强大的GTK剪贴板管理器通过合理使用快捷键可以显著提升日常操作效率。本文整理了CliSwift Package Registry PublishSE-0391 提案的发布命令、元数据与签名机制全解析Swift Package Registry PublishSE 0391 提案的发布命令、元数据与签名机制全解析 导读 本文以 Swift Evolutio文档上一篇探索未来远程桌面Wprs下一篇Open3D无障碍指南如何实现3D可视化辅助功能的终极兼容性创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考