5

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

经过大量的头脑风暴、草拟想法和模型、写笔记和阅读大量有关 RDF 和相关主题的内容后，我终于想出了一份计划草案。

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

我的程序由两部分组成：

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

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

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

所以这是我心中的问题：

1) 我应该使用哪个 URI 方案？我没有网站或任何网页，所以使用 http 没有意义。使用任何其他标准 IANA 注册的 URI 似乎也没有意义。我一直在考虑两种选择：对公共资源使用一些自定义的、我自己的 URI 方案名称，对私有资源使用裸 URN，如下所示：

urn : random_name_i_made_up : some_private_resource_uuid

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

2）如何隐藏私有资源？一方面，URI 告诉任务来自哪里可能非常有用，尤其是当任务在人们之间共享和委派时。另一方面，它不考虑隐私。然后我在想，我可以/应该根据用户设置使用两种不同的 URI 样式吗？这会造成一些不一致。我不确定在这里做什么，因为我对 URI 没有任何经验。希望你能给我一些建议。

4

1 回答 1

3

1) 我应该使用哪个 URI 方案？

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

2）如何隐藏私有资源？

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

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

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

于 2013-05-31T00:00:34.647 回答