问题标签 [iri]

我正在尝试合并两个本体以创建一个新的单一本体。为此，我应该如何指定新本体的IRI？它应该是新文件的路径还是某个 url？

这是我的代码：

创建的本体开始如下：

的值xmlns是文件的路径。但是，当我将 url 指定为新本体的 IRI 时，例如：http://www.semanticweb.org/ontologies/2015/11/productCatalog#，它给出了以下异常：

那么指定新本体的IRI的正确方法是什么？

来自 RFC-3986，第 2.5 节：

当一个新的 URI 方案定义了一个表示由通用字符集 [UCS] 中的字符组成的文本数据的组件时，数据应首先根据 UTF-8 字符编码 [STD63] 编码为八位字节；那么只有那些与未保留集中的字符不对应的八位字节应该进行百分比编码。例如，字符 A 将表示为“A”，字符 LATIN CAPITAL LETTER A WITH GRAVE 将表示为“%C3%80”，字符 KATAKANA LETTER A 将表示为“%E3%82%A2 ”。

那么在这里对 Unicode 字符进行 URL 编码的正确方法是什么？人们断言 IRI 中的非 ASCII 符号应先转换为 UTF-8，然后再进行百分比编码。

但是我找到了一个带有application/x-www-form-urlencoded Content-Type 的示例教育网络表单，我尝试使用四种浏览器（Firefox、Chrome Opera、IE）用一些非 ASCII 符号填充它，并查看了 POST 查询我进入了wireshark。原来 %H1H2%H3H4...%HkHk+1 符号的编码是提交表单时表单页面的编码。

所以对于字母“Ж”，如果表单页面编码设置为 UTF-8，我会得到 %0D96 但是，如果我切换到 8 位 Windows-1251，我会得到 %C6，如果我切换到 CP-1252 我会得到得到 %26%231046，其中 %26 是 &，%23 是 #，因此，我得到 'Ж': Ж 的 xml Unicode 编号，因为 CP-1252 中没有这样的字母。

所以我的问题是为什么浏览器不首先将 IRI 转换为 UTF-8，尽管 URL RFC 似乎需要它？

也许，这是因为http://是一个旧的 URI 方案？来自https://en.wikipedia.org/wiki/Percent-encoding：

通用 URI 语法要求提供 URI 中字符数据表示的新 URI 方案实际上必须表示来自未保留集中的字符而无需翻译，并且应该根据 UTF-8 将所有其他字符转换为字节，然后百分比编码这些值。此要求是在 2005 年 1 月随 RFC 3986 的发布而引入的。在此日期之前引入的 URI 方案不受影响。

所以说：在此日期之前引入的 URI 方案不受影响。 但这似乎是一个蹩脚的解释。

此外，这里https://unspecified.wordpress.com/2008/07/08/browser-uri-encoding-the-best-we-can-do/一个人发现了和我一样的问题，这个人试图解释它这都是关于模糊的 HTML 规范的方式。但我仍然无法理解 HTML 标准是如何出现在这里的。无论如何，请求都是由浏览器发出的，浏览器应该生成正确的 URI。

感谢您的关注。

上下文：我正在创建一个将其数据存储在 location.hash 中的应用程序。我想编码尽可能少的字符以保持最大的易读性。

正如此答案中所解释的，URL 的每个段的保留字符都不同。那么 URL Fragment/location.hash 具体有哪些限制呢？

相关文章： URL 中的 Unicode 字符

我有像 9625ea21a1bf1be22963576fcdfd863d 这样的字母数字 id 的数据。我可以说这也是一个 IRI（国际化资源标识符）或 URI 值吗？

所有 URI 示例都类似于 aaa.txt、aaa/bbb.html 或 protocol://aaa/bbb.ext#tag。

我想用前缀来表示这个 nt 文件：

我写入一个新的 nt 文件是：

但是当我在cmd中使用它来sparql时：

cmd中显示错误：

我也试过这个：

但它报告了相同的错误，我不知道如何解决它。

我应该如何修改才能正常？

任何帮助将不胜感激。谢谢！

在执行以下代码时

超时 900 wget --random-wait --tries=2 --timeout=90 --recursive --level=1 --no-parent --follow-tags=a \ --html-extension --convert-links - -restrict-file-names=windows --force-directories \ --reject jpg,JPG,jpeg,JPEG,gif,GIF,pdf,PDF,zip,ZIP,png,PNG,css,CSS,js,JS,mp4 ,MP4,wmv,WMV,mp3,MP3,aac,AAC,mpeg,MPEG,flv,FLV,m4v,M4V,wav,WAV,svg,SVG,exe,EXE,rar,RAR \ --local-encoding=UTF -8 --header="接受字符集：utf-8" \ www.google.com

