分配URI来RDF资源

Question

我使用GNOME技术编写桌面应用程序，我达到了 阶段，我开始策划语义桌面支持。

经过大量的头脑风暴，素描思想和模型，写作笔记 ，并阅读了很多有关RDF和相关主题，我终于想出了一个 计划草案。

我决定做的第一件事就是定义我给URI提供URI的方式，这就是我希望听到你的建议的地方。

我的程序由两个部分组成：

1）在较低的水平，RDF模式被定义。这是一组标准的 类和属性，可能由需要更多选项的用户扩展 （使用定义语言转换为RDF）。

2）在高电平时，用户定义了使用的那些种类和性质 资源。

下级没有问题，因为数据模型为 public：即使用户决定添加新内容，她也非常欢迎 分享它，并让其他人的应用具有更多功能。第二部分是问题 。在较高级别，用户定义任务，会议，约会，计划和日程安排。这些可能是私人的，并且用户可能更喜欢在URI中具有任何信息以揭示信息的来源 。

因此，这里有我的心里也有疑问：

1）我应该使用哪一个URI方案？我没有网站或任何网页，因此使用http没有任何意义。它似乎也没有使用任何其他标准的IANA注册的URI。我一直在考虑 两种选择：使用一些自定义的，我自己的，URI方案名称 公共资源，并使用私立的裸URN，像这样 ：

urn : random_name_i_made_up : some_private_resource_uuid 

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

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

Answer 1

1）我应该使用哪种URI方案？

我会建议标准urn:uuid:，然后是您的资源UUID。使用标准通常比本地解决方案更受欢迎！

2）如何隐藏私有资源？

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

有一个单一的，均匀的标识符溶液，然后提供可以或可以不解决给定标识符的文件的，根据上下文的一个或多个服务（用户身份，有关内容本身的，等等等等元数据）。是的，这很像HTTP服务器可以做的，因此您可能需要重新考虑是否在架构中使用嵌入式HTTP服务。如果没有，你需要将有许多相似之处HTTP服务，你只需要明确其中标识符可以解析为一个文档的情况下，当要么是不可能或不允许发生的事情，等

您可能还想考虑要增加哪些价值。重新发明基本服务接入协议可能是一个很有趣的事情，但如果你在基本服务水平再使用标准组件的用户可能会获得更多的价值，而不是专注于创新和增加功能，一旦用户实际上可以访问内容对象。