将URI分配给RDF资源

时间:2013-05-29 18:11:16

标签: uri rdf language-design ontology privacy

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

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

我决定做的第一件事是定义我给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。希望你对我有一些建议。

1 个答案:

答案 0 :(得分:3)

  

1)我应该使用哪种URI方案?

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

  

2)如何隐藏私人资源?

不要使用不同的标识符方案。试图将授权和访问控制烘焙到身份方案中的方法是将这些层混合在一起,这将导致您将来感到痛苦。例如,如果用户将一些当前私有内容(例如草稿)公开(现在以其可发布的形式),会发生什么?

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

您可能还想考虑添加最多价值的位置。重新发明基本服务访问协议可能是一项有趣的练习,但如果您在基本服务级别重新使用标准组件,您的用户可能会获得更多价值,并且一旦用户实际访问了标准组件,您就可以集中精力创新和添加功能。内容对象。