我收到此版本不支持 IRI 错误。我的 wget 版本是 1.12。你能帮我解决这个问题吗

TL/DR：在为语义​​网定义新词汇时，为什么我们不应该更喜欢https:IRI？

语义网是围绕使用 IRI 来识别各种组件而构建的，无论是网页等资源还是所有权等抽象概念。我咨询过的每个来源都http:特别推荐使用 IRI，例如：

• 链接数据书（2011 年），
• 英国政府开放数据倡议（2010 年），
• W3C 关于 Cool URIs 的说明(2008)，以及
• W3C 关于 RDF 词汇表最佳实践的说明(2008)。

这让我有点吃惊。世界似乎正在​​从 HTTP 转向 HTTPS，但我知道没有使用https:IRI 的词汇，而且上面引用的文档都没有讨论这个问题。我可以找到关于为什么ftp:或urn:不太好的选择的讨论，但没有关于https:.

尽管语义网上的 IRI 主要是标识符而不是定位符，但有一个约定，即 IRI 是查找有关实体的更多信息的好地方，并且各种权威机构建议 303 重定向到 RDF 或 OWL 模式或其他描述性文档等文档信息。如果 IRI 是http:一个，则至少可以通过 HTTP 进行初始请求和重定向。即使 schema 内容没有任何机密性，它仍然存在以下问题：

• 它容易受到中间人攻击。恶意方可能会故意注入不一致的模式信息，这可能会影响应用程序做出的处理决策，从而可能导致 DoS 或以其他方式破坏用户体验。

• ISP 可能会自己做 MITM 以将广告注入内容。真的，他们不应该对非 HTML 内容执行此操作（好吧，他们根本不应该这样做，但这是另一回事），但这取决于 ISP 是否足够关心才能做到这一点。正如 Superfish 所展示的，这仍然可以通过 HTTPS 发生，但要困难得多。

• ISP 可能会跟踪该请求。用户正在使用咨询特定模式的应用程序这一事实本身就是有关客户的有价值的信息，这些信息可以出售给美国参议院最近投票通过使其合法化的广告商。人们越来越注重隐私，并希望尽量减少这种情况。当然 ISP 仍然知道您访问了哪个域，因为SNI 字段未加密，但我们仍然可以尽量减少数据泄露。

如果客户端支持，HSTS可用于确保后续访问直接通过 HTTPS，但这对仍然通过 HTTP 发出的初始请求没有任何作用。迄今为止，在 DNS 中加入类似功能的尝试都失败了，我怀疑部分原因是 DNSSEC 采用缓慢。我不知道任何其他可能缓解上述问题的技术措施。

这些考虑都向我表明，与定义新词汇https:相比，这是一个更好的选择。http:显然，如果您有一个已经使用的现有词汇表，情况就不同了http:，但这不是我感兴趣的情况。

但是我确定我不是第一个想到这个的人，所以我只能认为每个人仍然使用和推荐http:是有原因的。如果是这样，有什么缺点https:？任何人都可以指导我对此进行很好的讨论吗？据我所知，W3C 在这个主题上没有任何让我感到惊讶的东西。

例子：

我认为这是一个 IRI，也是一个 URI。（我对吗？）

我使用 OWL API 来解析它。在“IRI”类中，有一个方法getShortForm()，当我使用它时，我得到“ae689-790e-3525-9e3a-dac63f449a03”。

关于URI，我认为它的本地名称是“587ae689-790e-3525-9e3a-dac63f449a03”。我不太确定。事实上，我从别人的博客中知道“本地名称”这个词。我在 URI 的结构中找不到“本地名称”，如下所示。

所以，我有两个问题：

1. IRI 的缩写是什么？为什么示例的 shortForm 不是“587ae689-790e-3525-9e3a-dac63f449a03”？

2. URI 的本地名称是什么，示例的本地名称是什么？

我有一个没有版本的本体 IRI。如何添加或更新特定 OWL 本体的版本 IRI？

文件 IRI 的标准 ( https://www.rfc-editor.org/rfc/rfc8089 ) 区分了没有权限的文件 IRI [1] 和没有权限的文件 IRI [2]。

现代网络浏览器（在 Firefox 和 Chrome 上测试）会自动将 [1] 更改为 [2]。例如，当 [1] 出现在链接标签中时，所遵循的有效链接是 [2]。（RFC 文档中没有解释这样的重写规则。）

有谁知道为什么浏览器会这样做以及这是否符合标准？

这会导致关联数据设置中的实际问题，其中 [1] 和 [2] 表示不同的资源。