Redirect from HTTP to HTTPS doesn't work

[matthewhorridge]

Protege 4.3 doesn't seem to load purl.org-based ontologies correctly. For example, the ontology http://purl.org/twc/ontology/frir.owl loads successfully when I load it from a local file, or when I load the redirect target (https://raw.github.com/timrdf/csv2rdf4lod-automation/master/doc/ontology/frir.owl), but for whatever reason, Protege attempts to load the redirect page as RDF directly. This is obviously incorrect, and doesn't seem to work for 302 or 303 redirects.

Is there an aspect of the redirect that I'm missing to make Protege work fine? This is a pretty standard way to create a long-lived URI for ontologies, and it's disappointing that it doesn't seem to work anymore.

[stdotjohn]

This is an old bug that was passed to the OWL api bugtracker some time
ago. The issue is that the redirect goes from http to https. Java does
not like these redirects (there is a bug report for java somewhere also)
because it represents a change in security. In this case it could cause
a user to reveal his or her identity. When I last looked the java bug
was marked as "won't fix". I don't know what happened with the owl api bug.

-Timothy

On 11/14/2013 09:24 AM, Matthew Horridge wrote:

|Protege 4.3 doesn't seem to load purl.org-based ontologies correctly. For example, the ontology http://purl.org/twc/ontology/frir.owl loads successfully when I load it from a local file, or when I load the redirect target (https://raw.github.com/timrdf/csv2rdf4lod-automation/master/doc/ontology/frir.owl), but for whatever reason, Protege attempts to load the redirect page as RDF directly. This is obviously incorrect, and doesn't seem to work for 302 or 303 redirects.

Is there an aspect of the redirect that I'm missing to make Protege work fine? This is a pretty standard way to create a long-lived URI for ontologies, and it's disappointing that it doesn't seem to work anymore.
|

—
Reply to this email directly or view it on GitHub
#17.

[jvendetti]

I looked through the bug list on the OWL API's GitHub page. I couldn't find any bug reports for this, but maybe I missed something.

I downloaded the latest version of the OWL API from Maven Central (version 3.4.8), and dropped it into a Protege 4.3 installation. Performing a File | Open from URL... with http://purl.org/twc/ontology/frir.owl results in the following exception:

org.semanticweb.owlapi.io.OWLOntologyCreationIOException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

[matthewhorridge]

See this http://sourceforge.net/p/owlapi/bugs/367/

[matthewhorridge]

Testing outside of Protege with 3.4.8 and the following code works

try {
            OWLOntologyManager man = OWLManager.createOWLOntologyManager();
            OWLOntology ont = man.loadOntology(IRI.create("http://purl.org/twc/ontology/frir.owl"));
            System.out.println(ont);
} catch (OWLOntologyCreationException e) {
            e.printStackTrace();
}

[stdotjohn]

I think that this may have been fixed? I tried this on a relatively
recent (development) version of Protege and it succeeded in both opening
the ontology and open an ontology with this import.

Can any confirm or deny?

-Timothy

[jvendetti]

You're right Tim. I was able to successfully load this ontology in Protege using the latest code base. Verified both with a version of Protege built with Eclipse, and a version of Protege built on the command line with Maven.

I don't know what changed between versions 4.3 and current code base that fixed this issue. Nonetheless, I'm closing, and this problem won't be present in the next release (5.0.0 beta).