Ontology IRI versus ontology location - problem with indirect import
Opened this issue · 9 comments
Hi,
currently, to the best of my knowledge, the IRI of om-2 is http://www.ontology-of-units-of-measure.org/resource/om-2/ (or http://www.ontology-of-units-of-measure.org/vocabularies/om-2/ ?), while the location is https://raw.githubusercontent.com/HajoRijgersberg/OM/master/om-2.0.rdf! This works fine with a direct import, but in the case of an ontology O1 importing om-2, another ontology O2 importing O1 in Protégé leads to an error:
INFO 08:41:33 Exception caught trying to get ontology id for file:/C:/Users/JUNGG/Development/ontology/ontology/Extension%20(SERA%20information%20Objects)/ic-forecast.ttl org.semanticweb.owlapi.model.UnloadableImportException: Could not load imported ontology: <http://www.ontology-of-units-of-measure.org/resource/om-2> Cause: Server returned HTTP response code: 500 for URL: http://www.ontology-of-units-of-measure.org/data/om-2
Am I using the right location? How can I avoid this error?
Hi Georg,
Thanks for your interest and issue.
I see something strange in the error message of Protégé: it says 'Cause: Server returned HTTP response code: 500 for URL: http://www.ontology-of-units-of-measure.org/**data**/om-2'. However, I tried that URI and to it works; it returns the ontology code (although not the original om2.0.rdf). But I'm wondering why Protégé uses that URI. Could you try to use http://www.ontology-of-units-of-measure.org/resource/om-2/?
(Indeed, http://www.ontology-of-units-of-measure.org/vocabularies/om-2/ also appears to work.)
Best, Hajo
Hi Hajo,
thanks, this is indeed a good observation. I did not find the URL http://www.ontology-of-units-of-measure.org/data/om-2 in any of the local files and have no idea why Protégé is using it. I will try to look into that.
If I import om-2 directly into another ontology or open it in a new Protégé window, I use the Github raw file URL https://raw.githubusercontent.com/HajoRijgersberg/OM/master/om-2.0.rdf, since opening http://www.ontology-of-units-of-measure.org/resource/om-2/ never seemed to work. So with your hint I tried again loading the latter into a new Protégé window, and I got the same error message, now noticing the odd "data" URL:
Server returned HTTP response code: 500 for URL: http://www.ontology-of-units-of-measure.org/data/om-2
If I understand you correctly however, then even this "data"-URL should technically work?
Also, entering each URL into a browser:
- http://www.ontology-of-units-of-measure.org/resource/om-2 and
- http://www.ontology-of-units-of-measure.org/vocabularies/om-2
redirect to the documentation at [http://www.foodvoc.org/page/om-2], while
- http://www.ontology-of-units-of-measure.org/data/om-2 and
- https://raw.githubusercontent.com/HajoRijgersberg/OM/master/om-2.0.rdf
point to (different!) raw files.
Hi Georg,
Thanks for further investigating why Protégé uses that data URL.
I expect that data URL to work, since it seems to be generated somehow from the original om-2.0.rdf. However, it appears not to work... :/ I do not know why that data URL exists.
Thanx for everything you have tried. Long story short: I think we can best use the original om-2.0.rdf. That's the file I maintain; that's the way OM is meant to be.
Does that work for you?
Hi Hajo,
yes, for me it is perfectly fine to just use the maintained version at https://raw.githubusercontent.com/HajoRijgersberg/OM/master/om-2.0.rdf. However, there are some automatisms (in Protégé, but also in general) where I seem to have little influence over: If I import om-2 into an ontology O1 (using the URL above), om-2 identifies itself with the IRI prefix http://www.ontology-of-units-of-measure.org/resource/om-2 but loads just fine. However, if I import O1 into O2, during this import Protégé looks up om-2 via its IRI prefix, ends up contacting the latter URL, and from there gets redirected to http://www.ontology-of-units-of-measure.org/data/om-2, which unfortunately does not work.
The glitch is in the data URL not working, but also in the server at http://www.ontology-of-units-of-measure.org/ not redirecting to the Github raw ontology file but to the data URL. So either the om-2 version reachable through the data URL needs to be fixed or the redirection needs to point to Github instead.
I am trying to find a workaround in Protégé, I will post it here if I find something.
Cheers,
Georg
Hi Georg,
Thanx for your investigations. It's strange, especially if O2 imports O1. I have to discuss the topic within my organization. Hope that that can lead to a solution.
If you find a workaround, that would be great. Let's keep each other updated!
Cheers, Hajo
@HajoRijgersberg @GeorgJung I had a quick look at this and from what I can tell the problem is somewhere down in the software used on the FoodVoc site to host the ontology.
First of all, to address the mystery of the /data/ url: this is expected for a Linked Data Platform (it's basically the content negotiation pattern described here: https://www.w3.org/TR/cooluris/#r303uri). The software makes a distinction between the URL that identifies the resource (the /resource/ url) and the URL that describes the resource (the /data/ url). We can see what is happening by doing a curl request:
❯ curl -v http://www.ontology-of-units-of-measure.org/resource/om-2/
* Trying 137.224.11.21...
* TCP_NODELAY set
* Connected to www.ontology-of-units-of-measure.org (137.224.11.21) port 80 (#0)
> GET /resource/om-2/ HTTP/1.1
> Host: www.ontology-of-units-of-measure.org
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Wed, 14 Jul 2021 22:46:20 GMT
< Server: Apache-Coyote/1.1
< Location: /data/om-2
< Content-Length: 0
The response is a HTTP 302 (redirect) status code, and the location to which it redirects is /data/om-2. So it's the hosting software that introduces that URL, and this is normal, and Protege is also doing the right thing by following that redirection.
The second part of the problem is the 500 error you saw when Protege tried to import the ontology from the redirected url. We can reproduce this with curl as well:
❯ curl -v http://www.ontology-of-units-of-measure.org/data/om-2
* Trying 137.224.11.21...
* TCP_NODELAY set
* Connected to www.ontology-of-units-of-measure.org (137.224.11.21) port 80 (#0)
> GET /data/om-2 HTTP/1.1
> Host: www.ontology-of-units-of-measure.org
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Date: Wed, 14 Jul 2021 22:49:01 GMT
< Server: Apache-Coyote/1.1
< Content-Type: text/plain;charset=ISO-8859-1
< Content-Length: 69
< Connection: close
<
* Closing connection 0
{"message" :"Interne fout","exception" :"no message","success":false}
This is a bug in the LD platform software used on the foodvoc site, related to the handling of the Accept header in the request (the Accept header indicates the syntax format the client prefers for the data in the response). In the above request it's not set to a specific format, and this results in a 500 error. If we adapt the request to set an explicit header to, for example, say "I want my data in RDF/XML syntax", we do get a response with actual RDF data:
curl -v -H "Accept: application/rdf+xml" http://www.ontology-of-units-of-measure.org/data/om-2
* Trying 137.224.11.21...
* TCP_NODELAY set
* Connected to www.ontology-of-units-of-measure.org (137.224.11.21) port 80 (#0)
> GET /data/om-2 HTTP/1.1
> Host: www.ontology-of-units-of-measure.org
> User-Agent: curl/7.64.1
> Accept: application/rdf+xml
>
< HTTP/1.1 200 OK
< Date: Wed, 14 Jul 2021 22:51:27 GMT
< Server: Apache-Coyote/1.1
< Transfer-Encoding: chunked
<
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#hiddenLabel">
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#AnnotationProperty"/>
</rdf:Description>
<rdf:Description rdf:nodeID="genid-9705366b18194de9a2dcb5bbab39c385-node1c3sfjt7fx10">
<rdf:rest rdf:nodeID="genid-9705366b18194de9a2dcb5bbab39c385-node1c3sfjt7fx11"/>
<rdf:first rdf:resource="http://www.ontology-of-units-of-measure.org/resource/om-2/SingularUnit"/>
</rdf:Description>
<rdf:Description rdf:about="http://www.ontology-of-units-of-measure.org/resource/om-2/SingularUnit">
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
(...etc)
I think that Protege shows a 500 error because it either does not set an Accept header when processing the import, or it sets the header to a value the FoodVoc software doesn't understand. Either way the problem is at FoodVoc's end: it should not throw an error for this, but just pick a default format if it can't figure out the preferred format (or return a 406 "Not Acceptable" error, rather than a 500, so the client knows what is wrong).
Finally, as for why the returned data is not the right version of the OM ontology: that is a matter for how the FoodVoc software is configured, and how any updates done to the version of OM in this Github repository are supposed to make their way into that platform.
Thanx, Jeen! @ Georg: Jeen and I are now in contact about this subject and the intention is that within my organization activities will be organized based on what Jeen describes to update FoodVoc.
To be continued!
Hi @HajoRijgersberg, @jeenbroekstra,
any news on this issue?
Turns out that this problem is not only caused by the FoodVoc software (which still needs to be fixed), but often occurs with Protégé when dealing with redirections. See for example issue 890 at Protégé, issue 705 at OWL API, or issue 954 at OWL API.
Still, if this can be fixed on your side it would help tremendously. Some of the issues reporting this for Protégé or OWL API date back to 2019 and are still open...
Hi Georg,
No news yet, except that I have again contacted people within my organization about this issue. Hope I will get an answer soon...
Thanx, good to know about Protégé! Jeen, do you have these experiences too?