cfa*_*771 5 rdf uri privacy language-design ontology
我正在使用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经验.希望你对我有一些建议.
1) 我应该使用哪种 URI 方案？
urn:uuid:我建议您的资源 UUID 遵循的标准。使用标准通常比本土解决方案更受青睐！
2）如何隐藏私有资源？
不要使用不同的标识符方案。尝试将授权和访问控制融入到身份方案中会以一种混合各层的方式，这注定会在未来给您带来痛苦。例如，如果用户将一些当前私有的内容（例如草稿）公开（现在处于可发布的形式），会发生什么？
拥有一个统一的标识符解决方案，然后提供一项或多项服务，这些服务可能会也可能不会将给定标识符解析为文档，具体取决于上下文（用户身份、有关内容本身的元数据等）。是的，这很像 HTTP 服务器所做的事情，因此您可能需要重新考虑是否在架构中嵌入 HTTP 服务。如果不是，您需要的服务将与 HTTP 有很多相似之处，您只需要明确标识符可以解析为文档的情况，当不可能或不允许时会发生什么，等等。
您可能还需要考虑要在哪里增加最大价值。重新发明基本服务访问协议可能是一个有趣的练习，但是如果您在基本服务级别重用标准组件，并且在用户实际访问该协议后专注于创新和添加功能，您的用户可能会获得更多价值。内容对象。