简体   繁体   中英

How to extend Pellet 2.4.0 with custom SWRL built-ins?

I've already accomplished this with the SWRLBuiltInBridge component of the SWRLAPI: https://github.com/protegeproject/swrlapi/wiki/SWRLBuiltInBridge

However, in my Java code I also use the Pellet Reasoner with the OWLAPI. Whenever I use the reasoner it generates a warning when it finds a SWRL rule with an unknown built-in. I know I could disable the rule checking in the reasoner and use the SWRLAPI whenever I want to run the rules.

But that seems nonpractical... Because I would have to run the rules after every ontology modification before I use the reasoner.

I've seen a blog page which delves into this question, but might be outdated: https://semwebguy.wordpress.com/2011/01/04/how-to-extend-pellet2-2-2s-swrl-built-in-support-with-your-custom-built-in/

Furthermore, the way of creating a built-in (accordingly to the blog) is different when compared with the SWRLAPI (the Abox object is an argument for example).

Is there another approach to do this? Or is it possible to connect Pellet with the SWRLBuiltInBridge?

The Pellet reasoner do not use SwrlApi. The way Pellet use/implement built-in is really far from the SwrlApi. Each built-in must interact with the inner datastructure of the reasoner (ABox) and must do it using the ATerm's objets.

But if you need to do it, there is always a hack that is possible. You can follow the example on the method testSpecialBuitIn() .

They key is to add your custom buildIn using this method: BuiltInRegistry.instance.registerBuiltIn.

If your builtin is correct, there is nothing more require.

Please not that this solution use the .core. modules of Pellet without interfaces; so changes in form/behaviour can occur from one version to another without warning.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM