SPARQL - 找到本体需要什么？
我对 SPARQL、OWL 和 Jena 还很陌生，所以如果我问的问题非常愚蠢，请原谅。我遇到了一个问题，几天来一直让我发疯。我使用以下字符串作为 Jena QueryFactory.create(queryString) 的查询，
queryString = "PREFIX foaf: <http://xmlns.com/foaf/0.1/>"+
"PREFIX ho: <http://www.flatlandfarm.de/fhtw/ontologies/2010/5/22/helloOwl.owl#>" +
"SELECT ?name ?person ?test ?group "+
"WHERE { ?person foaf:name ?name ; "+
" a ho:GoodPerson ; "+
" ho:isMemberOf ?group ; "+
"}";
直到今天早上，只要我只从 foaf 命名空间请求属性，它就可以工作。当我从自己的命名空间请求属性时，我总是得到空结果。当我正要在这里发布这个问题并做了一些最终测试以便能够尽可能精确地发布它时，它突然起作用了。因此，由于我不知道到底要问什么，所以我在发布之前删除了我的问题。几个小时后，我使用 Protege 的 Pellet 插件创建并导出推断模型。我将其命名为 helloOwlInferred.owl 并将其上传到服务器上 helloWl.owl 所在的目录。我调整了加载推断本体的方法，并更改了上述查询，以便将前缀 ho: 也分配给推断本体。立刻，一切都不再起作用了。确切地说，它不再有效，但它与我直到今天早上最初的查询所遇到的症状相同。我的前缀不再起作用了。我做了一个简单的测试：我将所有 helloWorldInferred.owl 文件（我的服务器上的前缀文件和我加载的本地副本）重命名为 helloWorld.owl。奇怪的是，一切都解决了。
将其重命名回 helloWorldInferred.owl 再次破坏了一切。等等。那里发生了什么事？我是否只需要等待几周，直到我的本体“注册为有效前缀”？
I'm pretty new to SPARQL, OWL and Jena, so please excuse if I'm asking utterly stupid questions. I'm having a problem that is driving me nuts since a couple of days. I'm using the following String as a query for a Jena QueryFactory.create(queryString),
queryString = "PREFIX foaf: <http://xmlns.com/foaf/0.1/>"+
"PREFIX ho: <http://www.flatlandfarm.de/fhtw/ontologies/2010/5/22/helloOwl.owl#>" +
"SELECT ?name ?person ?test ?group "+
"WHERE { ?person foaf:name ?name ; "+
" a ho:GoodPerson ; "+
" ho:isMemberOf ?group ; "+
"}";
Until this morning it worked as long as I only asked for properties from the foaf namespace. As soon as I asked for properties from my own namespace I always got empty results. While I was about to post this question here and did some final tests to be able to post it as precise as possible, it suddenly worked. So as I did not know what exactly to ask for anymore, I deleted my question before posting it. A couple of hours later I used Protege's Pellet plugin to create and export an inferred Model. I called it helloOwlInferred.owl and uploaded it to the directory on my server where helloWl.owl resided yet. I adjusted my method to load the inferred ontology and changed the above query so that the prefix ho: was assigned to the inferred ontology as well. At once, nothing worked any more. To be exact it was not nothing that worked any more but it was the same symptoms I had till this morning with my original query. My prefix did not work any more. I did a simple test: I renamed all the helloWorldInferred.owl files (the one on my server for the prefix and my local copy which I loaded) to helloWorld.owl. Strange enough that fixed everything.
Renaming it back to helloWorldInferred.owl broke everything again. And so on. What is going on there? Do I just need to wait a couple of weeks until my ontology gets "registered as a valid prefix"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你必须为
ho:定义一个精确的URI前缀，然后告诉Protegé（有一个命名空间面板，并定义与本体前缀相同的URI），这样，当你在中定义GoodPerson时Protegé，它假设您的意思是http://www.flatlandfarm.de/fhtw/ontologies/2010/5/22/helloOwl.owl#GoodPerson，这与ho:GoodPerson相同仅当您为两者使用相同的 URI 前缀时。如果您不这样做，Protegé（或其他一些组件，如 Web 服务器）将做这些愚蠢的事情，例如编写本体的 URI 及其默认 URI 前缀（当您未指定时位于 GoodPerson 前面的前缀）任何前缀）使用文件名（或者更糟糕的是，像 file:///home/user/... 这样的 URI）。
请记住，本体的 URI 在技术上不同于用于与本体本身关联的实体（类、属性等）的 URI 前缀，并且
ho:只是具有本地含义的快捷方式，取决于您在文件或 SPARQL 查询等文档中定义的内容。本体 URI 也可以与从中获取本体文件的 URL 不同，尽管最好使它们相同。通常，您需要在 Apache 中进行 URL 重写才能实现这一点，但有时本体文件并未物理发布，因为本体被加载到 SPARQL 端点中，并且其 URI 通过端点的帮助解析为 RDF 文档通过将本体 URI 重写为发出 DESCRIBE 语句的 SPARQL 请求本身。只要关联数据可从您的 SPARQL 端点访问（即位于您的三元组存储中），同样的技巧可用于解析任何其他 URI（即您的本体实例化数据）。
You have to define a precise URI prefix for
ho:, then tell it to Protegé (there is a panel for namespaces and define the same URI as the ontology prefix), so that, when you define GoodPerson in Protegé, it assumes you meanhttp://www.flatlandfarm.de/fhtw/ontologies/2010/5/22/helloOwl.owl#GoodPerson, which is the same asho:GoodPersononly if you have used the same URI prefix for the two.If you don't do so, Protegé (or some other component, like a web server) will do these silly things like composing the ontology's URI and its default URI prefix (the one that goes in front of GoodPerson when you don't specify any prefix) using the file name (or even worse, a URI like file:///home/user/...).
Remember, the ontology's URI is technically different than the URI's prefix that you use for the entities associated to the ontology itself (classes, properties etc), and
ho:is just a shortcut having a local meaning, which depends on what you define in documents like files or SPARQL queries.The ontology URI can also be different than the URL from where the ontology file can be fetched, although it is good to make them the same. Usually you need to play with URL rewriting in Apache to make that happen, but sometimes that ontology file isn't physically published, since the ontology is loaded into a SPARQL endpoint and its URI is resolved to an RDF document through the help of the endpoint itself, by rewriting the ontology URI into a SPARQL request that issues a DESCRIBE statement. The same trick can be used to resolve any other URI (i.e., your ontology-instantiating data), as long as associated data are accessible from your SPARQL endpoint (ie, are in your triple store).
看起来这是由 Protege 中的错误（或功能？）引起的。当我用新名称导出推断本体时，Protege将
xmlns(blank)和xml:base的定义更改为新文件的名称，但它没有更改实际名称空间的定义。因为我修复了它似乎有效。
我的错是没有以必要的注意力检查实际来源。
It looks like this was caused by a bug (or a feature?) in Protege. When I exported the inferred ontology with a new name, Protege changed the definitions of
xmlns(blank)andxml:baseto the name of the new file, but it did not change the definition of the actual namespace.Since I fixed that it seems to work.
My fault not having examined the the actual source with the necessary attention.
前缀和 QName 的整个想法只是压缩 URI 以节省空间并提高可读性，它们最常见的问题是定义本身或 QName 中的拼写错误。
您在查询中使用的前缀定义很可能会导致生成的 URI 与本体中属性的实际 URI 不匹配。
话虽这么说，您的问题可能是由于耶拿的某些原因造成的，所以很可能值得在 耶拿邮件列表
The whole idea of prefixes and QNames is just to compress URIs to save space and improve readability, the most common issue with them is spelling errors either in the definitions themselves or in the QNames.
Most likely the prefix definition you are using in your query is causing URIs to be generated which don't match the actual URIs of properties in your ontology.
That being said your issue may be due to something with Jena so it may well be worth asking your question on the Jena Mailing List
也许您的 OWL 文件包含
rdf:ID="something"构造（或某种其他形式的相对 URL，例如rdf:about="#something"）？通过使用 OWL 文件的基本 URL，
rdf:ID和相对 URL 扩展为完整的绝对 URL，例如http://whatever/file.owl#something。如果文件中未明确指定基本 URL（使用类似xml:base="http://whatever/file.owl"的内容），则文件在 Web 服务器上的位置 (或者在您的文件系统中（如果您加载本地文件）将被用作基本 URI。因此，如果您移动文件或在多个位置拥有副本，则文件中的 URI 将发生变化，因此您必须相应地更改 SPARQL 查询。
包含显式
xml:base或避免相对 URI 和rdf:ID应该可以解决该问题。Maybe your OWL file contains the
rdf:ID="something"construct (or some other form of relative URL, such asrdf:about="#something")?rdf:IDand relative URLs are expanded into full absolute URLs, such ashttp://whatever/file.owl#something, by using the base URL of the OWL file. If the base URL is not explicitly specified in the file (using something likexml:base="http://whatever/file.owl"), then the location of the file on the web server (or in your file system if you load a local file) will be used as the base URI.So if you move the file around or have copies in several locations, then the URIs in your file will change, and hence you'd have to change your SPARQL query accordingly.
Including an explicit
xml:base, or avoiding relative URIs andrdf:ID, should fix the problem.