uri - 将 URI 分配给 RDF 资源

Question

我正在使用 Gnome 技术编写一个桌面应用程序，并且我达到了
阶段我开始规划语义桌面支持。

经过大量的头脑 Storm ，草拟想法和模型，写笔记
并阅读了很多关于 RDF 和相关主题的内容，我终于想出了一个
计划草案。

我决定做的第一件事是定义我给 URI 的方式
资源，这就是我想听听你的建议的地方。

我的程序由两部分组成:

1) 在较低级别上，定义了一个 RDF 模式。这是一套标准的
类和属性，可能由需要更多选项的用户扩展
(使用翻译成 RDF 的定义语言)。

2) 在高层次上，用户使用这些类定义资源和
特性。

低层没有问题，因为数据模型是
public:即使用户决定添加新内容，她也非常欢迎
分享它，让其他人的应用程序有更多的功能。问题是
与第二部分。在更高级别，用户定义任务，
session 、约会、计划和时间表。这些可能是私有(private)的，并且
用户可能更喜欢在 URI 中包含任何信息来揭示来源
的信息。

所以这是我心中的问题:

1) 我应该使用哪个 URI 方案？我没有网站或任何网络
页面，所以使用 http 没有意义。它似乎也没有
感觉使用任何其他标准 IANA 注册的 URI。我一直
考虑两个选项:使用一些自定义的、我自己的 URI 方案名称
公共(public)资源，并为私有(private)资源使用裸 URN，例如
这:

urn : random_name_i_made_up : some_private_resource_uuid

但我想知道自定义 URI 方案是否是一个好的决定，我是
愿意听取您的意见:)

2)如何隐藏私有(private)资源？一方面，它可能非常有用
让 URI 告诉任务来自哪里，尤其是当任务来自
人们之间共享和委托(delegate)。另一方面，它不
考虑隐私。然后我在想，我可以/应该使用两种不同的
URI 样式取决于用户设置？这会产生一些
不一致。我不知道在这里做什么，因为我没有
使用 URI 的经验。希望你能给我一些建议。

Answer 1

1) Which URI scheme should I use?

我会建议标准 urn:uuid:后跟您的资源 UUID。使用标准通常比本土解决方案更受欢迎!

2) How to hide the private resources?

不要使用不同的标识符方案。试图将授权和访问控制融入身份方案是在以某种方式混合这些层，这势必会在 future 给您带来痛苦。例如，如果用户将一些当前私有(private)的内容(例如草稿)公开(现在处于可发布的形式)会发生什么？

拥有一个统一的标识符解决方案，然后提供一个或多个服务，这些服务可能会或可能不会将给定的标识符解析为文档，具体取决于上下文(用户身份、有关内容本身的元数据等)。是的，这很像 HTTP 服务器所做的，因此您可能需要重新考虑是否在您的架构中嵌入 HTTP 服务。如果不是，您需要的服务将与 HTTP 有许多相似之处，您只需要清楚在哪些情况下可以将标识符解析为文档，当不可能或不允许时会发生什么等。

您可能还想考虑要在哪里增加最大的值(value)。重新发明基本服务访问协议(protocol)可能是一个有趣的练习，但是如果您在基本服务级别重用标准组件，您的用户可能会获得更多值(value)，并且一旦用户真正可以访问，就可以专注于创新和添加功能内容对象。