search

CommonCoreOntology / CommonCoreOntologies

The Common Core Ontology Repository holds the current released version of the Common Core Ontology suite.
BSD 3-Clause "New" or "Revised" License
176 stars 51 forks source link

Is robot.jar mistakenly accessing the wrong imported ontology? #452

Open swartik opened 2 weeks ago

swartik commented 2 weeks ago

This issue is related to #451. After changing the Makefile in my copy of the repository per that issue, I ran make. with the arguments to make curl succeed. The make command got as far as reasoning. Here's some abbreviated output:

for file in src/cco-modules/AgentOntology.ttl src/cco-modules/ArtifactOntology.ttl ... Reasoning on src/cco-modules/AgentOntology.ttl... org.semanticweb.owlapi.model.UnloadableImportException: Could not load imported ontology: http://www.ontologyrepository.com/CommonCoreOntologies/Mid/InformationEntityOntology Cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The command fails for the same reason curl failed in #451: my organization's firewall. Robot.jar attempted to import a file from ontologyrepository.com and the firewall blocked the request. For the record, I have access to another computer beyond our firewall. On that computer the command works as expected.

Now, here's the issue. Isn't the proper action for robot.jar to open the version of InformationEntityOntology in the src/cco-modules directory? Is the attempt to access ontologyrepository.com a mistake?

I have almost no experience with robot.jar, and I don't even know if it has an equivalent to Protege's catalog-v001.xml. An expert will have to weigh in on whether accessing the local file is possible.

dlutz2 commented 2 weeks ago

The error "unable to find valid certification path to requested target" is not actually the firewall blocking the request, its your local jre/jdk refusing to make the connection since it cannot verify the https connection. This is caused by the local java not having the needed trusted certs to trace the "certification path" mentioned. Often this means the local jre/jdk doesn't have the certs managed by your company/site (or whoever manages the firewall/security infrastructure). This can be remedied by either a) adding those certs to the jre or b) finding the setting if its exists for all apps that make https calls (e.g. curl, ROBOT). Also, ROBOT does use the catalog-v001.xml file (assumed to be in same directory as input ontology or as explicitly in the ROBOT call) but that catalog file must contain all ontologies (and their imports), with the versioned IRI if that's how its referenced in the import, pointing to the local copies and or it will attempt a remote fetch resulting in the error you saw. Also, also, ROBOT uses the same OWLAPI libraries that Protege uses, so if you can get Protege to resolve the imports, you should also be able to get ROBOT to resolve them (without disabling security which some companies discourage)

swartik commented 2 weeks ago

@dlutz2, I appreciate the clarification. I admit I'm using "firewall" loosely, to describe all the transformations and filters that occur between my computer and a destination URL. As for solutions, suffice it to say I've gone back and forth with my IT department many times and the only thing that's ever worked is configuring applications to ignore certificates and security.

What I'm saying is: some of us have problems beyond our control, and I hope CCO's maintainers will be able to provide us with workarounds.