External Process (tool) Error Handling

[coltonglasgow]

The ontology toolkit allows you to define an external tool. This feature is used in the documentation for serialization but I am attempting to use it for validation. I have an external script that loads all ontology files and checks for undefined concepts across ontologies but I am unable to access the results of that script via the onto_tool bundle process. I do not believe onto_tool keeps track of the external process to indicate a pass/fail. Similar to the validation action, I would like a way of stopping the bundle process if my external tool fails.

The way these external processes are started is with a transform action. That makes sense for external scripts that transform files but in my case, I am attempting to validate (not change any files). Maybe an external tool action could be created for better clarity.

[sa-bpelakh]

I have actually started work on an external tool validator, I can try to dig that up. However, what does your 'undefined concepts' tool do - can it be expressed as a SPARQL query? If so, you can just use a SPARQL SELECT or CONSTRUCT validator to do the same, and not have to have external scripts.

[coltonglasgow]

The undefined concepts script is a modified version of a script originally written by @dylan-sa (https://github.com/semanticarts/undefined-concepts-tool). The intention of the script is to load all ontology files into individual named graphs and look for classes and properties that have not been defined in any of the named graphs (using named graphs to identify the source file). We have gone a step farther than this to also convert our triple pattern files into valid turtle and check for undefined concepts in those files as well. A SPARQL query is the method used to find the undefined concepts in the script but the triple pattern to valid turtle conversion (I believe) is only possible in a script.

[rjyounes]

@sa-bpelakh This is just one example. It could be the serializer or any number of other things. I don't know if you can pick up fatal errors from any type of tool, but perhaps you can handle specific types of errors from Python (e.g., sys.exit(1)).

[bpelakh]

Right, the use case for which I was developing the 'tool' validation was a reasoner. The intent was anything that could return a non-zero return code as an indication of failure.

…

On Thu, Jul 24, 2025 at 5:16 PM Rebecca Younes ***@***.***> wrote: *rjyounes* left a comment (semanticarts/ontology-toolkit#130) <#130 (comment)> @sa-bpelakh <https://github.com/sa-bpelakh> This is just one example. It could be the serializer or any number of other things. I don't know if you can pick up fatal errors from any type of tool, but perhaps you can handle specific types of errors from Python (e.g., sys.exit(1)). — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA27QIPCZQTL2NORI7UL7C33KFEKHAVCNFSM6AAAAACCJ672USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMJUHE4DKNJUHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rjyounes]

Now we've observed that some errors in scripts invoked from the bundler do halt onto_tool processing. Perhaps the problem in the other cases we observed was that the scripts were not actually throwing errors. But I'm confused about why @bpelakh thinks onto_tool is not doing that. Can this issue be closed?